You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Danny Bols <db...@osirion.be> on 2003/11/20 09:14:26 UTC
Woody - Determining the value for a widget
Hello,
it seems that if a field widget doesn't have a corresponding value in the
request it's original value gets overidden with the null-value.
Is this the way it should work or is it a slip of the pen in the
Field.readFromRequest(formContext) method?
--
Danny
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
RE: Woody - Determining the value for a widget
Posted by Antonio Gallardo <ag...@agsoftware.dnsalias.com>.
Danny Bols dijo:
>> From: Antonio Gallardo [mailto:agallardo@agsoftware.dnsalias.com]
>> Sent: zaterdag 22 november 2003 9:24
>> To: users@cocoon.apache.org
>> Subject: RE: Woody - Determining the value for a widget
>>
>>
>> Danny Bols dijo:
>> > I still have a problem with the current behaviour which overwrites
>> field
>> > values with null values if they are not available on the request
>> string!
>> > If I am not able to convince you at least I would plead to make this
>> > behaviour configurable.
>>
>> You can define this fields as "wd:output". We use it for hidden Primary
>> keys and woody gracefully return it back. It does not overwrite it.
>>
>> But, I think the question here is what we are trying to do with woody?
>>
>> Woody is just a form interface between the user and the server. Woody
>> work
>> is interact with the user and return to us the results of this
>> interaction. Nothing more, nothing less.
>>
>> The woody binding framework allow us to easily interact between the
>> "model" and the "views", by using form.save() and form.load(). The views
>> in this case is woody.
>>
>> The tight integration between woody and "model" related stuff is not a
>> good idea. I am not sure why I need to be confident with woody about my
>> data. I prefer to never let them leave. Instead we can just give a copy
>> to
>> woody. As pointed before, we cannot trust in the user input. So why put
>> on
>> risk the critical data, by giving them to woody? An approach is: "check"
>> what woody return back, control it and do some actions after all. This
>> is
>> posible using Flow.
>>
>> My view point is: woody just send me the fields that the user fill.
>> Woody
>> cannot manage all the bean fields if we don't describe it.
>> Note: I am aware it is posible, JXPath allow it, but it is not
>> desirable.
>>
>> Woody don't know nothing more or nothing less. I cannot expect woody
>> return me the next value of an autoincremental value. This is not woody
>> job.
>>
>> Then it is the work of the "model" to decide what actions to do based on
>> the woody output. It is a chain. So I think we cannot ask more to woody.
>>
>> Don't think I have not the same problems as you. We thought a solution
>> can
>> be a returning flags that indicate what changed on the bean. Maybe
>> Dynabeans can come to help here.
>
> Just to make the discussion clear a I made a simplified description and
> example of the process we are talking about:
>
> Some shortcuts I used:
> ---------------------------------
> DS = Data Store (could be a database)
> BO = Business Object (could be a bean)
> UI = User interface (could be multiple templates acting on 1 form)
>
> The process:
> ------------------
> DS--(1)-->BO--(2)-->(Form<--(3)-->UI)--(4)-->BO--(5)-->DS
>
> (1)The BO is loaded from the DS
> (2) The BO data is loaded into a FORM
> (3) User interaction takes place based on the FORM object.
> (4) The FORM data is assigned to BO
> (5) BO changes are comitted to the DS:
>
>
> Example
> ------------
> A (very) simplified sales transaction example of this process (in
> flowscript) could be something like:
>
> (1) SalesOrder mySalesOrder = new SalesOrder();
> mySalesOrder.loadFromDataStore("so125631");
>
> (2) myForm.id = mySalesOrder.getOrderNo();
> myForm.desc = mySalesOrder.getDescritpion();
> :
> for(var i = mySalesOrder.getOrderLines(); i.hasNext();) {
> var myOrderLine = i.next();
> var myRow = myForm.form.getWidget("orderlines").addRow();
> myRow.id = myOrderLine.getId();
> myRow.desc = myOrderLine.getDesc();
> }
>
> (3) while(!finished) {
> :
> if(showOrderLines) {
> form.showForm("orderlines");
> if(showOrderLineDetails) {
> form.showForm("orderlinedetails");
> } else {
> form.showForm("orderheader");
> }
> }
>
> (4) mySalesOrder.setDescritpion(myForm.desc);
> for(var i = myForm.getWidget("orderlines"); i.hasNext();) {
> var myRow = i.next();
> var myOrderLine = mySalesOrder.getOrderLine(myRow.id);
> myOrderLine.setDesc(myRow.desc);
> }
>
> (5) mySalesOrder.saveToDataStore()
>
>
> Thougths
> -------------
> This thread is about the 3th step in the process, the user interaction
> based
> on a woody form object. The contract between the model and view is the
> FORM
> object. But once the data is handed over from the MODEL to the VIEW you
> want
> to be able to build "flexible interaction" with "riskless processing".
>
> Flexible interaction.
> IMHO this would start with having multiple templates for one form and to
> be
> able to refer to all the widgets in a form (absolute/relative addressing
> widgets, see other thread).
>
> Riskless processing.
> If in the example above I activate an order header template (which doesn't
> do anything with my order lines) I don't want my order line data to
> unnecessary travel back and forth over the network and to be processed by
> woody. Why should we use hidden fields? Why storing primary keys in
> wd:output fileds? Why put extra load on the valuable resources and
> processing time? Why introducing more processing risks?
I just suggested a posible solution. But I guess you are controlling all
this flow from the same function. If this is the case. You don't need to
make a roundtrip for the header info. The header is stored inside the
continuation as part of a variable being declared in the flow:
> (3) while(!finished) {
> :
> if(showOrderLines) {
> form.showForm("orderlines");
mySalesOrder.processOrderLines;
> if(showOrderLineDetails) {
> form.showForm("orderlinedetails");
mySalesOrder.processOrderLinesDetails;
> } else {
> form.showForm("orderheader");
mySalesOrder.processHeader;
> }
> }
Is this OK?
Best Regards,
Antonio Gallardo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
RE: Woody - Determining the value for a widget
Posted by Antonio Gallardo <ag...@agsoftware.dnsalias.com>.
Danny Bols dijo:
> I still have a problem with the current behaviour which overwrites field
> values with null values if they are not available on the request string!
> If I am not able to convince you at least I would plead to make this
> behaviour configurable.
You can define this fields as "wd:output". We use it for hidden Primary
keys and woody gracefully return it back. It does not overwrite it.
But, I think the question here is what we are trying to do with woody?
Woody is just a form interface between the user and the server. Woody work
is interact with the user and return to us the results of this
interaction. Nothing more, nothing less.
The woody binding framework allow us to easily interact between the
"model" and the "views", by using form.save() and form.load(). The views
in this case is woody.
The tight integration between woody and "model" related stuff is not a
good idea. I am not sure why I need to be confident with woody about my
data. I prefer to never let them leave. Instead we can just give a copy to
woody. As pointed before, we cannot trust in the user input. So why put on
risk the critical data, by giving them to woody? An approach is: "check"
what woody return back, control it and do some actions after all. This is
posible using Flow.
My view point is: woody just send me the fields that the user fill. Woody
cannot manage all the bean fields if we don't describe it.
Note: I am aware it is posible, JXPath allow it, but it is not desirable.
Woody don't know nothing more or nothing less. I cannot expect woody
return me the next value of an autoincremental value. This is not woody
job.
Then it is the work of the "model" to decide what actions to do based on
the woody output. It is a chain. So I think we cannot ask more to woody.
Don't think I have not the same problems as you. We thought a solution can
be a returning flags that indicate what changed on the bean. Maybe
Dynabeans can come to help here.
I know I can be wrong, please comments.
Best Regards,
Antonio Gallardo.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
RE: Woody - Determining the value for a widget
Posted by Antonio Gallardo <ag...@agsoftware.dnsalias.com>.
Danny Bols dijo:
>> From: Bruno Dumon [mailto:bruno@outerthought.org]
>> Sent: zaterdag 22 november 2003 16:48
>> To: users@cocoon.apache.org
>> Subject: RE: Woody - Determining the value for a widget
>>
>>
>> On Sat, 2003-11-22 at 08:41, Danny Bols wrote:
>> > > From: Bruno Dumon [mailto:bruno@outerthought.org]
>> > > Sent: vrijdag 21 november 2003 21:10
>> > > To: users@cocoon.apache.org
>> > > Subject: RE: Woody - Determining the value for a widget
>> > >
>> > >
>> > > On Fri, 2003-11-21 at 20:29, Danny Bols wrote:
>> > > > > From: Bruno Dumon [mailto:bruno@outerthought.org]
>> > >
>> > > <snipped use cases I resonate with/>
>> > >
>> > > > > > > The question is whether we should consider a missing
>> > > request parameter
>> > > > > > > (value == null) the same as an empty value (value = "").
>> > > Currently,
>> > > > > > > they're considered to be equivalent and the field is
>> > > > > therefore nullified.
>> > > > > >
>> > > > > > You are right, there is a big difference between a parameter
>> > > > > which is not
>> > > > > > available on the request and a parameter which has an empty
>> > > > > value. So a +1
>> > > > > > for processing them differently and for not overriding widgets
>> > > > > with unwanted
>> > > > > > null values.
>> > > > >
>> > > > > It's more complicated then this. While this may work for
>> the default
>> > > > > renditions of the field widget (though I'm not sure the HTML
>> spec
>> > > > > requires empty fields to be submitted), it is for example
>> > > impossible to
>> > > > > do this for checkboxes. As suggested on the -dev ML a
>> while ago, this
>> > > > > could be solved by adding hidden id + ".present" fields
>> to the form
>> > > > > (though I don't like that very much from the HTTP-interface
>> > > > > perspective).
>> > > > >
>> > > > > This would also allow to detect if a composite widget is
>> not present,
>> > > > > i.e. if a repeater is not present at all, none of its
>> child widgets
>> > > > > would need to be further processed.
>> > > > >
>> > > > > Anyway, I'm -1 for any solution that would only work for
>> certain types
>> > > > > of widgets.
>> > > >
>> > > > I agree with you. But the clue is NOT to use hidden fields! Why
>> > > should we do
>> > > > that? Since we have woody there is a form object which
>> stores and cares
>> > > > about al the form data. Just put only those fields in the
>> template which
>> > > > have to be editable during that particular step of the
>> process. This is
>> > > > about using the strengths of a FORM instance an not having to
>> > > rely on a HTML
>> > > > spec which was not really designed for this kind of interaction.
>> > > > The basic principle is: ONE form object MULTIPLE templates/views.
>> > >
>> > > ok, got that. But how can we know, upon form submit, if a
>> certain field
>> > > was included in the request or not? This would indeed be
>> possible if we
>> > > knew what template was used in the publication pipeline. The
>> template
>> > > itself could however also be dynamic (i.e. generated by a
>> JXTemplate).
>> >
>> > I agree...we don't know which fields should be inculded in the
>> request. But
>> > does woody know this at this moment? I don't think so, woody
>> acts as if all
>> > the widgets should be availble by overwriting them with null
>> values if they
>> > aren't available. So IMHO the current version of woody doesn't have a
>> > solution for this either
>>
>> As said before in this thread, Woody doesn't support this indeed,
>> otherwise this thread wouldn't be here in the first place :-)
>> > Making a solid solution for this is very complicated: how would woody
>> > possibly know which fields should be available on the request?
>> And what do
>> > we get for it in return? .... still no guarantee on the values
>> of the fields
>> > on the request. I think we should be very pragmatical and not
>> overcomplicate
>> > processing and lose flexibility.
>>
>> But what's your solution then? It is not because there's no request
>> parameter, that there's no widget. OK, this might be true for a field
>> widget rendered as an <input> box, but it's not the case for checkboxes
>> (unchecked checkboxes do not give a request parameter). All I'm asking
>> for is a solution that will work for all types of widgets. If it's only
>> the checkbox which has this problem then maybe we could only use the
>> ".present" trick for widgets that can be rendered as checkboxes.
>
> The nice thing about the ".present" trick is that it also would work
> without
> the use of continuations. On the other hand I like the solution of Torsten
> to collect all the id's of the widgets in the WoodyTemplateTransformer and
> to put them in the continuation object which is a much cleaner approach.
> So a +1 for the Torsten approach now the relationship between woody and
> flow
> is becoming much closer.
-1 Because woody can be used without Flow. In fact some people use it
without flow. If we write it in "stone" then woody will ONLY work with or
highly depend on flow. Is this what we want?
For me this is not a good solution. Of course I use woody with flow.
Before make a decision, please let think this 2 times.
> OK. What do you think woody should do in case a form is configured as
> "secure" and the xslt removes widgets by accident?
I guess this would happen on devel time and not in production time, so the
developer need to take care of this. It is not a good sample at all.
Best Regards,
Antonio Gallardo.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
RE: Woody - Determining the value for a widget
Posted by Danny Bols <db...@osirion.be>.
> -----Original Message-----
> From: Bruno Dumon [mailto:bruno@outerthought.org]
> Sent: zondag 23 november 2003 22:12
> To: users@cocoon.apache.org
> Subject: RE: Woody - Determining the value for a widget
>
>
> On Sun, 2003-11-23 at 21:41, Danny Bols wrote:
> > > From: Bruno Dumon [mailto:bruno@outerthought.org]
> > > Sent: zaterdag 22 november 2003 16:48
> > > To: users@cocoon.apache.org
> > > Subject: RE: Woody - Determining the value for a widget
> > >
> > >
> > > On Sat, 2003-11-22 at 08:41, Danny Bols wrote:
> > > > > From: Bruno Dumon [mailto:bruno@outerthought.org]
> > > > > Sent: vrijdag 21 november 2003 21:10
> > > > > To: users@cocoon.apache.org
> > > > > Subject: RE: Woody - Determining the value for a widget
> > > > >
> > > > >
> > > > > On Fri, 2003-11-21 at 20:29, Danny Bols wrote:
> > > > > > > From: Bruno Dumon [mailto:bruno@outerthought.org]
> > > > >
> > > > > <snipped use cases I resonate with/>
> > > > >
> > > > > > > > > The question is whether we should consider a missing
> > > > > request parameter
> > > > > > > > > (value == null) the same as an empty value (value = "").
> > > > > Currently,
> > > > > > > > > they're considered to be equivalent and the field is
> > > > > > > therefore nullified.
> > > > > > > >
> > > > > > > > You are right, there is a big difference between a parameter
> > > > > > > which is not
> > > > > > > > available on the request and a parameter which has an empty
> > > > > > > value. So a +1
> > > > > > > > for processing them differently and for not
> overriding widgets
> > > > > > > with unwanted
> > > > > > > > null values.
> > > > > > >
> > > > > > > It's more complicated then this. While this may work for
> > > the default
> > > > > > > renditions of the field widget (though I'm not sure
> the HTML spec
> > > > > > > requires empty fields to be submitted), it is for example
> > > > > impossible to
> > > > > > > do this for checkboxes. As suggested on the -dev ML a
> > > while ago, this
> > > > > > > could be solved by adding hidden id + ".present" fields
> > > to the form
> > > > > > > (though I don't like that very much from the HTTP-interface
> > > > > > > perspective).
> > > > > > >
> > > > > > > This would also allow to detect if a composite widget is
> > > not present,
> > > > > > > i.e. if a repeater is not present at all, none of its
> > > child widgets
> > > > > > > would need to be further processed.
> > > > > > >
> > > > > > > Anyway, I'm -1 for any solution that would only work for
> > > certain types
> > > > > > > of widgets.
> > > > > >
> > > > > > I agree with you. But the clue is NOT to use hidden fields! Why
> > > > > should we do
> > > > > > that? Since we have woody there is a form object which
> > > stores and cares
> > > > > > about al the form data. Just put only those fields in the
> > > template which
> > > > > > have to be editable during that particular step of the
> > > process. This is
> > > > > > about using the strengths of a FORM instance an not having to
> > > > > rely on a HTML
> > > > > > spec which was not really designed for this kind of interaction.
> > > > > > The basic principle is: ONE form object MULTIPLE
> templates/views.
> > > > >
> > > > > ok, got that. But how can we know, upon form submit, if a
> > > certain field
> > > > > was included in the request or not? This would indeed be
> > > possible if we
> > > > > knew what template was used in the publication pipeline.
> The template
> > > > > itself could however also be dynamic (i.e. generated by a
> JXTemplate).
> > > >
> > > > I agree...we don't know which fields should be inculded in the
> > > request. But
> > > > does woody know this at this moment? I don't think so, woody
> > > acts as if all
> > > > the widgets should be availble by overwriting them with null
> > > values if they
> > > > aren't available. So IMHO the current version of woody
> doesn't have a
> > > > solution for this either
> > >
> > > As said before in this thread, Woody doesn't support this indeed,
> > > otherwise this thread wouldn't be here in the first place :-)
> > > > Making a solid solution for this is very complicated: how
> would woody
> > > > possibly know which fields should be available on the request?
> > > And what do
> > > > we get for it in return? .... still no guarantee on the values
> > > of the fields
> > > > on the request. I think we should be very pragmatical and not
> > > overcomplicate
> > > > processing and lose flexibility.
> > >
> > > But what's your solution then? It is not because there's no request
> > > parameter, that there's no widget. OK, this might be true for a field
> > > widget rendered as an <input> box, but it's not the case for
> checkboxes
> > > (unchecked checkboxes do not give a request parameter). All I'm asking
> > > for is a solution that will work for all types of widgets. If
> it's only
> > > the checkbox which has this problem then maybe we could only use the
> > > ".present" trick for widgets that can be rendered as checkboxes.
> >
> > The nice thing about the ".present" trick is that it also would
> work without
> > the use of continuations. On the other hand I like the solution
> of Torsten
> > to collect all the id's of the widgets in the
> WoodyTemplateTransformer and
> > to put them in the continuation object which is a much cleaner approach.
> > So a +1 for the Torsten approach now the relationship between
> woody and flow
> > is becoming much closer.
>
> I don't mind using the continuation for this purpose, but there should
> be an alternative for in case continuations are not available. But to
> repeat myself: if it's only the checkbox that has this 'problem', I'd go
> for the .present trick.
I don't know if the checkbox is the only stranger in town. A few other
thoughts that came up to me:
- Isn't using the ".present" trick less secure? It is possible to
manipulate(or even hack) ".present" fields in the request string. OTOH it
could also be a feature which gives the client the possibility to tell woody
which fields are present and which are not.
- I don't like the fact that we are leaning upon the HTTP spec for this
solution.
> > > > > Another solution Torsten Curdt came up with is that the
> > > > > WoodyTemplateTransformer could collect the id's of all
> widgets that it
> > > > > effectively put on the form, and attach this information to the
> > > > > flowscript continuation object. What I don't like about this
> > > (otherwise
> > > > > very smart) approach is that it is very thightly bound to the
> > > > > continuations concept.
> > > >
> > > > And what if my xslt skips certain fields based on their styling
> > > attributes?
> > >
> > > That would not be allowed. The role of the XSLT is to style
> widgets, not
> > > to remove them.
> >
> > OK. What do you think woody should do in case a form is configured as
> > "secure"
>
> What do you mean?
A "secure" form imo was a form in which woody should check all the request
parameters against the widgets transformed by the WoodyTemplateTransformer.
I was thinking to have this configurable.
> > and the xslt removes widgets by accident?
>
> that's a bug in the XSLT then.
Yep it would indeed be a bug......but it would be nice in that case if
woody would raise an exception so the developper knows about it.
--
Danny
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
RE: Woody - Determining the value for a widget
Posted by Bruno Dumon <br...@outerthought.org>.
On Sun, 2003-11-23 at 21:41, Danny Bols wrote:
> > From: Bruno Dumon [mailto:bruno@outerthought.org]
> > Sent: zaterdag 22 november 2003 16:48
> > To: users@cocoon.apache.org
> > Subject: RE: Woody - Determining the value for a widget
> >
> >
> > On Sat, 2003-11-22 at 08:41, Danny Bols wrote:
> > > > From: Bruno Dumon [mailto:bruno@outerthought.org]
> > > > Sent: vrijdag 21 november 2003 21:10
> > > > To: users@cocoon.apache.org
> > > > Subject: RE: Woody - Determining the value for a widget
> > > >
> > > >
> > > > On Fri, 2003-11-21 at 20:29, Danny Bols wrote:
> > > > > > From: Bruno Dumon [mailto:bruno@outerthought.org]
> > > >
> > > > <snipped use cases I resonate with/>
> > > >
> > > > > > > > The question is whether we should consider a missing
> > > > request parameter
> > > > > > > > (value == null) the same as an empty value (value = "").
> > > > Currently,
> > > > > > > > they're considered to be equivalent and the field is
> > > > > > therefore nullified.
> > > > > > >
> > > > > > > You are right, there is a big difference between a parameter
> > > > > > which is not
> > > > > > > available on the request and a parameter which has an empty
> > > > > > value. So a +1
> > > > > > > for processing them differently and for not overriding widgets
> > > > > > with unwanted
> > > > > > > null values.
> > > > > >
> > > > > > It's more complicated then this. While this may work for
> > the default
> > > > > > renditions of the field widget (though I'm not sure the HTML spec
> > > > > > requires empty fields to be submitted), it is for example
> > > > impossible to
> > > > > > do this for checkboxes. As suggested on the -dev ML a
> > while ago, this
> > > > > > could be solved by adding hidden id + ".present" fields
> > to the form
> > > > > > (though I don't like that very much from the HTTP-interface
> > > > > > perspective).
> > > > > >
> > > > > > This would also allow to detect if a composite widget is
> > not present,
> > > > > > i.e. if a repeater is not present at all, none of its
> > child widgets
> > > > > > would need to be further processed.
> > > > > >
> > > > > > Anyway, I'm -1 for any solution that would only work for
> > certain types
> > > > > > of widgets.
> > > > >
> > > > > I agree with you. But the clue is NOT to use hidden fields! Why
> > > > should we do
> > > > > that? Since we have woody there is a form object which
> > stores and cares
> > > > > about al the form data. Just put only those fields in the
> > template which
> > > > > have to be editable during that particular step of the
> > process. This is
> > > > > about using the strengths of a FORM instance an not having to
> > > > rely on a HTML
> > > > > spec which was not really designed for this kind of interaction.
> > > > > The basic principle is: ONE form object MULTIPLE templates/views.
> > > >
> > > > ok, got that. But how can we know, upon form submit, if a
> > certain field
> > > > was included in the request or not? This would indeed be
> > possible if we
> > > > knew what template was used in the publication pipeline. The template
> > > > itself could however also be dynamic (i.e. generated by a JXTemplate).
> > >
> > > I agree...we don't know which fields should be inculded in the
> > request. But
> > > does woody know this at this moment? I don't think so, woody
> > acts as if all
> > > the widgets should be availble by overwriting them with null
> > values if they
> > > aren't available. So IMHO the current version of woody doesn't have a
> > > solution for this either
> >
> > As said before in this thread, Woody doesn't support this indeed,
> > otherwise this thread wouldn't be here in the first place :-)
> > > Making a solid solution for this is very complicated: how would woody
> > > possibly know which fields should be available on the request?
> > And what do
> > > we get for it in return? .... still no guarantee on the values
> > of the fields
> > > on the request. I think we should be very pragmatical and not
> > overcomplicate
> > > processing and lose flexibility.
> >
> > But what's your solution then? It is not because there's no request
> > parameter, that there's no widget. OK, this might be true for a field
> > widget rendered as an <input> box, but it's not the case for checkboxes
> > (unchecked checkboxes do not give a request parameter). All I'm asking
> > for is a solution that will work for all types of widgets. If it's only
> > the checkbox which has this problem then maybe we could only use the
> > ".present" trick for widgets that can be rendered as checkboxes.
>
> The nice thing about the ".present" trick is that it also would work without
> the use of continuations. On the other hand I like the solution of Torsten
> to collect all the id's of the widgets in the WoodyTemplateTransformer and
> to put them in the continuation object which is a much cleaner approach.
> So a +1 for the Torsten approach now the relationship between woody and flow
> is becoming much closer.
I don't mind using the continuation for this purpose, but there should
be an alternative for in case continuations are not available. But to
repeat myself: if it's only the checkbox that has this 'problem', I'd go
for the .present trick.
> > > > Another solution Torsten Curdt came up with is that the
> > > > WoodyTemplateTransformer could collect the id's of all widgets that it
> > > > effectively put on the form, and attach this information to the
> > > > flowscript continuation object. What I don't like about this
> > (otherwise
> > > > very smart) approach is that it is very thightly bound to the
> > > > continuations concept.
> > >
> > > And what if my xslt skips certain fields based on their styling
> > attributes?
> >
> > That would not be allowed. The role of the XSLT is to style widgets, not
> > to remove them.
>
> OK. What do you think woody should do in case a form is configured as
> "secure"
What do you mean?
> and the xslt removes widgets by accident?
that's a bug in the XSLT then.
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org bruno@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
RE: Woody - Determining the value for a widget
Posted by Danny Bols <db...@osirion.be>.
> From: Bruno Dumon [mailto:bruno@outerthought.org]
> Sent: zaterdag 22 november 2003 16:48
> To: users@cocoon.apache.org
> Subject: RE: Woody - Determining the value for a widget
>
>
> On Sat, 2003-11-22 at 08:41, Danny Bols wrote:
> > > From: Bruno Dumon [mailto:bruno@outerthought.org]
> > > Sent: vrijdag 21 november 2003 21:10
> > > To: users@cocoon.apache.org
> > > Subject: RE: Woody - Determining the value for a widget
> > >
> > >
> > > On Fri, 2003-11-21 at 20:29, Danny Bols wrote:
> > > > > From: Bruno Dumon [mailto:bruno@outerthought.org]
> > >
> > > <snipped use cases I resonate with/>
> > >
> > > > > > > The question is whether we should consider a missing
> > > request parameter
> > > > > > > (value == null) the same as an empty value (value = "").
> > > Currently,
> > > > > > > they're considered to be equivalent and the field is
> > > > > therefore nullified.
> > > > > >
> > > > > > You are right, there is a big difference between a parameter
> > > > > which is not
> > > > > > available on the request and a parameter which has an empty
> > > > > value. So a +1
> > > > > > for processing them differently and for not overriding widgets
> > > > > with unwanted
> > > > > > null values.
> > > > >
> > > > > It's more complicated then this. While this may work for
> the default
> > > > > renditions of the field widget (though I'm not sure the HTML spec
> > > > > requires empty fields to be submitted), it is for example
> > > impossible to
> > > > > do this for checkboxes. As suggested on the -dev ML a
> while ago, this
> > > > > could be solved by adding hidden id + ".present" fields
> to the form
> > > > > (though I don't like that very much from the HTTP-interface
> > > > > perspective).
> > > > >
> > > > > This would also allow to detect if a composite widget is
> not present,
> > > > > i.e. if a repeater is not present at all, none of its
> child widgets
> > > > > would need to be further processed.
> > > > >
> > > > > Anyway, I'm -1 for any solution that would only work for
> certain types
> > > > > of widgets.
> > > >
> > > > I agree with you. But the clue is NOT to use hidden fields! Why
> > > should we do
> > > > that? Since we have woody there is a form object which
> stores and cares
> > > > about al the form data. Just put only those fields in the
> template which
> > > > have to be editable during that particular step of the
> process. This is
> > > > about using the strengths of a FORM instance an not having to
> > > rely on a HTML
> > > > spec which was not really designed for this kind of interaction.
> > > > The basic principle is: ONE form object MULTIPLE templates/views.
> > >
> > > ok, got that. But how can we know, upon form submit, if a
> certain field
> > > was included in the request or not? This would indeed be
> possible if we
> > > knew what template was used in the publication pipeline. The template
> > > itself could however also be dynamic (i.e. generated by a JXTemplate).
> >
> > I agree...we don't know which fields should be inculded in the
> request. But
> > does woody know this at this moment? I don't think so, woody
> acts as if all
> > the widgets should be availble by overwriting them with null
> values if they
> > aren't available. So IMHO the current version of woody doesn't have a
> > solution for this either
>
> As said before in this thread, Woody doesn't support this indeed,
> otherwise this thread wouldn't be here in the first place :-)
> > Making a solid solution for this is very complicated: how would woody
> > possibly know which fields should be available on the request?
> And what do
> > we get for it in return? .... still no guarantee on the values
> of the fields
> > on the request. I think we should be very pragmatical and not
> overcomplicate
> > processing and lose flexibility.
>
> But what's your solution then? It is not because there's no request
> parameter, that there's no widget. OK, this might be true for a field
> widget rendered as an <input> box, but it's not the case for checkboxes
> (unchecked checkboxes do not give a request parameter). All I'm asking
> for is a solution that will work for all types of widgets. If it's only
> the checkbox which has this problem then maybe we could only use the
> ".present" trick for widgets that can be rendered as checkboxes.
The nice thing about the ".present" trick is that it also would work without
the use of continuations. On the other hand I like the solution of Torsten
to collect all the id's of the widgets in the WoodyTemplateTransformer and
to put them in the continuation object which is a much cleaner approach.
So a +1 for the Torsten approach now the relationship between woody and flow
is becoming much closer.
> > > Another solution Torsten Curdt came up with is that the
> > > WoodyTemplateTransformer could collect the id's of all widgets that it
> > > effectively put on the form, and attach this information to the
> > > flowscript continuation object. What I don't like about this
> (otherwise
> > > very smart) approach is that it is very thightly bound to the
> > > continuations concept.
> >
> > And what if my xslt skips certain fields based on their styling
> attributes?
>
> That would not be allowed. The role of the XSLT is to style widgets, not
> to remove them.
OK. What do you think woody should do in case a form is configured as
"secure" and the xslt removes widgets by accident?
--
Danny
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
RE: Woody - Determining the value for a widget
Posted by Bruno Dumon <br...@outerthought.org>.
On Sat, 2003-11-22 at 08:41, Danny Bols wrote:
> > From: Bruno Dumon [mailto:bruno@outerthought.org]
> > Sent: vrijdag 21 november 2003 21:10
> > To: users@cocoon.apache.org
> > Subject: RE: Woody - Determining the value for a widget
> >
> >
> > On Fri, 2003-11-21 at 20:29, Danny Bols wrote:
> > > > From: Bruno Dumon [mailto:bruno@outerthought.org]
> >
> > <snipped use cases I resonate with/>
> >
> > > > > > The question is whether we should consider a missing
> > request parameter
> > > > > > (value == null) the same as an empty value (value = "").
> > Currently,
> > > > > > they're considered to be equivalent and the field is
> > > > therefore nullified.
> > > > >
> > > > > You are right, there is a big difference between a parameter
> > > > which is not
> > > > > available on the request and a parameter which has an empty
> > > > value. So a +1
> > > > > for processing them differently and for not overriding widgets
> > > > with unwanted
> > > > > null values.
> > > >
> > > > It's more complicated then this. While this may work for the default
> > > > renditions of the field widget (though I'm not sure the HTML spec
> > > > requires empty fields to be submitted), it is for example
> > impossible to
> > > > do this for checkboxes. As suggested on the -dev ML a while ago, this
> > > > could be solved by adding hidden id + ".present" fields to the form
> > > > (though I don't like that very much from the HTTP-interface
> > > > perspective).
> > > >
> > > > This would also allow to detect if a composite widget is not present,
> > > > i.e. if a repeater is not present at all, none of its child widgets
> > > > would need to be further processed.
> > > >
> > > > Anyway, I'm -1 for any solution that would only work for certain types
> > > > of widgets.
> > >
> > > I agree with you. But the clue is NOT to use hidden fields! Why
> > should we do
> > > that? Since we have woody there is a form object which stores and cares
> > > about al the form data. Just put only those fields in the template which
> > > have to be editable during that particular step of the process. This is
> > > about using the strengths of a FORM instance an not having to
> > rely on a HTML
> > > spec which was not really designed for this kind of interaction.
> > > The basic principle is: ONE form object MULTIPLE templates/views.
> >
> > ok, got that. But how can we know, upon form submit, if a certain field
> > was included in the request or not? This would indeed be possible if we
> > knew what template was used in the publication pipeline. The template
> > itself could however also be dynamic (i.e. generated by a JXTemplate).
>
> I agree...we don't know which fields should be inculded in the request. But
> does woody know this at this moment? I don't think so, woody acts as if all
> the widgets should be availble by overwriting them with null values if they
> aren't available. So IMHO the current version of woody doesn't have a
> solution for this either
As said before in this thread, Woody doesn't support this indeed,
otherwise this thread wouldn't be here in the first place :-)
> Making a solid solution for this is very complicated: how would woody
> possibly know which fields should be available on the request? And what do
> we get for it in return? .... still no guarantee on the values of the fields
> on the request. I think we should be very pragmatical and not overcomplicate
> processing and lose flexibility.
But what's your solution then? It is not because there's no request
parameter, that there's no widget. OK, this might be true for a field
widget rendered as an <input> box, but it's not the case for checkboxes
(unchecked checkboxes do not give a request parameter). All I'm asking
for is a solution that will work for all types of widgets. If it's only
the checkbox which has this problem then maybe we could only use the
".present" trick for widgets that can be rendered as checkboxes.
>
>
> > Another solution Torsten Curdt came up with is that the
> > WoodyTemplateTransformer could collect the id's of all widgets that it
> > effectively put on the form, and attach this information to the
> > flowscript continuation object. What I don't like about this (otherwise
> > very smart) approach is that it is very thightly bound to the
> > continuations concept.
>
> And what if my xslt skips certain fields based on their styling attributes?
That would not be allowed. The role of the XSLT is to style widgets, not
to remove them.
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org bruno@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
RE: Woody - Determining the value for a widget
Posted by Danny Bols <db...@osirion.be>.
> From: Bruno Dumon [mailto:bruno@outerthought.org]
> Sent: vrijdag 21 november 2003 21:10
> To: users@cocoon.apache.org
> Subject: RE: Woody - Determining the value for a widget
>
>
> On Fri, 2003-11-21 at 20:29, Danny Bols wrote:
> > > From: Bruno Dumon [mailto:bruno@outerthought.org]
>
> <snipped use cases I resonate with/>
>
> > > > > The question is whether we should consider a missing
> request parameter
> > > > > (value == null) the same as an empty value (value = "").
> Currently,
> > > > > they're considered to be equivalent and the field is
> > > therefore nullified.
> > > >
> > > > You are right, there is a big difference between a parameter
> > > which is not
> > > > available on the request and a parameter which has an empty
> > > value. So a +1
> > > > for processing them differently and for not overriding widgets
> > > with unwanted
> > > > null values.
> > >
> > > It's more complicated then this. While this may work for the default
> > > renditions of the field widget (though I'm not sure the HTML spec
> > > requires empty fields to be submitted), it is for example
> impossible to
> > > do this for checkboxes. As suggested on the -dev ML a while ago, this
> > > could be solved by adding hidden id + ".present" fields to the form
> > > (though I don't like that very much from the HTTP-interface
> > > perspective).
> > >
> > > This would also allow to detect if a composite widget is not present,
> > > i.e. if a repeater is not present at all, none of its child widgets
> > > would need to be further processed.
> > >
> > > Anyway, I'm -1 for any solution that would only work for certain types
> > > of widgets.
> >
> > I agree with you. But the clue is NOT to use hidden fields! Why
> should we do
> > that? Since we have woody there is a form object which stores and cares
> > about al the form data. Just put only those fields in the template which
> > have to be editable during that particular step of the process. This is
> > about using the strengths of a FORM instance an not having to
> rely on a HTML
> > spec which was not really designed for this kind of interaction.
> > The basic principle is: ONE form object MULTIPLE templates/views.
>
> ok, got that. But how can we know, upon form submit, if a certain field
> was included in the request or not? This would indeed be possible if we
> knew what template was used in the publication pipeline. The template
> itself could however also be dynamic (i.e. generated by a JXTemplate).
I agree...we don't know which fields should be inculded in the request. But
does woody know this at this moment? I don't think so, woody acts as if all
the widgets should be availble by overwriting them with null values if they
aren't available. So IMHO the current version of woody doesn't have a
solution for this either
Making a solid solution for this is very complicated: how would woody
possibly know which fields should be available on the request? And what do
we get for it in return? .... still no guarantee on the values of the fields
on the request. I think we should be very pragmatical and not overcomplicate
processing and lose flexibility.
> Another solution Torsten Curdt came up with is that the
> WoodyTemplateTransformer could collect the id's of all widgets that it
> effectively put on the form, and attach this information to the
> flowscript continuation object. What I don't like about this (otherwise
> very smart) approach is that it is very thightly bound to the
> continuations concept.
And what if my xslt skips certain fields based on their styling attributes?
> However, it would be quite easy to let the WoodyTemplateTransformer
> embed a hidden field (or something that is translated to a hidden field
> by the XSLT) in the form containing this list of widget id's (this would
> be done right before encountering the closing wt:form-template tag). So
> then we'd only need one hidden field, and it wouldn't be the
> responsibility of the XSLT to create them.
>
> This could be made optional so that if there isn't such a hidden field,
> the behaviour is as it is now.
I still have a problem with the current behaviour which overwrites field
values with null values if they are not available on the request string! If
I am not able to convince you at least I would plead to make this behaviour
configurable.
> > > > > Now this is debatable, furthermore considering that I
> envisioned to
> > > > > distinguish these two cases to raise an exception when a
> null-valued
> > > > > required field is not present on the request (see
> > > > > http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24180).
> > > >
> > > > The case discussed in here is about giving a form-designer a
> > > test tool for
> > > > static (=simple?) forms (template wt: is equal to design
> wd:). I hope we
> > > > will not block the way for more dynamic templates / interaction.
> > > >
> > > > What do you think?
> > >
> > > I've got some more thinking to do on all this, but
> unfortunately my time
> > > to spend on this is quite limitted. But don't hesitate to share any
> > > further ideas on this.
> >
> > Great to hear your comments! Petty of your time to spent though :-(
> > I am willing to share a bit of my valuable time on this when needed.
>
> Great.
;-)
--
Danny
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
RE: Woody - Determining the value for a widget
Posted by Bruno Dumon <br...@outerthought.org>.
On Fri, 2003-11-21 at 20:29, Danny Bols wrote:
> > From: Bruno Dumon [mailto:bruno@outerthought.org]
<snipped use cases I resonate with/>
> > > > The question is whether we should consider a missing request parameter
> > > > (value == null) the same as an empty value (value = ""). Currently,
> > > > they're considered to be equivalent and the field is
> > therefore nullified.
> > >
> > > You are right, there is a big difference between a parameter
> > which is not
> > > available on the request and a parameter which has an empty
> > value. So a +1
> > > for processing them differently and for not overriding widgets
> > with unwanted
> > > null values.
> >
> > It's more complicated then this. While this may work for the default
> > renditions of the field widget (though I'm not sure the HTML spec
> > requires empty fields to be submitted), it is for example impossible to
> > do this for checkboxes. As suggested on the -dev ML a while ago, this
> > could be solved by adding hidden id + ".present" fields to the form
> > (though I don't like that very much from the HTTP-interface
> > perspective).
> >
> > This would also allow to detect if a composite widget is not present,
> > i.e. if a repeater is not present at all, none of its child widgets
> > would need to be further processed.
> >
> > Anyway, I'm -1 for any solution that would only work for certain types
> > of widgets.
>
> I agree with you. But the clue is NOT to use hidden fields! Why should we do
> that? Since we have woody there is a form object which stores and cares
> about al the form data. Just put only those fields in the template which
> have to be editable during that particular step of the process. This is
> about using the strengths of a FORM instance an not having to rely on a HTML
> spec which was not really designed for this kind of interaction.
> The basic principle is: ONE form object MULTIPLE templates/views.
ok, got that. But how can we know, upon form submit, if a certain field
was included in the request or not? This would indeed be possible if we
knew what template was used in the publication pipeline. The template
itself could however also be dynamic (i.e. generated by a JXTemplate).
Another solution Torsten Curdt came up with is that the
WoodyTemplateTransformer could collect the id's of all widgets that it
effectively put on the form, and attach this information to the
flowscript continuation object. What I don't like about this (otherwise
very smart) approach is that it is very thightly bound to the
continuations concept.
However, it would be quite easy to let the WoodyTemplateTransformer
embed a hidden field (or something that is translated to a hidden field
by the XSLT) in the form containing this list of widget id's (this would
be done right before encountering the closing wt:form-template tag). So
then we'd only need one hidden field, and it wouldn't be the
responsibility of the XSLT to create them.
This could be made optional so that if there isn't such a hidden field,
the behaviour is as it is now.
> > > > Now this is debatable, furthermore considering that I envisioned to
> > > > distinguish these two cases to raise an exception when a null-valued
> > > > required field is not present on the request (see
> > > > http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24180).
> > >
> > > The case discussed in here is about giving a form-designer a
> > test tool for
> > > static (=simple?) forms (template wt: is equal to design wd:). I hope we
> > > will not block the way for more dynamic templates / interaction.
> > >
> > > What do you think?
> >
> > I've got some more thinking to do on all this, but unfortunately my time
> > to spend on this is quite limitted. But don't hesitate to share any
> > further ideas on this.
>
> Great to hear your comments! Petty of your time to spent though :-(
> I am willing to share a bit of my valuable time on this when needed.
Great.
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org bruno@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
RE: Woody - Determining the value for a widget
Posted by Bruno Dumon <br...@outerthought.org>.
On Fri, 2003-11-21 at 21:38, Timothy Larson wrote:
> --- Bruno Dumon <br...@outerthought.org> wrote:
> > On Fri, 2003-11-21 at 21:01, Timothy Larson wrote:
> > > So far, I lean toward using an *optional* set of explicit views.
> >
> > But with explicit views, you would still need to know what view was used
> > when a form is submitted, so the name of the view would then be embedded
> > in the form itself?
>
> True, but it is less hidden data to pass back and forth across the network
> or to store in the continuation. By the way, what if this data (either the
> view name or the list of widgets sent) could be stored in a hidden field
> or in the continuation?
Sure, might be possible, but I don't want this to be the only way since
I don't want woody to depend on continuations. But it would be easy
enough to do both, i.e. first check if the continuation has this
information, else check for a hidden request parameter, or else assume
all widgets were in the template.
> The decision could be made per form based on how
> much secure enforcement is needed (store in continuation) versus how much
> we offload from the server to the client (store in a hidden field).
>
> > A problem I see with explicit views is that they need to be static
> > (IIUC). I think a common use case will be that the template file is
> > processed by the JXTemplate generator and that some widgets will be
> > included conditionally.
>
> In some cases the view could be dynamically "static" using static
> expression of dynamic union semantics.
"some cases", yes, but not all.
> In this case the stored
> data (either in the continuation or a hidden field) would be the
> view name plus some parameters.
Seems like a lot of trouble to save some bytes... We could also zip the
list of id's to make it smaller. But anyway, if it can be stored in the
continuation, and since that is what most people will be using anyway,
then that seems like a good solution.
>
> > > This may even lead to the possibility of the view introducing
> > > view-specific widgets, driven by the same general set of needs
> > > that produced the aggregate widget.
> >
> > Could you expand a bit on this?
>
> Not a concrete thought, just a feeling. I will let you know if the
> idea gells into anything useful enough that I could express it.
ok
> The aggregate field and its inverse (which is not created yet) hold
> a concept that could live in the form definition or in a view or
> template.
The way I see it handling request parameters is exactly the purpose of a
widget, but I'm curious to what you can come up with.
> Currently it just happens to only live in the definition.
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org bruno@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
RE: Woody - Determining the value for a widget
Posted by Danny Bols <db...@osirion.be>.
> From: Timothy Larson [mailto:timlarsonwork@yahoo.com]
> Sent: vrijdag 21 november 2003 21:38
> To: users@cocoon.apache.org
> Subject: RE: Woody - Determining the value for a widget
>
>
> --- Bruno Dumon <br...@outerthought.org> wrote:
> > On Fri, 2003-11-21 at 21:01, Timothy Larson wrote:
> > > So far, I lean toward using an *optional* set of explicit views.
> >
> > But with explicit views, you would still need to know what view was used
> > when a form is submitted, so the name of the view would then be embedded
> > in the form itself?
>
> True, but it is less hidden data to pass back and forth across the network
> or to store in the continuation. By the way, what if this data
> (either the
> view name or the list of widgets sent) could be stored in a hidden field
> or in the continuation? The decision could be made per form based on how
> much secure enforcement is needed (store in continuation) versus how much
> we offload from the server to the client (store in a hidden field).
>
> > A problem I see with explicit views is that they need to be static
> > (IIUC). I think a common use case will be that the template file is
> > processed by the JXTemplate generator and that some widgets will be
> > included conditionally.
>
> In some cases the view could be dynamically "static" using static
> expression of dynamic union semantics. In this case the stored
> data (either in the continuation or a hidden field) would be the
> view name plus some parameters.
uuumm...I guess I miss the point...what do you mean with..."static
expression of dynamic union semantics"
--
Danny
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
RE: Woody - Determining the value for a widget
Posted by Timothy Larson <ti...@yahoo.com>.
--- Bruno Dumon <br...@outerthought.org> wrote:
> On Fri, 2003-11-21 at 21:01, Timothy Larson wrote:
> > So far, I lean toward using an *optional* set of explicit views.
>
> But with explicit views, you would still need to know what view was used
> when a form is submitted, so the name of the view would then be embedded
> in the form itself?
True, but it is less hidden data to pass back and forth across the network
or to store in the continuation. By the way, what if this data (either the
view name or the list of widgets sent) could be stored in a hidden field
or in the continuation? The decision could be made per form based on how
much secure enforcement is needed (store in continuation) versus how much
we offload from the server to the client (store in a hidden field).
> A problem I see with explicit views is that they need to be static
> (IIUC). I think a common use case will be that the template file is
> processed by the JXTemplate generator and that some widgets will be
> included conditionally.
In some cases the view could be dynamically "static" using static
expression of dynamic union semantics. In this case the stored
data (either in the continuation or a hidden field) would be the
view name plus some parameters.
> > This may even lead to the possibility of the view introducing
> > view-specific widgets, driven by the same general set of needs
> > that produced the aggregate widget.
>
> Could you expand a bit on this?
Not a concrete thought, just a feeling. I will let you know if the
idea gells into anything useful enough that I could express it.
The aggregate field and its inverse (which is not created yet) hold
a concept that could live in the form definition or in a view or
template. Currently it just happens to only live in the definition.
--Tim Larson
__________________________________
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
RE: Woody - Determining the value for a widget
Posted by Bruno Dumon <br...@outerthought.org>.
On Fri, 2003-11-21 at 21:01, Timothy Larson wrote:
> If we want to only send selected fields to the browser, and not
> all empty fields are guarantied to be sent back by the browser,
> then it seem we need to know which selected fields were sent so
> we will know which selected fields to process on return.
>
> To me this says we should either create explicit views of a form
> (to exist between the form definition and the form templates),
> or we need to collect (and possibly cache) the list of widgets
> that are in the template and use this list to drive the form's
> readFromRequest method.
yep, I was thinking the same.
> So far, I lean toward using an *optional* set of explicit views.
But with explicit views, you would still need to know what view was used
when a form is submitted, so the name of the view would then be embedded
in the form itself?
A problem I see with explicit views is that they need to be static
(IIUC). I think a common use case will be that the template file is
processed by the JXTemplate generator and that some widgets will be
included conditionally.
> This may even lead to the possibility of the view introducing
> view-specific widgets, driven by the same general set of needs
> that produced the aggregate widget.
Could you expand a bit on this?
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org bruno@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
RE: Woody - Determining the value for a widget
Posted by Danny Bols <db...@osirion.be>.
> From: Timothy Larson [mailto:timlarsonwork@yahoo.com]
> Sent: vrijdag 21 november 2003 21:02
> To: users@cocoon.apache.org
> Subject: RE: Woody - Determining the value for a widget
>
>
> If we want to only send selected fields to the browser, and not
> all empty fields are guarantied to be sent back by the browser,
> then it seem we need to know which selected fields were sent so
> we will know which selected fields to process on return.
What to you want to achieve with this? What would you do when some fields
are missing on the request? Overwrite the form values with null values (and
destroy critical data in the form object like woody does now?)....or produce
an exception? You never have any guarantee on what is being send back by the
browser and even if all the fields being send back are the ones you expected
you don't have any guarantee over the values.
What I am trying to make clear is that we shouldn't overcomplicate the
architecture and the form processing. IMHO we should only process those
fields which are available on the request.
> To me this says we should either create explicit views of a form
> (to exist between the form definition and the form templates),
> or we need to collect (and possibly cache) the list of widgets
> that are in the template and use this list to drive the form's
> readFromRequest method.
We shouldn't overcomplicate the architecture. To get a form up and running I
already have 5 files to maintain... the definition, the template, the
sitemap and the flow script! Introducing views would make it 6.
>
> So far, I lean toward using an *optional* set of explicit views.
> This may even lead to the possibility of the view introducing
> view-specific widgets, driven by the same general set of needs
> that produced the aggregate widget.
>
> WDYT?
I am not convinced about introducing views (see comments above). I could
imagine introducing an optional configurable transformer option though which
checks the fields being send back.
--
Danny
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
RE: Woody - Determining the value for a widget
Posted by Timothy Larson <ti...@yahoo.com>.
If we want to only send selected fields to the browser, and not
all empty fields are guarantied to be sent back by the browser,
then it seem we need to know which selected fields were sent so
we will know which selected fields to process on return.
To me this says we should either create explicit views of a form
(to exist between the form definition and the form templates),
or we need to collect (and possibly cache) the list of widgets
that are in the template and use this list to drive the form's
readFromRequest method.
So far, I lean toward using an *optional* set of explicit views.
This may even lead to the possibility of the view introducing
view-specific widgets, driven by the same general set of needs
that produced the aggregate widget.
WDYT?
--Tim Larson
__________________________________
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
RE: Woody - Determining the value for a widget
Posted by Danny Bols <db...@osirion.be>.
> From: Bruno Dumon [mailto:bruno@outerthought.org]
> Sent: vrijdag 21 november 2003 16:48
>
> On Thu, 2003-11-20 at 11:38, Danny Bols wrote:
> > If one wants to create a more dynamic user interface based on one single
> > woody form in which we give the user more control over the
> interaction it
> > would IMHO be bad design to put all the inivisble widgets on
> the request and
> > waste valuable processing time.
>
> The crucial part here is "based on one single woody form". Using
> multiple forms solves this, but your use case of hiding "detailed" stuff
> seems a good one (though even that could be solved by using two
> different forms, or putting the fields in a hidden div).
Operating in an environment with business critical data the crucial part is
indeed using only ONE form instance. In our case the "critical" business
data is loaded once into the form with the first request. During user(woody)
interaction we can not afford to take unwanted risks of synchronizing
multiple forms and templates and creating redundant data. A commit gives the
user the gurantee that the form data is written back in one single
transaction to avoid inconsistencies in the data store.
We don't use the technique of hidden fields or a hidden div because this
would lead to unnecessary processing (and risks of damaging critical data).
We simply put only those fields in a template which needs to be editable in
that step of the interaction.
> > Here are a few cases in which more dynamic user interfaces based on one
> > woody form are needed:
> > - switching between a "simple" and an "advanced" mode
> > - in case of a repeater switching between a "single row" and
> "multiple row"
> > mode
> > - a wizard-based interaction in which the user is guided step-by-step
> > through the different parts of a form
> >
> > We are using this kind of interaction by using different
> templates on the
> > same form which are tied together in flow script.
> >
> > See also my comments below.
> >
> > > -----Original Message-----
> > > From: news [mailto:news@sea.gmane.org]On Behalf Of Sylvain Wallez
> > > Sent: donderdag 20 november 2003 10:04
> > > To: users@cocoon.apache.org
> > > Subject: Re: Woody - Determining the value for a widget
> > >
> > >
> > > Danny Bols wrote:
> > >
> > > >Hello,
> > > >
> > > >it seems that if a field widget doesn't have a corresponding
> > > value in the request it's original value gets overidden with the
> > > null-value.
> > > >
> > > >Is this the way it should work or is it a slip of the pen in the
> > > Field.readFromRequest(formContext) method?
> > > >
> > > >
> > >
> > > The question is whether we should consider a missing request parameter
> > > (value == null) the same as an empty value (value = ""). Currently,
> > > they're considered to be equivalent and the field is
> therefore nullified.
> >
> > You are right, there is a big difference between a parameter
> which is not
> > available on the request and a parameter which has an empty
> value. So a +1
> > for processing them differently and for not overriding widgets
> with unwanted
> > null values.
>
> It's more complicated then this. While this may work for the default
> renditions of the field widget (though I'm not sure the HTML spec
> requires empty fields to be submitted), it is for example impossible to
> do this for checkboxes. As suggested on the -dev ML a while ago, this
> could be solved by adding hidden id + ".present" fields to the form
> (though I don't like that very much from the HTTP-interface
> perspective).
>
> This would also allow to detect if a composite widget is not present,
> i.e. if a repeater is not present at all, none of its child widgets
> would need to be further processed.
>
> Anyway, I'm -1 for any solution that would only work for certain types
> of widgets.
I agree with you. But the clue is NOT to use hidden fields! Why should we do
that? Since we have woody there is a form object which stores and cares
about al the form data. Just put only those fields in the template which
have to be editable during that particular step of the process. This is
about using the strengths of a FORM instance an not having to rely on a HTML
spec which was not really designed for this kind of interaction.
The basic principle is: ONE form object MULTIPLE templates/views.
> > > Now this is debatable, furthermore considering that I envisioned to
> > > distinguish these two cases to raise an exception when a null-valued
> > > required field is not present on the request (see
> > > http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24180).
> >
> > The case discussed in here is about giving a form-designer a
> test tool for
> > static (=simple?) forms (template wt: is equal to design wd:). I hope we
> > will not block the way for more dynamic templates / interaction.
> >
> > What do you think?
>
> I've got some more thinking to do on all this, but unfortunately my time
> to spend on this is quite limitted. But don't hesitate to share any
> further ideas on this.
Great to hear your comments! Petty of your time to spent though :-(
I am willing to share a bit of my valuable time on this when needed.
--
Danny
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
RE: Woody - Determining the value for a widget
Posted by Bruno Dumon <br...@outerthought.org>.
On Thu, 2003-11-20 at 11:38, Danny Bols wrote:
> If one wants to create a more dynamic user interface based on one single
> woody form in which we give the user more control over the interaction it
> would IMHO be bad design to put all the inivisble widgets on the request and
> waste valuable processing time.
The crucial part here is "based on one single woody form". Using
multiple forms solves this, but your use case of hiding "detailed" stuff
seems a good one (though even that could be solved by using two
different forms, or putting the fields in a hidden div).
>
> Here are a few cases in which more dynamic user interfaces based on one
> woody form are needed:
> - switching between a "simple" and an "advanced" mode
> - in case of a repeater switching between a "single row" and "multiple row"
> mode
> - a wizard-based interaction in which the user is guided step-by-step
> through the different parts of a form
>
> We are using this kind of interaction by using different templates on the
> same form which are tied together in flow script.
>
> See also my comments below.
>
> > -----Original Message-----
> > From: news [mailto:news@sea.gmane.org]On Behalf Of Sylvain Wallez
> > Sent: donderdag 20 november 2003 10:04
> > To: users@cocoon.apache.org
> > Subject: Re: Woody - Determining the value for a widget
> >
> >
> > Danny Bols wrote:
> >
> > >Hello,
> > >
> > >it seems that if a field widget doesn't have a corresponding
> > value in the request it's original value gets overidden with the
> > null-value.
> > >
> > >Is this the way it should work or is it a slip of the pen in the
> > Field.readFromRequest(formContext) method?
> > >
> > >
> >
> > The question is whether we should consider a missing request parameter
> > (value == null) the same as an empty value (value = ""). Currently,
> > they're considered to be equivalent and the field is therefore nullified.
>
> You are right, there is a big difference between a parameter which is not
> available on the request and a parameter which has an empty value. So a +1
> for processing them differently and for not overriding widgets with unwanted
> null values.
It's more complicated then this. While this may work for the default
renditions of the field widget (though I'm not sure the HTML spec
requires empty fields to be submitted), it is for example impossible to
do this for checkboxes. As suggested on the -dev ML a while ago, this
could be solved by adding hidden id + ".present" fields to the form
(though I don't like that very much from the HTTP-interface
perspective).
This would also allow to detect if a composite widget is not present,
i.e. if a repeater is not present at all, none of its child widgets
would need to be further processed.
Anyway, I'm -1 for any solution that would only work for certain types
of widgets.
> >
> > Now this is debatable, furthermore considering that I envisioned to
> > distinguish these two cases to raise an exception when a null-valued
> > required field is not present on the request (see
> > http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24180).
>
> The case discussed in here is about giving a form-designer a test tool for
> static (=simple?) forms (template wt: is equal to design wd:). I hope we
> will not block the way for more dynamic templates / interaction.
>
> What do you think?
I've got some more thinking to do on all this, but unfortunately my time
to spend on this is quite limitted. But don't hesitate to share any
further ideas on this.
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org bruno@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
RE: Woody - Determining the value for a widget
Posted by Danny Bols <db...@osirion.be>.
If one wants to create a more dynamic user interface based on one single
woody form in which we give the user more control over the interaction it
would IMHO be bad design to put all the inivisble widgets on the request and
waste valuable processing time.
Here are a few cases in which more dynamic user interfaces based on one
woody form are needed:
- switching between a "simple" and an "advanced" mode
- in case of a repeater switching between a "single row" and "multiple row"
mode
- a wizard-based interaction in which the user is guided step-by-step
through the different parts of a form
We are using this kind of interaction by using different templates on the
same form which are tied together in flow script.
See also my comments below.
> -----Original Message-----
> From: news [mailto:news@sea.gmane.org]On Behalf Of Sylvain Wallez
> Sent: donderdag 20 november 2003 10:04
> To: users@cocoon.apache.org
> Subject: Re: Woody - Determining the value for a widget
>
>
> Danny Bols wrote:
>
> >Hello,
> >
> >it seems that if a field widget doesn't have a corresponding
> value in the request it's original value gets overidden with the
> null-value.
> >
> >Is this the way it should work or is it a slip of the pen in the
> Field.readFromRequest(formContext) method?
> >
> >
>
> The question is whether we should consider a missing request parameter
> (value == null) the same as an empty value (value = ""). Currently,
> they're considered to be equivalent and the field is therefore nullified.
You are right, there is a big difference between a parameter which is not
available on the request and a parameter which has an empty value. So a +1
for processing them differently and for not overriding widgets with unwanted
null values.
>
> Now this is debatable, furthermore considering that I envisioned to
> distinguish these two cases to raise an exception when a null-valued
> required field is not present on the request (see
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24180).
The case discussed in here is about giving a form-designer a test tool for
static (=simple?) forms (template wt: is equal to design wd:). I hope we
will not block the way for more dynamic templates / interaction.
What do you think?
--
Danny
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Woody - Determining the value for a widget
Posted by Sylvain Wallez <sy...@apache.org>.
Danny Bols wrote:
>Hello,
>
>it seems that if a field widget doesn't have a corresponding value in the request it's original value gets overidden with the null-value.
>
>Is this the way it should work or is it a slip of the pen in the Field.readFromRequest(formContext) method?
>
>
The question is whether we should consider a missing request parameter
(value == null) the same as an empty value (value = ""). Currently,
they're considered to be equivalent and the field is therefore nullified.
Now this is debatable, furthermore considering that I envisioned to
distinguish these two cases to raise an exception when a null-valued
required field is not present on the request (see
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24180).
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org