> Hi, this is the updated current points to discuss.
>
> 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.
>
> 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?
Input Filters
> =============
>
> 0) Should the component supply an input filter interface?
> > yes
> 1) Should the component supply input filters?
> > yes, one in a first stage, then many with tieins
> 2) Should the component user handle filtering in his controllers?
> > yes
>
> Output Filters
> ==============
>
> 0) Should the component supply an output filter interface?
> > yes
> 1) Should the component supply input filters?
> > yes, one with HTML/Tidy in a first stage, then with tieins
> 2) Should this filters be pluggable in the view-manager?
> > no
> 3) Should this filters be freely usable by the component user once he has
> his
> output from the view manager?
> > yes
>
> Routing
> =======
>
> 0) Which routed should be developped first? Url, Tree, Regexps, Assertions
> (railish) ?
Assertions or Regexps will probably be the easiest to develop. Starting
there would let us turn up a working example earlier. I haven't looked at
the tree component enough to render an opinion, but the URL controller may
need to be fairly verbose.
A Simple Router may serve as a good example to help people understand what a
router does. Have it take the first URL segment as the controller name, the
second as the action name, and the third as an id parameter (if the third
does anything at all).
>
>
> View-manager
> ============
>
> 0) Should the view-manager implement the same routing system as the router?
> 1) Should another object be used to factorized processes that are common
> the
> the input and the view-router?
>
> View-handlers
> =============
>
> 0) Which should be the first view handler?
> > PhpViewHandler, PHP being a fine templating languages
>
> PhpViewHandler
> --------------
>
> 0) How should view methods be implemented?
> > In factories/singletons, it should be easy to port to Template extensions
> --
> Components mailing list
> Components@lists.ez.no
> http://lists.ez.no/mailman/listinfo/components
>
--
Joe Kepley
Director of Development
-------------------------
Blend Interactive, Inc.
http://www.blendinteractive.com
-------------------------
136 S. Dakota Avenue
Sioux Falls, SD 57104
o: 605.334.7077
m: 605.728.6550
f: 866.686.5491
--
Components mailing list
Components@lists.ez.no
http://lists.ez.no/mailman/listinfo/components
