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" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > 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: [EMAIL PROTECTED] > > For additional commands, email: [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
