Hi, this is the updated current points to discuss.
Feel free to comment or add any ;)
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 m
Hi!
On 06/23/2008 04:50 PM James Pic wrote:
> Hi, this is the updated current points to discuss.
> Feel free to comment or add any ;)
> HTTP Request Parser
> ===
> Reminder: the request parser creates the abstract input object.
> 0) Should it allow plugins?
>> no
I would not do
> 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?
Hi Tobias, Thanks for your input!
Tobias Schlitt wrote:
> On 06/23/2008 04:50 PM James Pic wrote:
> > 1) Should filter anything?
> >> no
>
> Same as above. Filtering should usually be done in the models, IMO.
Are you sure that persistent object classes should accept invalid values and try
to filt
Hi Joe! Thanks for your input!
Joe Kepley wrote:
> > HTTP Request Parser
> > ===
> > 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 s
On Tue, 24 Jun 2008, James Pic wrote:
> Tobias Schlitt wrote:
> > On 06/23/2008 04:50 PM James Pic wrote:
> >
> > > 1) Should the component supply input filters?
> > >> yes, one in a first stage, then many with tieins
> >
> > We only have UserInput for this purpose, so this would make 1 tiein.
>
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 toge
Derick Rethans wrote:
> On Tue, 24 Jun 2008, James Pic wrote:
> > Tobias Schlitt wrote:
> > > On 06/23/2008 04:50 PM James Pic wrote:
> > > > 1) Should another object be used to factorized processes that are
> > > > common the
> > > > the input and the view-router?
> > >
> > > What do you imagine
On Tue, 24 Jun 2008, James Pic wrote:
> Joe Kepley wrote:
> >
> > 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.
On Mon, 2008-06-23 at 16:50 +0200, James Pic wrote:
> Hi, this is the updated current points to discuss.
> Feel free to comment or add any ;)
>
> HTTP Request Parser
> ===
>
> Reminder: the request parser creates the abstract input object.
>
> 0) Should it allow plugins?
> > no
>
On Tue, 24 Jun 2008, Kore Nordmann wrote:
> On Mon, 2008-06-23 at 16:50 +0200, James Pic wrote:
> > Hi, this is the updated current points to discuss.
> > Feel free to comment or add any ;)
> >
> > HTTP Request Parser
> > ===
> >
> > Reminder: the request parser creates the abstr
Derick Rethans schrieb:
> On Tue, 24 Jun 2008, Kore Nordmann wrote:
>
>> On Mon, 2008-06-23 at 16:50 +0200, James Pic wrote:
>>> Hi, this is the updated current points to discuss.
>>> Feel free to comment or add any ;)
>>>
>>> HTTP Request Parser
>>> ===
>>>
>>> Reminder: the reque
Hi,
Thanks Kore and Pierre for the input!
Pierre Minnieur wrote:
> Derick Rethans schrieb:
>> On Tue, 24 Jun 2008, Kore Nordmann wrote:
>>> On Mon, 2008-06-23 at 16:50 +0200, James Pic wrote:
Hi, this is the updated current points to discuss.
Feel free to comment or add any ;)
H
Derick Rethans wrote:
> On Tue, 24 Jun 2008, Kore Nordmann wrote:
> > On Mon, 2008-06-23 at 16:50 +0200, James Pic wrote:
> > > Output Filters
> > > ==
> > > 2) Should this filters be pluggable in the view-manager?
> > > > no
> >
> > IF we support output filters, they must be pluggable
>
>
> > 2) Should all the GET/POST variables be mixed together?
> > > yes
>
> GET variables should be used for view selection, or maybe selection of
> the data to display, while POST data should be used for modifications. I
> wouldn't like that those semantic differences between thse two data
> arr
15 matches
Mail list logo
