On Sun, 2004-04-25 at 14:54, Sylvain Wallez wrote:
> Bruno Dumon wrote:
>
> >I'm a bit annoyed by the current status of our flowscript API's for
> >CForms. I'll leave the intro for what it is and just jump right into it:
> >
> >Form.showForm()
> >===============
> >I find that this function hides too much of how a form is processed, and
> >stands in the way of doing more advanced stuff.
> >
> >I propose that instead of Form.showForm(), we just let the user control
> >it:
> >
> >var form = new Form("my_form_definition.xml");
> >var finished = false;
> >while (!finished) {
> > cocoon.sendPageAndWait("my-pipeline", {"form": form});
> > finished = form.processSubmit();
> >}
> >
> >
>
> As Chris pointed out some time ago, this way of doing things, although
> fully functionnal, creates an unnecessarily long chain of continuations.
> This can be avoided by using bookmark continuations (see the v2 JS
> stuff), but makes the code less trivial.
What's the problem with a long chain of continuations? I mean, the
continuation is created anyhow, does it matter where it's added in the
continuation tree? Ah, just realizing: maybe because it allows faster
expiring of continuations?
<snip/>
on validators:
> >Since we now have the generalized concept of WidgetValidators, I propose
> >we use those to plug in the custom validation. In this way, the custom
> >validation will automatically be peformed as part of the normal form
> >processing cycle. WidgetValidators are currently however only part of
> >the WidgetDefinitions, we could make it possible to define additional
> >ones on the instances.
> >
> >The same should probably be done for event handlers. Currently the v2
> >API works around this limitation by using the FormHandler to allow to
> >add instance-specific event handlers.
> >
> >
>
> +1. form.validator was a hack needed before the generalized validation,
> and isn't needed anymore. Also, do we still need FormHandler? My
> impression is that we can remove it completely.
I would leave it in (it's not like it's much code anyway). The
FormHandler allows to capture all generated events without the need to
register individual event listeners on each widget, which might be
useful.
<snip/>
> >* pro: ScriptableWidget makes it much more natural to work with the form
> >in a javascript environment. Working directly with the Java objects
> >feels clumsy. If you look at the v2 API, it allows to easily do some
> >powerful stuff like assigning javascript functions as event handlers.
> >
> >
>
> A java interface can easily be implemented in JS: see
> http://www.mozilla.org/rhino/ScriptingJava.html, "implementing java
> interfaces". Sure, it's not that easy as just passing a function as a
> method argument, but we can provide convenience functions for this.
Ah, that's right, I was overseeing that.
>
> >* con: different objects, different API's, different documentation,
> >needs work when new widgets or features/concepts are added. Makes it
> >more difficult to do one part of logic in javascript and another part in
> >Java. Makes the javascript code harder to move to Java if you want to.
> >
> >I'm still undecided on this topic (ScriptableWidget). I'd like to hear
> >what others think of this, and how they are actually working today (my
> >experience in using all this is rather limited). At first I was more
> >towards the ScriptableWidget approach, though as I'm writing this I'm
> >more leaning towards directly using the java objects, and creating some
> >convenience functions to wrap javascript functions as custom validators
> >and event handlers (as far as that's technically possible).
> >
> >
>
> I never used the ScriptableWidget API as, being primarily a Java
> developper, the Java API is more natural to me. Also, although me may
> provide a more JS-friendly API to allow more compact notations, it
> should in no way restrict the accessibility of specific features of
> particular widget implementations. By this, I mean that the JS wrapper
> should delegate all properties and methods it doesn't know about to the
> underlying java widget.
>
> >Actually, that's leading me to another random thought: do we need the
> >javascript Form object? (this is unrelated to the ScriptableWidget
> >issue) Instead we could just have some convenience functions to create a
> >form instance, to get a binding object, ... Currently my code always
> >contains a var form and a var formWidget, and when starting I was always
> >making the mistake of using the form instead of the formWidget var, and
> >now I still find it annoying.
> >
> >
>
> Well, you can get the form widget using jsForm.getWidget()!
Yep, I know, but the distinction between the "form" and the "form
widget" seemed a bit strange to me (from a user point of view). I can
live with it though.
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
[EMAIL PROTECTED] [EMAIL PROTECTED]
