Re: Learning from XForms

[Sylvain Wallez <sy...@apache.org>]

Daniel Fagerstrom wrote:

> Micah Dubinko wrote:
> <snip/>
>
>> I'm happy to learn whatever I can here.
>
>
> <snip/>
> Micah Dubinko wrote in another mail:
>
>> I want to get involved in Cocoon more, and wonder if this would be a 
>> good project to cut my teeth on. 
>
>
> Hi Micah (and the rest of the list)!
>
> There are certainly places in Cocoon where your help could be very 
> valuable, how about geting involved in Cocoon form handling ;)
>
> I hope I don't embarrass you by telling those on the list who don't 
> know (me until an hour ago e.g.) that Micah (http://dubinko.info/) 
> among other things is editor and author of the W3C XForms spec where 
> he has been involved for the last six years, author of an excelent 
> book about XForms (http://xformsinstitute.com/essentials/), and author 
> of numerous magazine articles.
>
> I thought about asking about your reaction to Sylvain's XForms-CForms 
> comparison 
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105881304808076&w=2 
> but found out that you already have started to write about that 
> http://dubinko.info/blog/2004/10.html#perm2004-10-13_xmlforms. I also 
> found http://wiki.apache.org/cocoon/XFormsInCocoon. Please do not be 
> shy ;), publish your ideas about such things here at the list, so that 
> we can discuss them.
>
> XForms in Cocoon
> ----------------
>
> There have been several different partial XForms implementations in or 
> related to Cocoon since 2000. ExFormula (Berin Loritsch), Precept 
> (Torsten Curdt), XMLForm (Ivan Ivanov), JXForm (Christopher Oliver). 
> They where essentially one man shows. XMLForm become quite popular but 
> it had a security problem and also a got a community issue when Ivan 
> decided to continue development in an own fork outside Cocoon. IIRC 
> Berin had some discussions at the XForms mail-list a number of years 
> ago about server side implementation and draw the conclussion that the 
> commity was mainly interested in client side implementation.
>
> After this experience and especially after Sylvain's letter, there 
> seem to have been a feeling in the community that XForms is not 
> relevant for Cocoon.


Let me correct this: in the now famous "XMLForms vs Woody" post, the 
conclusion wasn't that XForms was not relevant for Cocoon, but that the 
XForm event model was IMO too rich to be implemented in a simple and 
efficient manner by a server-side implementation.

Woody on the contrary was less ambitious, but had good foundations for a 
server-side form framework. It later evolved into the CForms we have 
today, which does have an event model which, although simple, fits many 
complex needs as it runs server side.

> IMHO, this might be a mistake. I sometimes got the impression that we 
> spend a lot of time to independently evolve things that are quite 
> close to what XForms allready does. And the last time I reviewed the 
> spec it seemed to me that the XForms event model would work well at 
> the server side also.


I shamely admit I haven't read the final version of the XForm spec :-/

> Now we can't switch form frame work every now and then in Cocoon. Our 
> users need stabillity and we as a community needs focus, and CForms is 
> an excelent form frame work in many ways. But I think that we can and 
> should make it much less monolitic and thus open it up for pluging in 
> new ideas into the frame work. Now it is rather all or nothing.
>
> We currently have a long discussion about, (among other things), how 
> to achieve a stricter model - view separation in CForms 
> (http://marc.theaimsgroup.com/?t=109941988300003&r=1&w=2, especially 
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=109960841308357&w=2). 
> The major point here is to put the conversion/rendering step (what you 
> call I18N formatting in your blog entry, and also identify as a major 
> issue), between the model and the view.
>
> Another thing is having a request processor that writes into the 
> widget tree instead of letting the widgets read from the request. This 
> makes it possible to plug in an XML based request processor instead of 
> the request parameters based, e.g.


The danger here is to fall again in the XMLForm trap, where all request 
parameters where checked to see if they corresponded to some valid XPath 
expression.

Note also that most widgets only call getParameter() on the request, and 
that we could easily cut that dependency by passing e.g. a Map 
implementation wrapping the request. That's what JSF does to abstract 
the request between servlet and portlet, as they have no abstraction of 
the environment as Cocoon does.

> In my view it is possible to break up the rather heavy widget 
> interface in more focused concern areas, and especially to give a more 
> focused model-view interface, without breaking back compabillity.


Could you elaborate on this?

> If we can achive this, it will be possible to use an XForms like user 
> interface, and still using the rest of the frame work. Or to plug in 
> an own e.g. DOM based widget hierarchy whith the existing UI.
>
> IIUC there is still work to do in formalizing the life cycle and the 
> event handling in CForms, it would be very interesting to see a 
> comparison with the event model in XForms.


Sure, comparisons are always interesting.

Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

Re: Learning from XForms

[Sylvain Wallez <sy...@apache.org>]

Daniel Fagerstrom wrote:

> Sylvain Wallez wrote:
>
>> Daniel Fagerstrom wrote:
>
>
> <snip/>
>
>>> After this experience and especially after Sylvain's letter, there 
>>> seem to have been a feeling in the community that XForms is not 
>>> relevant for Cocoon.
>>
>>
>> Let me correct this: in the now famous "XMLForms vs Woody" post, the 
>> conclusion wasn't that XForms was not relevant for Cocoon, but that 
>> the XForm event model was IMO too rich to be implemented in a simple 
>> and efficient manner by a server-side implementation. 
>
>
> Do you talk about the event model there? Anyway after your post 
> whether it was influential or not, (I would say it was), there have 
> been a concensus on the list among "key players" that XForms not is 
> suited for server side implementation (search the archive for XForms). 
> I don't know, but I am interested in Micah's opinion about it. The 
> Chiba guys think it is suitable for server side implementation and 
> maybe even prove it (http://chiba.sourceforge.net/features.html).
>
>> Woody on the contrary was less ambitious, but had good foundations 
>> for a server-side form framework. It later evolved into the CForms we 
>> have today, which does have an event model which, although simple, 
>> fits many complex needs as it runs server side. 
>
>
> Sure, I think it was the best choice back then. What I'm discussing 
> now is how to evolve our form processing so that we both keep back 
> compatibillity and makes it an open framework where we can plug in new 
> modules.
>
> <snip/>
>
>>>
>>> Another thing is having a request processor that writes into the 
>>> widget tree instead of letting the widgets read from the request. 
>>> This makes it possible to plug in an XML based request processor 
>>> instead of the request parameters based, e.g.
>>
>>
>> The danger here is to fall again in the XMLForm trap, where all 
>> request parameters where checked to see if they corresponded to some 
>> valid XPath expression.
>
>
> As long as one uses a separate form model, this danger can be avoided 
> by either letting the business model (or a binding framw work) pull 
> data from the form model, or by having a schema that restrict what can 
> be added to the form model.
>
> One can also use the mechanism that Jonas Ekstedt and also Reinhard 
> (http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106672364131946&w=2) 
> have proposed. One register all used widgets during form rendering and 
> then only read from registred widgets during request processing. With 
> this solution one is safe even without using a form model.
>
>> Note also that most widgets only call getParameter() on the request, 
>> and that we could easily cut that dependency by passing e.g. a Map 
>> implementation wrapping the request. That's what JSF does to abstract 
>> the request between servlet and portlet, as they have no abstraction 
>> of the environment as Cocoon does. 
>
>
> Might be a possiblity, the important thing is getting better separation.
>
>>> In my view it is possible to break up the rather heavy widget 
>>> interface in more focused concern areas, and especially to give a 
>>> more focused model-view interface, without breaking back compabillity.
>>
>>
>> Could you elaborate on this?
>
>
> Yes, my main interested ATM is give a better model-view separation in 
> the framework. Taking a look at e.g. your helper class for the JX 
> macro implementation, a subset of the interaface is used for rendering 
> the widget hierarchy. That part of the inteface could be factored out 
> to a separate interface.


Do you mean the widget tree crawling methods?

> In 
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=109960841308357&w=2, 
> I discuss what would be needed in a "populate" interface.


As I mentioned previously, either abstracting the request parameters 
through a Map could be a way to achieve this.

We could also add a setValue(String), but that may not be enough, as 
some widgets do more than reading a single value. For example, an action 
checks its own parameter (e.g. "ok"), but also parameters corresponding 
to an image button (i.e. "ok.x").

Furthermore, traversing the tree in order is important, as some 
containers prepare a context for their children. This is for example the 
case of repeater (creating rows if "repeater-id.size" is present) or 
aggregate-field that splits its request parameter and feeds its children.

> And also that convertion/rendering IMO should be done in a separate 
> component.


I agree with this. CForms convertors should be usable not only in CForms.

Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

Re: Learning from XForms

[Daniel Fagerstrom <da...@nada.kth.se>]

Sylvain Wallez wrote:

> Daniel Fagerstrom wrote:

<snip/>

>> After this experience and especially after Sylvain's letter, there 
>> seem to have been a feeling in the community that XForms is not 
>> relevant for Cocoon.
>
> Let me correct this: in the now famous "XMLForms vs Woody" post, the 
> conclusion wasn't that XForms was not relevant for Cocoon, but that 
> the XForm event model was IMO too rich to be implemented in a simple 
> and efficient manner by a server-side implementation. 

Do you talk about the event model there? Anyway after your post whether 
it was influential or not, (I would say it was), there have been a 
concensus on the list among "key players" that XForms not is suited for 
server side implementation (search the archive for XForms). I don't 
know, but I am interested in Micah's opinion about it. The Chiba guys 
think it is suitable for server side implementation and maybe even prove 
it (http://chiba.sourceforge.net/features.html).

> Woody on the contrary was less ambitious, but had good foundations for 
> a server-side form framework. It later evolved into the CForms we have 
> today, which does have an event model which, although simple, fits 
> many complex needs as it runs server side. 

Sure, I think it was the best choice back then. What I'm discussing now 
is how to evolve our form processing so that we both keep back 
compatibillity and makes it an open framework where we can plug in new 
modules.

<snip/>

>>
>> Another thing is having a request processor that writes into the 
>> widget tree instead of letting the widgets read from the request. 
>> This makes it possible to plug in an XML based request processor 
>> instead of the request parameters based, e.g.
>
> The danger here is to fall again in the XMLForm trap, where all 
> request parameters where checked to see if they corresponded to some 
> valid XPath expression.

As long as one uses a separate form model, this danger can be avoided by 
either letting the business model (or a binding framw work) pull data 
from the form model, or by having a schema that restrict what can be 
added to the form model.

One can also use the mechanism that Jonas Ekstedt and also Reinhard 
(http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106672364131946&w=2) 
have proposed. One register all used widgets during form rendering and 
then only read from registred widgets during request processing. With 
this solution one is safe even without using a form model.

> Note also that most widgets only call getParameter() on the request, 
> and that we could easily cut that dependency by passing e.g. a Map 
> implementation wrapping the request. That's what JSF does to abstract 
> the request between servlet and portlet, as they have no abstraction 
> of the environment as Cocoon does. 

Might be a possiblity, the important thing is getting better separation.

>> In my view it is possible to break up the rather heavy widget 
>> interface in more focused concern areas, and especially to give a 
>> more focused model-view interface, without breaking back compabillity.
>
> Could you elaborate on this?

Yes, my main interested ATM is give a better model-view separation in 
the framework. Taking a look at e.g. your helper class for the JX macro 
implementation, a subset of the interaface is used for rendering the 
widget hierarchy. That part of the inteface could be factored out to a 
separate interface. In 
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=109960841308357&w=2, I 
discuss what would be needed in a "populate" interface. And also that 
convertion/rendering IMO should be done in a separate component. These 
are examples of more focused concern areas. By splitting the widget 
interface in a number of sub interfaces it would be easier to replace 
one of the components with something else.
<snip/>

/Daniel

Re: CForms Wizards

[Sylvain Wallez <sy...@apache.org>]

Sylvain Wallez wrote:

> That could be something like:
>
> function validateWizard() {
>  currentPage.setState(WidgetState.INVISIBLE); // another one may be 
> chosen below
>  for (page in pageList) {
>    page.setState(WidgetState.ACTIVE);
>    if (page.validate()) {
>      page.setState(WidgetState.INVISIBLE);
>    } else {
>      return false; // validation failed
>    }
>  }


return true; // all pages validated

> }


Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

Re: CForms Wizards

[Daniel Fagerstrom <da...@nada.kth.se>]

Sylvain Wallez wrote:

> Daniel Fagerstrom wrote:
>
>> Sylvain Wallez wrote:
>>
>>> Daniel Fagerstrom wrote:
>>
<snip/>

>> Sure, IMO, you should always do a complete validation of _all_ 
>> widgets before binding your form model to business data. There is the 
>> same problem with widget states, you can have faulty event logic so 
>> that you happens to hide some subtree during all states in the 
>> filling in of the multi form.
>
> Sure, but forgetting a whole subform within the event handling is less 
> likely to happen than forgetting a single widget in the template.

The complete validation will let you know if there is a forgotten field.

> Furthermore, we can automate the subform navigation and validation, 
> not only using <fd:wizard-action> but also using a new <fd:wizard> 
> container that would automatically iterate among its children (which 
> are likely to be <fd:struct> themselves).

Might be. The important question is IMO how to separate the different 
concern areas in multi page forms. My view is that:

* What you want to show in each sub form is a view concern and should be 
handled of the view layer e.g. JXTG with taglib.

* The control of the sub form flow is a control concern, and should be 
handled by the control layer, i.e. flowscripts.

* The model is responsible for the data structure and validation. In my 
view the widget hierarchy should mainly be responsible for model concerns.

I'm of course aware of that there are gray areas where it is hard or 
maybe impractical to place a functionality in M, V or C. But I find it 
hard to be entusiastic about evolving the form definition to a mix of M, 
V and C concerns.

>> So, partial validation is used after each sub form in a wizard to 
>> give immediate feedback. Then complete validation is done before 
>> using the data. This is IMO the only safe option.
>
> Exactly. But with template-driven wizard, you don't know where to go 
> back if validation fails, whereas with definition-driven wizard, we 
> simply redisplay the first invalid subcontainer. Or will you keep the 
> list of used widgets with each step to find where a widget was firstly 
> used?

You should never be alowed to pass an invalid sub form, you can go 
backwards from it not forward. Or are you thinking about some 
backtracking engine where the user fill in a value in sub form 10 that 
not is consistent with something on sub form 2 that makes sub form 2 
redisplayed and then the user have to try to go through the sub forms 
again. In that case: to much magic for my taste.

>>> Also, this behaviour only validates terminal widgets and no 
>>> container widgets, which may carry some additional semantic checks 
>>> like row uniqueness in a repeater.
>>
>> I'm aware of that as you can see in the bugzilla comment, and have 
>> not thought that much about of it yet. One possibillity could be to 
>> let value change "bubble" and let the container validators trigger on 
>> child events. Any other ideas? I have not used container validators 
>> yet, so I don't know that much about the use cases.
>
> The current behaviour is recursive depth-first validation, i.e. a 
> container triggers its own validators if all of its children are 
> valid. I'm not sure bubbling could do the trick, as validation is 
> handled separately from value-changed events, and we have to know 
> where to stop bubbling. Bubbling up to the Form is likely not to work, 
> as validation will fail on required fields that weren't in the template.

What I mean is that container validation is trigered by validation event 
bubling. If you introduce container level bubling you must of course 
design your UI so that you are able to fill in the fields within the 
container and see the validation error in the same screen.
 
<snip/>

>> If we can find a good solution of the parent validation problem, it 
>> is rather usefull as we only need to tell about what widgets that we 
>> want to validate once, in the view. Furthermore, even if I have no 
>> immediate need for that, Jonas has shown that it makes it safe to use 
>> a form frame work without having a form model in between the view and 
>> the "business data".
>
> Uh, no form model and still safe? I missed that...

Yes, and you can do more cool things. In Chiba they use an adapter in 
the view that replaces the XPaths in the HTML output from the view with 
some kind of  random identifyers and register the mapping in a lookup 
table, that is used in the request processor. In this way you have no 
info about the model at all in what you send to the browser.

>>> Furthermore, flowscript back-button magic implies that we can only 
>>> navigate back to the previous screen, and not in an arbitrary screen 
>>> in the sequence.
>>
>> I implemented it in that way because I didn't had any use cases for 
>> something more complicated. But you can send a "go back" message 
>> together with a web continuation id to the form handler, by using 
>> that the form handler can first save the current form data and then 
>> jumping to any previous continuation. I'll explain the details in the 
>> above promised "back-button magic" RT.
>
> Things I don't like in this back-button magic:
> - not all forms are wizard, rather the contrary. So having the wizard 
> engine plugged in deep in CForms doesn't seem good to mee.

It will not disturb you if you don't use it.

> - it's magic, meaning the fact that the user can go back is even not 
> apparent in the flowscript.

We can add pluggable event handlers in the form handler so that the user 
can plug in other control flow events.

> - it is limited to CForms only, meaning if other pages are placed 
> inbetween (regular pages, other form handling, etc), they cannot 
> participate in the wizard navigation.

In the implementation I provided, it should be possible AFAIK.

> We had such a discussion one year ago and at that time I proposed a 
> wizard API [1] that makes use of bookmarks and PageLocal (that did not 
> existed at that time). Such a wizard API would make the fact that a 
> wizard-style interaction is setup explicit in the flowscript, without 
> requiring much more coding, especially if we integrate CForms in the 
> wizard API (rather than putting wizards in CForms).

<snip what="example"/>

> This approach allows to use wizard-style navigation with any kind of 
> page, and not only forms. And if we want to go further, we could even 
> make wizards a built-in feature of flowscript, i.e. add some methods 
> to the "cocoon" object such as:
> - cocoon.startWizard()
> - cocoon.wizardStep(name)
> - cocoon.finishWizard() // to invalidate all continuations in a wizard
>
> The backwards navigation could then be handled automatically by the 
> sendPageAndWait() method. Yes, that would be magic as you'll have 
> nothing special to write, except "cocoon.startWizard()", which 
> implictely says "let's start the magic, I know it will happen from now 
> on".

An excelent idea, I will give it a look. I would also prefer to have 
some kind of high level library for different flow cases. The low level 
coding with continuations is far to complicated and error proon. 
Continuations are like gotos on steroids. They are excelent for 
implementing high level control structures, but the user should not need 
to know about them or use them.

<snip/>

>> Either you decide what should be shown together in the view or in the 
>> model. You get <jx:if> (or separate templates), in the first case and 
>> fd:structs in the second. IMHO it is better to code view aspects, 
>> like what should be shown in the same sub view, in the view than in 
>> the model. It will be easier to reuse the model for several views, 
>> e.g. specialist view (one screen), wizard view and pda wizard view, 
>> if you don't put the view groupings in the model.
>
> Mmmh... I agree and disagree at the same time :-)
>
> The various widgets that will be presented in a multi-page navigation 
> will be grouped by their relations, i.e. a page will show a consistent 
> set of related data. And when displaying the same data in a single 
> page, it's very likely that the same grouping will be used to lay out 
> the page, using e.g. <fieldset> elements.
>
> In that case, the difference between the multi-page and single-page 
> templates will be that only one of these groups will be visible a one 
> time in the multi-page template.

Grouping of data is a good thing. But it is not obvious how to create a 
hierachic grouping of the data for two different wizards in such away 
that you get one group per sub form.

<snip/>

>> :) So we booth belive that multi chanel wizards mainly should affect 
>> the view. But you want AFAIU to have event based flow control in the 
>> model and I prefer to have flowscript based flow control.
>
> The event-driven model allows to have the *exact same* flowscript 
> whether the form is displayed in a single page or across multiple 
> pages. This is important in a multi-channel application as, although 
> the view will be different, the application logic should be the same 
> whatever kind of browser the user has.

Flowscripts where introduced in Cocoon for describing page flow so you 
are not supposed to reuse the part of your flowscript that describe the 
flow as that happen to be _the description_ of the page flow.

<snip/>

>> A problem with coding where we are in the wizard, booth as a widget 
>> state and a flowscript state (i.e. where we are in the form handling 
>> loop), is that previous continuations might get inconsistent. What 
>> happens if the user happens to use the browser back button in a 
>> widget state based wizard e.g.
>
> Using a single continuation within the form.showForm loop (which would 
> therefore no more be formally a loop) may be a way to handle this.

Tried that in my form.showForm loop, (that is implemented that way), and 
the browser backbutton behaviour is still flawed.

/Daniel

Re: CForms Wizards

[Sylvain Wallez <sy...@apache.org>]

Daniel Fagerstrom wrote:

> Sylvain Wallez wrote:
>
>> Daniel Fagerstrom wrote:
>
> <snip/>
>
>>> Take a look at 
>>> http://issues.apache.org/bugzilla/show_bug.cgi?id=32169 where I have 
>>> enhanced work of Jonas Ekstedt so that one can do the kind of things 
>>> you asked for in the section about multi page forms in 
>>> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106672364131946&w=2.
>>>
>>> So now it is possible to write CForms wizards by writing javascript 
>>> FSMs in the form definition using widget states. Or if you prefer, 
>>> by using flowscript back-button magic, and automatic selection of 
>>> what is validated based on what widgets you use in your template.
>>
>
> Before I answer I'd like to point out that the bugzilla entry 
> illustrates two different things: flowscript "back-button magic" for 
> CForms and "validating what's in the template". Even if they in 
> combination IMO is a very promising candidate for having easy to wrte 
> multi page wizards in Cocon, they can be evaluated and used separatly.


Sure.

> The flowscript stuff can be used together with widget states and could 
> be put into the trunk quite soon. A better metod for communicating 
> between the form and the flow script form handling code is needed 
> first. And I would also prefer to discuss the code and idea a little 
> bit first as it is intricate stuff. I will hopefully find time to 
> write an RT about the details soon.
>
> The "validating what's in the template" is IMO promising stuff and is 
> part of the CForms refactoring vision, that I talk about all the time 
> ;) But it is not ready for prime time yet. It is on going work.
>
>> There's a problem by validating what's in the template, IMO: this 
>> means that if the template is wrong, i.e. it misses some important 
>> widget defined by the form, the form will be incorrectly considered 
>> valid.
>
>
> Sure, IMO, you should always do a complete validation of _all_ widgets 
> before binding your form model to business data. There is the same 
> problem with widget states, you can have faulty event logic so that 
> you happens to hide some subtree during all states in the filling in 
> of the multi form.


Sure, but forgetting a whole subform within the event handling is less 
likely to happen than forgetting a single widget in the template. 
Furthermore, we can automate the subform navigation and validation, not 
only using <fd:wizard-action> but also using a new <fd:wizard> container 
that would automatically iterate among its children (which are likely to 
be <fd:struct> themselves).

> So, partial validation is used after each sub form in a wizard to give 
> immediate feedback. Then complete validation is done before using the 
> data. This is IMO the only safe option.


Exactly. But with template-driven wizard, you don't know where to go 
back if validation fails, whereas with definition-driven wizard, we 
simply redisplay the first invalid subcontainer. Or will you keep the 
list of used widgets with each step to find where a widget was firstly used?

>> Also, this behaviour only validates terminal widgets and no container 
>> widgets, which may carry some additional semantic checks like row 
>> uniqueness in a repeater.
>
>
> I'm aware of that as you can see in the bugzilla comment, and have not 
> thought that much about of it yet. One possibillity could be to let 
> value change "bubble" and let the container validators trigger on 
> child events. Any other ideas? I have not used container validators 
> yet, so I don't know that much about the use cases.


The current behaviour is recursive depth-first validation, i.e. a 
container triggers its own validators if all of its children are valid. 
I'm not sure bubbling could do the trick, as validation is handled 
separately from value-changed events, and we have to know where to stop 
bubbling. Bubbling up to the Form is likely not to work, as validation 
will fail on required fields that weren't in the template.

>> So although reading only widgets present in the original template may 
>> make sense, using that same widget list for validation is wrong. 
>
>
> Wrong. based on missing parent validation, or are there further reasons?


Yes, missing parent validation, and also the difficulty to detect faulty 
wizard pages and going back to them.

>> And again, registering this list of used widgets will become useless 
>> once widgets don't reset their values if their corresponding 
>> parameter is not present. I'm just waiting for the release before 
>> adding this new feature.
>
>
> Wrong and useless, you are using strong words Sylvain ;)


Well, yes because I see too many potential problems with this approach 
compared to the apparent simplicity it brings!

> If we can find a good solution of the parent validation problem, it is 
> rather usefull as we only need to tell about what widgets that we want 
> to validate once, in the view. Furthermore, even if I have no 
> immediate need for that, Jonas has shown that it makes it safe to use 
> a form frame work without having a form model in between the view and 
> the "business data".


Uh, no form model and still safe? I missed that...

>> Furthermore, flowscript back-button magic implies that we can only 
>> navigate back to the previous screen, and not in an arbitrary screen 
>> in the sequence.
>
>
> I implemented it in that way because I didn't had any use cases for 
> something more complicated. But you can send a "go back" message 
> together with a web continuation id to the form handler, by using that 
> the form handler can first save the current form data and then jumping 
> to any previous continuation. I'll explain the details in the above 
> promised "back-button magic" RT.


Things I don't like in this back-button magic:
- not all forms are wizard, rather the contrary. So having the wizard 
engine plugged in deep in CForms doesn't seem good to mee.
- it's magic, meaning the fact that the user can go back is even not 
apparent in the flowscript.
- it is limited to CForms only, meaning if other pages are placed 
inbetween (regular pages, other form handling, etc), they cannot 
participate in the wizard navigation.

We had such a discussion one year ago and at that time I proposed a 
wizard API [1] that makes use of bookmarks and PageLocal (that did not 
existed at that time). Such a wizard API would make the fact that a 
wizard-style interaction is setup explicit in the flowscript, without 
requiring much more coding, especially if we integrate CForms in the 
wizard API (rather than putting wizards in CForms).

Example:

function myWizard() {

    var form = new Form("blah.xml");

    var wizard = new Wizard();
    // allow showForm() to handle wizard navigation
    form.setWizard(wizard);

    wizard.markStep("step1");
    form.showForm("foo1.html");

    wizard.markStep("step2");
    cocoon.sendPageAndWait("dialog.html", {wizard:wizard}");
    wizard.handleNavigation();

    wizard.markStep("step3");
    form.showForm("foo3.html");

    ... etc ...
}

The "markStep()" method is used to create a named continuation that can 
later be used to go back to any previous step in the navigation chain.

This approach allows to use wizard-style navigation with any kind of 
page, and not only forms. And if we want to go further, we could even 
make wizards a built-in feature of flowscript, i.e. add some methods to 
the "cocoon" object such as:
- cocoon.startWizard()
- cocoon.wizardStep(name)
- cocoon.finishWizard() // to invalidate all continuations in a wizard

The backwards navigation could then be handled automatically by the 
sendPageAndWait() method. Yes, that would be magic as you'll have 
nothing special to write, except "cocoon.startWizard()", which 
implictely says "let's start the magic, I know it will happen from now on".

That proposal may seem rather in opposition with the state-driven wizard 
sample I wrote, but I think not. Flowscript-level wizards are useful for 
complex interactions and navigation, whereas form-level wizards are 
useful to simply split a large form throughout several screens, when 
there is no need for navigation decision (i.e. the next screen doesn't 
depend on values in the current or previous screens). Think of it as a 
server-side handling of form tabs (see the form1 sample in CForms).

>>> But in the later case you miss the joy of writing all the javascript 
>>> event handling code ;)
>>
>>
>> Sure, but you still need a lot of <jx:if> in the template, wheareas 
>> activating/hiding groups means you just declare all groups 
>> (fd:struct) in the template and it adapts automatically.
>
>
> Either you decide what should be shown together in the view or in the 
> model. You get <jx:if> (or separate templates), in the first case and 
> fd:structs in the second. IMHO it is better to code view aspects, like 
> what should be shown in the same sub view, in the view than in the 
> model. It will be easier to reuse the model for several views, e.g. 
> specialist view (one screen), wizard view and pda wizard view, if you 
> don't put the view groupings in the model.


Mmmh... I agree and disagree at the same time :-)

The various widgets that will be presented in a multi-page navigation 
will be grouped by their relations, i.e. a page will show a consistent 
set of related data. And when displaying the same data in a single page, 
it's very likely that the same grouping will be used to lay out the 
page, using e.g. <fieldset> elements.

In that case, the difference between the multi-page and single-page 
templates will be that only one of these groups will be visible a one 
time in the multi-page template.

>> And while writing the sample, some new <fd:wizard-action> widgets 
>> with builtin event handling popped up in my head, just like we have 
>> today <fd:repeater-action> and <fd:row-action>. No more javascript 
>> event-handling, no <jx:if>.
>
>
> Seem like good ideas.
>
>> One last point also: being able to split a form across multiple page 
>> may allow for multi-channel forms, where the full form is shown on a 
>> regular browser, whereas it is split across several pages for PDAs or 
>> phones. That split can be decided by the view, choosing the 
>> appropriate template depending on the browser type, with no impact on 
>> the flowscript which will just have a single form.showForm().
>
>
> :) So we booth belive that multi chanel wizards mainly should affect 
> the view. But you want AFAIU to have event based flow control in the 
> model and I prefer to have flowscript based flow control.


The event-driven model allows to have the *exact same* flowscript 
whether the form is displayed in a single page or across multiple pages. 
This is important in a multi-channel application as, although the view 
will be different, the application logic should be the same whatever 
kind of browser the user has.

> We introduced flowscripts in Cocoon once because we thought that it 
> was a better way to control flow in e.g. wizards than using FSMs, were 
> we wrong?


Certainly not! But there may be a need for lower-level controllers, 
which in that case is implemented in a event-driven way by using 
continuations to handle those events.

> A problem with coding where we are in the wizard, booth as a widget 
> state and a flowscript state (i.e. where we are in the form handling 
> loop), is that previous continuations might get inconsistent. What 
> happens if the user happens to use the browser back button in a widget 
> state based wizard e.g.


Using a single continuation within the form.showForm loop (which would 
therefore no more be formally a loop) may be a way to handle this.

> Anyway, thanks for evaluating the proposal and comming with 
> constructive critic. I have some interesting new things to consider :)


Sure!

Sylvain

[1] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106683720017320&w=2

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

Re: CForms Wizards

[Daniel Fagerstrom <da...@nada.kth.se>]

Sylvain Wallez wrote:
> Daniel Fagerstrom wrote:
<snip/>
>> Take a look at http://issues.apache.org/bugzilla/show_bug.cgi?id=32169 
>> where I have enhanced work of Jonas Ekstedt so that one can do the 
>> kind of things you asked for in the section about multi page forms in 
>> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106672364131946&w=2.
>>
>> So now it is possible to write CForms wizards by writing javascript 
>> FSMs in the form definition using widget states. Or if you prefer, by 
>> using flowscript back-button magic, and automatic selection of what is 
>> validated based on what widgets you use in your template.

Before I answer I'd like to point out that the bugzilla entry 
illustrates two different things: flowscript "back-button magic" for 
CForms and "validating what's in the template". Even if they in 
combination IMO is a very promising candidate for having easy to wrte 
multi page wizards in Cocon, they can be evaluated and used separatly.

The flowscript stuff can be used together with widget states and could 
be put into the trunk quite soon. A better metod for communicating 
between the form and the flow script form handling code is needed first. 
And I would also prefer to discuss the code and idea a little bit first 
as it is intricate stuff. I will hopefully find time to write an RT 
about the details soon.

The "validating what's in the template" is IMO promising stuff and is 
part of the CForms refactoring vision, that I talk about all the time ;) 
But it is not ready for prime time yet. It is on going work.

> There's a problem by validating what's in the template, IMO: this means 
> that if the template is wrong, i.e. it misses some important widget 
> defined by the form, the form will be incorrectly considered valid.

Sure, IMO, you should always do a complete validation of _all_ widgets 
before binding your form model to business data. There is the same 
problem with widget states, you can have faulty event logic so that you 
happens to hide some subtree during all states in the filling in of the 
multi form.

So, partial validation is used after each sub form in a wizard to give 
immediate feedback. Then complete validation is done before using the 
data. This is IMO the only safe option.

> Also, this behaviour only validates terminal widgets and no container 
> widgets, which may carry some additional semantic checks like row 
> uniqueness in a repeater.

I'm aware of that as you can see in the bugzilla comment, and have not 
thought that much about of it yet. One possibillity could be to let 
value change "bubble" and let the container validators trigger on child 
events. Any other ideas? I have not used container validators yet, so I 
don't know that much about the use cases.

> So although reading only widgets present in the original template may 
> make sense, using that same widget list for validation is wrong. 

Wrong. based on missing parent validation, or are there further reasons?

> And 
> again, registering this list of used widgets will become useless once 
> widgets don't reset their values if their corresponding parameter is not 
> present. I'm just waiting for the release before adding this new feature.

Wrong and useless, you are using strong words Sylvain ;)

If we can find a good solution of the parent validation problem, it is 
rather usefull as we only need to tell about what widgets that we want 
to validate once, in the view. Furthermore, even if I have no immediate 
need for that, Jonas has shown that it makes it safe to use a form frame 
work without having a form model in between the view and the "business 
data".

> Furthermore, flowscript back-button magic implies that we can only 
> navigate back to the previous screen, and not in an arbitrary screen in 
> the sequence.

I implemented it in that way because I didn't had any use cases for 
something more complicated. But you can send a "go back" message 
together with a web continuation id to the form handler, by using that 
the form handler can first save the current form data and then jumping 
to any previous continuation. I'll explain the details in the above 
promised "back-button magic" RT.

>> But in the later case you miss the joy of writing all the javascript 
>> event handling code ;)
> 
> Sure, but you still need a lot of <jx:if> in the template, wheareas 
> activating/hiding groups means you just declare all groups (fd:struct) 
> in the template and it adapts automatically.

Either you decide what should be shown together in the view or in the 
model. You get <jx:if> (or separate templates), in the first case and 
fd:structs in the second. IMHO it is better to code view aspects, like 
what should be shown in the same sub view, in the view than in the 
model. It will be easier to reuse the model for several views, e.g. 
specialist view (one screen), wizard view and pda wizard view, if you 
don't put the view groupings in the model.

> And while writing the sample, some new <fd:wizard-action> widgets with 
> builtin event handling popped up in my head, just like we have today 
> <fd:repeater-action> and <fd:row-action>. No more javascript 
> event-handling, no <jx:if>.

Seem like good ideas.

> One last point also: being able to split a form across multiple page may 
> allow for multi-channel forms, where the full form is shown on a regular 
> browser, whereas it is split across several pages for PDAs or phones. 
> That split can be decided by the view, choosing the appropriate template 
> depending on the browser type, with no impact on the flowscript which 
> will just have a single form.showForm().

:) So we booth belive that multi chanel wizards mainly should affect the 
view. But you want AFAIU to have event based flow control in the model 
and I prefer to have flowscript based flow control.

We introduced flowscripts in Cocoon once because we thought that it was 
a better way to control flow in e.g. wizards than using FSMs, were we wrong?

A problem with coding where we are in the wizard, booth as a widget 
state and a flowscript state (i.e. where we are in the form handling 
loop), is that previous continuations might get inconsistent. What 
happens if the user happens to use the browser back button in a widget 
state based wizard e.g.

                            ---o0o---

Anyway, thanks for evaluating the proposal and comming with constructive 
critic. I have some interesting new things to consider :)

/Daniel

Re: CForms Wizards

[Sylvain Wallez <sy...@apache.org>]

Daniel Fagerstrom wrote:

> Reinhard Poetz wrote:
>
>>  --- Sylvain Wallez <sy...@apache.org> schrieb:
>>
>>> Reinhard Poetz wrote:
>>>
>>>> Sylvain Wallez wrote:
>>>>
>>>>> Sylvain Wallez wrote:
>>>>>
>>>>>> Sorry to rain on the party, but the new widget state stuff in 
>>>>>> CForms should make building multi-page forms a piece of cake.
>>>>>> Off writing an example....
>>>>>
>>>>>
>>>>> Done, I wrote my first wizard with CForms :-)
>>>>>
> <snip/>
>
>> Thanks for your remarks. If nobody beats my, I'll try
>> to implement the wizard example by following your
>> ideas next week.
>> -- 
>> Reinhard
>
>
> Take a look at http://issues.apache.org/bugzilla/show_bug.cgi?id=32169 
> where I have enhanced work of Jonas Ekstedt so that one can do the 
> kind of things you asked for in the section about multi page forms in 
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106672364131946&w=2.
>
> So now it is possible to write CForms wizards by writing javascript 
> FSMs in the form definition using widget states. Or if you prefer, by 
> using flowscript back-button magic, and automatic selection of what is 
> validated based on what widgets you use in your template.


There's a problem by validating what's in the template, IMO: this means 
that if the template is wrong, i.e. it misses some important widget 
defined by the form, the form will be incorrectly considered valid. 
Also, this behaviour only validates terminal widgets and no container 
widgets, which may carry some additional semantic checks like row 
uniqueness in a repeater.

So although reading only widgets present in the original template may 
make sense, using that same widget list for validation is wrong. And 
again, registering this list of used widgets will become useless once 
widgets don't reset their values if their corresponding parameter is not 
present. I'm just waiting for the release before adding this new feature.

Furthermore, flowscript back-button magic implies that we can only 
navigate back to the previous screen, and not in an arbitrary screen in 
the sequence.

> But in the later case you miss the joy of writing all the javascript 
> event handling code ;)


Sure, but you still need a lot of <jx:if> in the template, wheareas 
activating/hiding groups means you just declare all groups (fd:struct) 
in the template and it adapts automatically.

And while writing the sample, some new <fd:wizard-action> widgets with 
builtin event handling popped up in my head, just like we have today 
<fd:repeater-action> and <fd:row-action>. No more javascript 
event-handling, no <jx:if>.

One last point also: being able to split a form across multiple page may 
allow for multi-channel forms, where the full form is shown on a regular 
browser, whereas it is split across several pages for PDAs or phones. 
That split can be decided by the view, choosing the appropriate template 
depending on the browser type, with no impact on the flowscript which 
will just have a single form.showForm().

Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

Re: CForms Wizards

[Daniel Fagerstrom <da...@nada.kth.se>]

Reinhard Poetz wrote:
>  --- Sylvain Wallez <sy...@apache.org> schrieb: 
>>Reinhard Poetz wrote:
>>>Sylvain Wallez wrote:
>>>>Sylvain Wallez wrote:
>>>>>Sorry to rain on the party, but the new widget
>>>>>state stuff in CForms 
>>>>>should make building multi-page forms a piece of
>>>>>cake.
>>>>>Off writing an example....
>>>>
>>>>Done, I wrote my first wizard with CForms :-)
>>>>
<snip/>
> Thanks for your remarks. If nobody beats my, I'll try
> to implement the wizard example by following your
> ideas next week.
> --
> Reinhard

Take a look at http://issues.apache.org/bugzilla/show_bug.cgi?id=32169 
where I have enhanced work of Jonas Ekstedt so that one can do the kind 
of things you asked for in the section about multi page forms in 
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106672364131946&w=2.

So now it is possible to write CForms wizards by writing javascript FSMs 
in the form definition using widget states. Or if you prefer, by using 
flowscript back-button magic, and automatic selection of what is 
validated based on what widgets you use in your template. But in the 
later case you miss the joy of writing all the javascript event handling 
code ;)

/Daniel

Re: CForms Wizards

[Reinhard Poetz <re...@yahoo.de>]

 --- Sylvain Wallez <sy...@apache.org> schrieb: 
> Reinhard Poetz wrote:
> 
> > Sylvain Wallez wrote:
> >
> >> Sylvain Wallez wrote:
> >>
> >>> Sorry to rain on the party, but the new widget
> state stuff in CForms 
> >>> should make building multi-page forms a piece of
> cake.
> >>>
> >>> Off writing an example....
> >>
> >>
> >> Done, I wrote my first wizard with CForms :-)
> >>
> >> Please update branch 2.1.x and point your browser
> to 
> >>
>
http://localhost:8888/forms-samples/do-multipage.flow
> >>
> >> Enjoy!
> >
> >
> > Great, thanks for the example! One question: IIUC
> the wizard is driven 
> > by the widget states and the event handling
> mechanism.
> 
> 
> Yes: the various "pages" are widget groups
> (fd:struct) whose state is 
> set either to active or invisible depending on the
> displayed page. The 
> initial state, in the form definition, is to have
> only page1 being 
> active, others being invisible. Navigation is
> managed by fd:action that 
> change the page state. "next" validates the current
> page whereas "prev" 
> doesn't. On the last page, a fd:submit goes back to
> flowscript if 
> validation is successful.
> 
> > This may solve many use cases but would it be
> possible to control 
> > which part of the form is shown by the controller
> (flowscript) which 
> > would bring some more flexibility (mix in
> non-forms pages, jump to 
> > different sub-pages)?
> 
> 
> That is possible if you use fd:submit instead of
> fd:action when control 
> has to come back to flowscript. Since only the
> active widgets are 
> validated, the submit will be sucessful if the
> widgets in the current 
> page are valid, not taking other pages into account.
> It's then the 
> flowscript's responsibility to display the
> appropriate page when calling 
> again form.showForm().
> 
> > [some pseudocode ...]
> > var myFlow() {
> >   var form = new Form("myForm");
> >   form.load(myBean);
> >   form.showSubForm("myPipeline", "../page1");
> >   cocoon.sendPageAndWait("showAnotherPage");
> >   form.showSubForm("myPipeline", "../page");
> >   form.save(myBean);
> > }
> 
> 
> The "showSubForm" above would simply set all pages
> to invisible state 
> except the one defined by the second parameter
> (which should be "pageX" 
> rather than "../pageX").
> 
> > And while writing this, another question came up:
> What's the best way 
> > to deal with validation errors? example: On page 2
> the users enters 
> > something that wouldn't let page 1 validate any
> more. Can we handle this?
> 
> 
> Validation of the last page could revalidate
> previous pages in order, 
> and switch back to the first one that doesn't
> validate successfully.
> 
> That could be something like:
> 
> function validateWizard() {
>   currentPage.setState(WidgetState.INVISIBLE); //
> another one may be 
> chosen below
>   for (page in pageList) {
>     page.setState(WidgetState.ACTIVE);
>     if (page.validate()) {
>       page.setState(WidgetState.INVISIBLE);
>     } else {
>       return false; // validation failed
>     }
>   }
> }
> 
> 
> Setting the page state to active before calling
> validate() is important 
> as non-active widgets are not validated. That isn't
> a problem here since 
> we must redisplay a page that doesn't validate, but
> I'm thinking of 
> adding a Widget.validate(boolean force) method, that
> would, when "force" 
> is true, validate widgets whatever their state.

Thanks for your remarks. If nobody beats my, I'll try
to implement the wizard example by following your
ideas next week.

--
Reinhard


	

	
		
___________________________________________________________
Gesendet von Yahoo! Mail - Jetzt mit 100MB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de

Re: CForms Wizards

[Sylvain Wallez <sy...@apache.org>]

Reinhard Poetz wrote:

> Sylvain Wallez wrote:
>
>> Sylvain Wallez wrote:
>>
>>> Sorry to rain on the party, but the new widget state stuff in CForms 
>>> should make building multi-page forms a piece of cake.
>>>
>>> Off writing an example....
>>
>>
>> Done, I wrote my first wizard with CForms :-)
>>
>> Please update branch 2.1.x and point your browser to 
>> http://localhost:8888/forms-samples/do-multipage.flow
>>
>> Enjoy!
>
>
> Great, thanks for the example! One question: IIUC the wizard is driven 
> by the widget states and the event handling mechanism.


Yes: the various "pages" are widget groups (fd:struct) whose state is 
set either to active or invisible depending on the displayed page. The 
initial state, in the form definition, is to have only page1 being 
active, others being invisible. Navigation is managed by fd:action that 
change the page state. "next" validates the current page whereas "prev" 
doesn't. On the last page, a fd:submit goes back to flowscript if 
validation is successful.

> This may solve many use cases but would it be possible to control 
> which part of the form is shown by the controller (flowscript) which 
> would bring some more flexibility (mix in non-forms pages, jump to 
> different sub-pages)?


That is possible if you use fd:submit instead of fd:action when control 
has to come back to flowscript. Since only the active widgets are 
validated, the submit will be sucessful if the widgets in the current 
page are valid, not taking other pages into account. It's then the 
flowscript's responsibility to display the appropriate page when calling 
again form.showForm().

> [some pseudocode ...]
> var myFlow() {
>   var form = new Form("myForm");
>   form.load(myBean);
>   form.showSubForm("myPipeline", "../page1");
>   cocoon.sendPageAndWait("showAnotherPage");
>   form.showSubForm("myPipeline", "../page");
>   form.save(myBean);
> }


The "showSubForm" above would simply set all pages to invisible state 
except the one defined by the second parameter (which should be "pageX" 
rather than "../pageX").

> And while writing this, another question came up: What's the best way 
> to deal with validation errors? example: On page 2 the users enters 
> something that wouldn't let page 1 validate any more. Can we handle this?


Validation of the last page could revalidate previous pages in order, 
and switch back to the first one that doesn't validate successfully.

That could be something like:

function validateWizard() {
  currentPage.setState(WidgetState.INVISIBLE); // another one may be 
chosen below
  for (page in pageList) {
    page.setState(WidgetState.ACTIVE);
    if (page.validate()) {
      page.setState(WidgetState.INVISIBLE);
    } else {
      return false; // validation failed
    }
  }
}


Setting the page state to active before calling validate() is important 
as non-active widgets are not validated. That isn't a problem here since 
we must redisplay a page that doesn't validate, but I'm thinking of 
adding a Widget.validate(boolean force) method, that would, when "force" 
is true, validate widgets whatever their state.

Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

CForms Wizards

[Reinhard Poetz <re...@apache.org>]

Sylvain Wallez wrote:
> Sylvain Wallez wrote:
> 
>>
>> Sorry to rain on the party, but the new widget state stuff in CForms 
>> should make building multi-page forms a piece of cake.
>>
>> Off writing an example....
> 
> 
> 
> Done, I wrote my first wizard with CForms :-)
> 
> Please update branch 2.1.x and point your browser to 
> http://localhost:8888/forms-samples/do-multipage.flow
> 
> Enjoy!

Great, thanks for the example! One question: IIUC the wizard is driven by the 
widget states and the event handling mechanism. This may solve many use cases 
but would it be possible to control which part of the form is shown by the 
controller (flowscript) which would bring some more flexibility (mix in 
non-forms pages, jump to different sub-pages)?

[some pseudocode ...]
var myFlow() {
   var form = new Form("myForm");
   form.load(myBean);
   form.showSubForm("myPipeline", "../page1");
   cocoon.sendPageAndWait("showAnotherPage");
   form.showSubForm("myPipeline", "../page");
   form.save(myBean);
}

And while writing this, another question came up: What's the best way to deal 
with validation errors? example: On page 2 the users enters something that 
wouldn't let page 1 validate any more. Can we handle this?

-- 
Reinhard

Re: Learning from XForms

[Sylvain Wallez <sy...@apache.org>]

Sylvain Wallez wrote:

>
> Sorry to rain on the party, but the new widget state stuff in CForms 
> should make building multi-page forms a piece of cake.
>
> Off writing an example....


Done, I wrote my first wizard with CForms :-)

Please update branch 2.1.x and point your browser to 
http://localhost:8888/forms-samples/do-multipage.flow

Enjoy!

Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

Re: Learning from XForms

[Sylvain Wallez <sy...@apache.org>]

Daniel Fagerstrom wrote:

> Torsten Curdt wrote:
> <snip/>
>
>> Exactly! For a secure system we need to keep the indirect population
>> approach. Although I had some continuation related RT on this...
>>
>> What actually is suspected to be populated on the next request
>> is available through the result of the last continuation!
>> Given this technique an automated and still secure population
>> mechanism could be put in place.
>>
>> ...but since I not yet got into the CForms codebase I am
>> not sure how CForms could benefit from this idea.
>
>
> Have you seen Jonas proposal 
> http://issues.apache.org/bugzilla/show_bug.cgi?id=32169 ? I currently 
> working on combining that with the "old" back button continuation 
> stuff from JXForm 
> (http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106684461526770&w=2)  
> and actually have a working prototype. It took quite some while to 
> make the continuations work in the way I wanted. Excpect some code and 
> an RT in the near future :)


Sorry to rain on the party, but the new widget state stuff in CForms 
should make building multi-page forms a piece of cake.

Off writing an example....

Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

Re: Learning from XForms

[Daniel Fagerstrom <da...@nada.kth.se>]

Torsten Curdt wrote:
<snip/>

> Exactly! For a secure system we need to keep the indirect population
> approach. Although I had some continuation related RT on this...
>
> What actually is suspected to be populated on the next request
> is available through the result of the last continuation!
> Given this technique an automated and still secure population
> mechanism could be put in place.
>
> ...but since I not yet got into the CForms codebase I am
> not sure how CForms could benefit from this idea.

Have you seen Jonas proposal 
http://issues.apache.org/bugzilla/show_bug.cgi?id=32169 ? I currently 
working on combining that with the "old" back button continuation stuff 
from JXForm 
(http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106684461526770&w=2)  
and actually have a working prototype. It took quite some while to make 
the continuations work in the way I wanted. Excpect some code and an RT 
in the near future :)

/Daniwl

Re: Learning from XForms

[Torsten Curdt <tc...@apache.org>]

>> IMHO, this might be a mistake. I sometimes got the impression that we 
>> spend a lot of time to independently evolve things that are quite 
>> close to what XForms allready does. And the last time I reviewed the 
>> spec it seemed to me that the XForms event model would work well at 
>> the server side also.

Hm... not sure about that.

> I shamely admit I haven't read the final version of the XForm spec :-/

Same here ...those days the reaction on the w3c XForms list was
"why on server - this is for the client" and our interest
was not shared. ...maybe this has changed now. Need to have
a look again anyway.

>> Another thing is having a request processor that writes into the 
>> widget tree instead of letting the widgets read from the request. This 
>> makes it possible to plug in an XML based request processor instead of 
>> the request parameters based, e.g.
> 
> 
> 
> The danger here is to fall again in the XMLForm trap, where all request 
> parameters where checked to see if they corresponded to some valid XPath 
> expression.

Exactly! For a secure system we need to keep the indirect population
approach. Although I had some continuation related RT on this...

What actually is suspected to be populated on the next request
is available through the result of the last continuation!
Given this technique an automated and still secure population
mechanism could be put in place.

...but since I not yet got into the CForms codebase I am
not sure how CForms could benefit from this idea.

cheers
--
Torsten