cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Ellis Parrott <parr...@fas.harvard.edu>
Subject Re: [Proposal] Implementing XMLForm with Flow
Date Thu, 05 Dec 2002 15:05:03 GMT

I've been looking into this too, and would like to add my 2 cents.

Basically I'm trying to build an interactive "wizard" type application,
but don't want to author the the wizard pages themselves, or control the
flow; this is because the content & flow is highly specialized, and I am
not :->.

It's the flow where problems persist; I have gotten branching working (if
you slected this go here, if that go there) using basic javascript, but
this doesn't scale at all.

My approach is to break down each page into three logical parts,
<question>, which is the question and background content, <answer>, which
is essentially the form itself, and <action> which is where the flow
lives. More static flow (next page doesn't depend on any responses) this
is fine, and for simply branching javascript works OK, because one can
change the "next" value using "onchange" attributes of the form elements.

But javascript isn't a satisfactory approach because of scalability and
depndence on the browser (I could actually live with it if it scaled).

Anyway, I still don't know how implement flow, especially aloowing the
authors to control simple flow. One ugly thought I've had is to include in
each page a hidden form that contains all the previous responses, and let
javascript control the flow, since it now has access to all the needed
data.

While I'm not endorsing javascript as the solution, let me describe how
I've done the basic flow control: for each form I have a FormManager
class in javascript that can register handlers for each form element.
Then for each form and form element, the stylesheet defines a unique ID
attribute. When specified in the <action> section, the stylesheet creates a
register handler function that registers a desired change in a target
element when a trigger element is modified. So when you check "No", the
hidden element that sets what the next page will be might change its value
from the default "occupation" to instead "program of study" page, or some
such thing.

By using a central handler, this should be extensible to any variety of
such actions, and if all the data were provided in a hidden form, then the
domain knowledge is right there for the javascript to use. I think that it
would make sense to have the data indexed by XPath values

Pros: This would for many purposes fulfill the requirements, and the
Action class would now be quite simple. In addition it would allow flow to
be moved from the developer to the author, which will be quite useful when
flow is simple (when x->y when a->b otherwise z). Also, almost all coding
is now in stylesheets instead of Java itself. Also, DHTML techiques are
fairly well established at this point.

Cons: Javascript needed; while javascript is fairly splintered among
different browsers, this would demand only the most basic & core
functionality. May get more & more messy over time, lots of CDATA
sections.


Again, I'm not married to this idea, and am actually thinking of moving to
an XSP to control flow logic for now. But I did spend some time thinking
about, and still consider it a viable idea.


For now I'm waiting to see what the content authors really need from the
application before proceeding with flow.


Anyway, my cents.


rob


On Wed, 4 Dec 2002, Ivelin Ivanov wrote:

>
> I hope you are the last hero trying to confront this monster.
>
> The discussion how to combine the two has been going on forever, but we have
> not come to an agreement.
> I would gladly offer my tactical guidance for your effort.
>
> The biggest issue that I had so far with the flow is how to implement in an
> elegant way, navigation logic which depends on domain knowledge.
> For example how to do a wizard where the next page (Car Models) depends on a
> selection on the previous (Brand Name) as well as a lookup to an external
> resource (BMW's Web Service providing a list of current car models or a db
> query).
>
> If I was to do this with Actions, I could use well known and standardized
> Java APIs - JWSP or JDBC.
> Maybe my issue is that I used the Struts model for too long and I can't get
> out of the box.
>
>
> Cheers,
>
> Ivelin
>
>
>
> ----- Original Message -----
> From: "Ugo Cei" <u.cei@cbim.it>
> To: <cocoon-dev@xml.apache.org>
> Sent: Wednesday, December 04, 2002 2:35 AM
> Subject: [Proposal] Implementing XMLForm with Flow
>
>
> > Premise #1: XMLForm has great support for XForms and validation, but it
> > uses butt-ugly actions for implementing the Control part of MVC.
> >
> > Premise #2: Control Flow rocks as an MVC (or MVC+) controller.
> >
> > Conclusion: let's reimplement XMLForm using Flow as the controller and
> > get rid of those actions.
> >
> > Plan of action: familiarize myself with both frameworks (I just started
> > using flow) and their internals, then start designing and coding. I have
> > a couple weeks' vacation starting Jan 1st and it would be nice to have
> > some nice OS project to work on ;-).
> >
> > Ivelin, Ovidiu (and everybody else), what do you think?
> >
> > Ugo
> >
> > --
> > Ugo Cei - http://www.beblogging.com/blog/
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> > For additional commands, email: cocoon-dev-help@xml.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message