> [mailto:[EMAIL PROTECTED] On Behalf Of Oleg Kobchenko > --- "Sherlock, Ric" <[EMAIL PROTECTED]> wrote: > > > I think I met it in one recent DSLs (D=Domain) that it's good > to have a single point of change: if there is no file name, > there is no file--that's the rationale behind testing > > 0<#qparamFile key instead of qparamFileExists key > > and I think it's less stressful not to worry about sync'ing > another pair of variables. With current implementation, this > workds perfectly. However, if app dev accidentally does not > indicate "multipart", the file name will arrive in qparam > instead. Whereas 0=#qparamFile key. A little inconsistency, > but maybe it is for the better, because a <intput type=file > > should not be used outside of "multipart". > In other words, a file is really a file only if 0<#qparamFile > key, in which case "qparam key" contains (reference to) its contents. > I'm convinced!
> > The other thing I'm debating, is whether consolidating keys with the > > same name into a vector should be left to the user if desired or be > > handled by JHP. This would add an additional level of boxing to > > CGIVALS, but given the array nature of J, I'm leaning > > towards JHP handling it. > > This would mean for instance that a set of checkboxes or > > radio buttons > > would be automatically become one entry in CGIKEYS and a vector in > > CGIVALS. Something along the lines of: > > CGIKEYS=: ~.CGIKEYS > > CGIVALS=: CGIKEYS </. CGIVALS > > This is a good point. It is address under HTTP Parameters in > http://www.jsoftware.com/jwiki/CGI/Design > > In other words, the "qparam key" will return the first value, > where as a number of additional accessors will take care of > arrays of grouped parameters: qparamList key - for same > names; qparamPrefix prefix - for cluster of parameters with > the same prefix (good for representing isolated entities on > the same page, like DB records, paging/sorting, etc.) > > The goal of this and other API designs is to isolate the user > from the global nouns and instead provide accessor verbs, > which have the advantage of representing different views of > the same underlying state. OK, that makes sense. I think I'm starting to understand how JHP & the CGI framework you have proposed fit together. ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
