On 03.11.2004 00:21, Sylvain Wallez wrote:
As I told before I am not sure. I really want to see what the other
people
will said here. I also already saw that Sylvain voted +1 for the changes.
But I am not sure if this is correct or not. That is all.
Yes, I'm +1. Or +10, +100 and even +1000 :-)
Thi
What i ment was that if a widget is disabled or not in a view it
shouldn't be processed as opposed to an empty parameter. They both have
the same value when invoking the "Request.getParameter" (null), don't
they?
On Tue, 2004-11-02 at 23:18, Sylvain Wallez wrote:
> Nuno Santos wrote:
>
> >The Re
Antonio Gallardo wrote:
Hi Tim:
As I told before I am not sure. I really want to see what the other people
will said here. I also already saw that Sylvain voted +1 for the changes.
But I am not sure if this is correct or not. That is all.
Yes, I'm +1. Or +10, +100 and even +1000 :-)
This issue h
Nuno Santos wrote:
The Request interface has a method to get an enumeration of parameter
names( getParameterNames), so just check the existence of the widget
Request parameter name and process only if exist!
We don't need to enumerate parameters, as each widget knows which
parameters it should
Jason Johnston wrote:
On Tue, 2004-11-02 at 13:55, Tim Larson wrote:
We would still perform validation. The only thing we would not do
is automatically reset a widget's value to null when its request
parameter is missing. Because we would still validate the widget,
"required" widgets would sti
On Tue, 2004-11-02 at 13:55, Tim Larson wrote:
>
> We would still perform validation. The only thing we would not do
> is automatically reset a widget's value to null when its request
> parameter is missing. Because we would still validate the widget,
> "required" widgets would still catch empty
Hi Tim:
As I told before I am not sure. I really want to see what the other people
will said here. I also already saw that Sylvain voted +1 for the changes.
But I am not sure if this is correct or not. That is all.
Tim Larson dijo:
> On Tue, Nov 02, 2004 at 02:38:24PM -0600, Antonio Gallardo wrot
On Tue, Nov 02, 2004 at 02:38:24PM -0600, Antonio Gallardo wrote:
> I see the point.I am more convinced that we are pushing HTTP to the
> maximum and we need more well, can we implement that only for
> stateless forms? Why we need to cut all with the same scissors? This is
> only a thought. ;-)
On Tue, Nov 02, 2004 at 12:33:48PM -0700, Jason Johnston wrote:
> On Mon, 2004-11-01 at 22:08, Tim Larson wrote:
> > > This can open some posible security concerns at all?
> >
> > The form model would still be in control of which request
> > parameters get processed. The only change is that a mis
Tim Larson dijo:
> On Mon, Nov 01, 2004 at 06:13:21PM -0600, Antonio Gallardo wrote:
>> Tim Larson dijo:
>> > We have talked several times about changing the request
>> > processing in cforms to not touch any widget whose
>> > request parameter is missing (to prevent these widgets'
>> > values from
On Mon, 2004-11-01 at 22:08, Tim Larson wrote:
> > This can open some posible security concerns at all?
>
> The form model would still be in control of which request
> parameters get processed. The only change is that a missing
> request parameter would cause no change to the corresponding
> widg
The Request interface has a method to get an enumeration of parameter
names( getParameterNames), so just check the existence of the widget
Request parameter name and process only if exist!
On Tue, 2004-11-02 at 05:08, Tim Larson wrote:
> On Mon, Nov 01, 2004 at 06:13:21PM -0600, Antonio Gallardo w
Tim Larson wrote:
We have talked several times about changing the request
processing in cforms to not touch any widget whose
request parameter is missing (to prevent these widgets'
values from being reset to null,) the end result being
that it would be easier for the view to decide how to
split a f
On Mon, Nov 01, 2004 at 06:13:21PM -0600, Antonio Gallardo wrote:
> Tim Larson dijo:
> > We have talked several times about changing the request
> > processing in cforms to not touch any widget whose
> > request parameter is missing (to prevent these widgets'
> > values from being reset to null,) t
Tim Larson dijo:
> We have talked several times about changing the request
> processing in cforms to not touch any widget whose
> request parameter is missing (to prevent these widgets'
> values from being reset to null,) the end result being
> that it would be easier for the view to decide how to
We have talked several times about changing the request
processing in cforms to not touch any widget whose
request parameter is missing (to prevent these widgets'
values from being reset to null,) the end result being
that it would be easier for the view to decide how to
split a form across multipl
16 matches
Mail list logo
