On Mon, 23 Jun 2008, Joe Kepley wrote:
> > HTTP Request Parser
> > ===================
> >
> > Reminder: the request parser creates the abstract input object.
> >
> > 0) Should it allow plugins?
> > > no
> > 1) Should filter anything?
> > > no
> > 2) Should all the GET/POST variables be mixed together?
> > > yes
>
>
> Given that it would be bad form to have a GET and POST variable of the same
> name on the same request, I'd agree with this. The system should give higher
> priority to POST vars vs GET vars to help avoid very simple variable
> spoofing.
I think it should still be configurable though - atleast the order of
overriding.
> > 3) Should all uploaded files info be in something like $input->files?
> > > yes
>
> What would the interface for this look like? Suppose I have two fields on my
> input form that take files, maybe <input type=file name=picture /> and
> <input type=file name=resume />. Would this be $input->files['resume'] and
> $input->files['picture']?
>
> Perhaps a cleaner implementation would be to have an object that represents
> the uploaded file, and mix that in with the other input fields.
>
> Let's suppose we have a form with these fields: name(text), email(text),
> picture(file), and resume(file). Maybe my input structure would look like
> this:
>
> $input->parameters: Array('name'=>'Bob Example', 'email'=>'[EMAIL PROTECTED]',
> 'picture'=>[some object representing an uploaded file], 'resume'=>[some
> object representing an uploaded file])
>
> We could have something like an HTTPUploadedFile class with attributes for
> file name, mime type, size, tmp file name, and error code. A saveTo() method
> that calls move_uploaded_file would offer some syntatic sugar as well. Then
> I could say things
> like: $input->parameters['resume']->saveTo('resumes/xyz.doc');
>
> Thoughts?
Sounds like an idea.
regards,
Derick
--
Components mailing list
[email protected]
http://lists.ez.no/mailman/listinfo/components
