You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Tim Larson <ti...@keow.org> on 2004/03/16 18:42:25 UTC
v2 forms flowscript example
In: cocoon-2.1/src/blocks/forms/samples/v2/forms_flow_example.js
Should this:
// 'wid' is a javascript wrapper of the Cocoon Form widget.
//
// Its subwidgets can be accessed by id.
be changed to this:
// 'wid' is a javascript wrapper of the Cocoon Form widget.
//
// The javascript wrappers of its subwidgets can be accessed by id.
to be accurate?
--Tim Larson
Re: Less is more... or less? (was Re: v2 forms flowscript example)
Posted by Sylvain Wallez <sy...@apache.org>.
Tim Larson wrote:
>On Mon, Mar 22, 2004 at 11:34:22AM +0100, Sylvain Wallez wrote:
>
>
>>Vadim Gritsenko wrote:
>>
>>
>>>>>Sylvain Wallez wrote:
>>>>>
>>>>>
>>>>>>Why is there a need to have a different API for widgets when used from JS than when used from Java? IMO, this is arbitrarily limiting the features available in flowscript.
>>>>>>
>>>>>>
>>>But isn't this our design approach? If I remember correctly our FOM discussions, "less is more", right?
>>>
>>>
>>Well, time for a bit of rant on this.
>>
>>I'm personally not that happy with "less is more" as it was applied to FOM. Although I agree that bloated APIs should be avoided, restricting the Cocoon core APIs (the environment) in some specific area of Cocoon (flowscript) seems to me an arbitrary constraint.
>>
>>
>
>I agree with "less is more" in designing API's, but when we have what should be *one* API exposed in two environments it should be the *same* API, modulo environment-specific ease-of-use enhancements. In short, I think everything that is public in the Java API should also be directly available in the JS API. I interpret "less is more" to mean expose-in-both or expose-in-neither, otherwise we create confusion.
>
>
+1000. That's exactly my point.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Less is more... or less? (was Re: v2 forms flowscript example)
Posted by Tim Larson <ti...@keow.org>.
On Mon, Mar 22, 2004 at 11:34:22AM +0100, Sylvain Wallez wrote:
> Vadim Gritsenko wrote:
> >>>Sylvain Wallez wrote:
> >>>>Why is there a need to have a different API for widgets when used
> >>>>from JS than when used from Java? IMO, this is arbitrarily limiting
> >>>>the features available in flowscript.
> >
> >But isn't this our design approach? If I remember correctly our FOM
> >discussions, "less is more", right?
>
> Well, time for a bit of rant on this.
>
> I'm personally not that happy with "less is more" as it was applied to
> FOM. Although I agree that bloated APIs should be avoided, restricting
> the Cocoon core APIs (the environment) in some specific area of Cocoon
> (flowscript) seems to me an arbitrary constraint.
I agree with "less is more" in designing API's, but when we have what
should be *one* API exposed in two environments it should be the *same*
API, modulo environment-specific ease-of-use enhancements.
In short, I think everything that is public in the Java API should also
be directly available in the JS API. I interpret "less is more" to mean
expose-in-both or expose-in-neither, otherwise we create confusion.
--Tim Larson
Re: Less is more... or less?
Posted by Antonio Gallardo <ag...@agssa.net>.
Sylvain Wallez dijo:
> An example: last week, a customer of mine (I do mentoring for them and
> they're not subscribed to users@) asked me "I get a "no such property or
> method" error when calling context.getRealPath() in my flowscript.
> Why?". I answered that this method isn't available in flowscript and
> provided a 10-lines workaround involving looking up the sourceresolver
> and resolving a "context://" URL.
Can you provide more info about this issue? We had the same problem some
weeks ago and solved in a total diferent approach. Maybe our solution can
help you too.
I remember the old discusions about why block some parts of the API. The
overall idea was to avoid abusing of flow (javascript) to write all the
code there.
But thinking about why flow exists: As a controller. I realize the
controller must be able to solve paths in order to delegate.
So I am +1 in reviewing what we have avaliable and what not in FOM.
Best Regards,
Antonio Gallardo.
Re: Less is more... or less?
Posted by Sylvain Wallez <sy...@apache.org>.
Stefano Mazzocchi wrote:
> Sylvain Wallez wrote:
>
>> So less is less when you have more on the *same* object accessed
>> directly in Java.
>
>
> Sylvain,
>
> less is more when all the things that you removed were not helping,
> not always.
>
> The "less is more" design approach is a process, not a solution.
Sure, and I totally agree with that. I should have reminded in my post
the quote that's on my weblog: "perfection is achieved not when there's
nothing more to add, but when there's nothing left to remove" (Antoine
de Saint-Exupéry).
> Instead of putting everything in FOM and deprecate bad ideas later, we
> opted for a process where we start small and add thing incrementally.
Yeah, but the question is what is the FOM? Is it the objects that are
made available, or the APIs on these objects? I know your answer:
"both". But why do we have *two* different APIs in Cocoon for the exact
same object, one being a subset of the other? This is really confusing
to users.
An example: last week, a customer of mine (I do mentoring for them and
they're not subscribed to users@) asked me "I get a "no such property or
method" error when calling context.getRealPath() in my flowscript.
Why?". I answered that this method isn't available in flowscript and
provided a 10-lines workaround involving looking up the sourceresolver
and resolving a "context://" URL.
Sure I could have started a vote to add getRealPath() to the FOM. But
the customer needed it right now, and not in 2.1.5, and the
workaround... well, just works even if ugly and slower. But it is a
workaround.
> It might result that we end up making FOM a java clone of the java
> APIs we provide. If the community requires so, great, wonderful.
That's where I see a limitation of the community dynamics and a proof
that this API reduction is a bad thing, as it's faster to provide a
workaround using a Java class and Cocoon's official APIs than discuss
and vote some changes that will be available in the next release.
Also, the fact that the workaround uses the official Java APIs (and not
clear violations of the public contract like
CocoonComponentManager.getCurrentEnvironment()) clearly shows IMO that
constraining the API of objects exposed by the FOM is useless.
> The point is that it has been done with a process that made it appear
> why we needed that, instead of just cloning over.
>
> This means: if you think there is something missing in FOM or has to
> change, ask for a vote to add it, at that point, you'll find
> resistance and people might suggest better ways to do what you had in
> mind, or not.
>
> Doesn't matter the outcome, it's the community process that counts.
Ok. I'll check what has been hidden from the environment API and start a
vote on this. I do agree with the fact that not all objects should be
exposed (although most of them actually are), but not with the reduction
of the API.
Ah, and what about the FOM if/when we'll have a Java version of
flowscript? Will we have a FOMRequest Java interface that will be subset
of Request? That sounds totally silly...
> In *that* regard, less is always more.
Yep. Less APIs in JS than in Java for the same object is more confusion ;-)
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Less is more... or less?
Posted by Stefano Mazzocchi <st...@apache.org>.
Sylvain Wallez wrote:
> So less is less when you have more on the *same* object accessed
> directly in Java.
Sylvain,
less is more when all the things that you removed were not helping, not
always.
The "less is more" design approach is a process, not a solution.
Instead of putting everything in FOM and deprecate bad ideas later, we
opted for a process where we start small and add thing incrementally.
It might result that we end up making FOM a java clone of the java APIs
we provide. If the community requires so, great, wonderful.
The point is that it has been done with a process that made it appear
why we needed that, instead of just cloning over.
This means: if you think there is something missing in FOM or has to
change, ask for a vote to add it, at that point, you'll find resistance
and people might suggest better ways to do what you had in mind, or not.
Doesn't matter the outcome, it's the community process that counts.
In *that* regard, less is always more.
--
Stefano.
Scripting Languages (was Re: Less is more... or less? (was Re: v2
forms flowscript example))
Posted by Christopher Oliver <re...@verizon.net>.
Sylvain Wallez wrote:
> Vadim Gritsenko wrote:
>
>>>> Sylvain Wallez wrote:
>>>>
>>>>> Why is there a need to have a different API for widgets when used
>>>>> from JS than when used from Java? IMO, this is arbitrarily
>>>>> limiting the features available in flowscript.
>>>>
>>>>
>>
>> But isn't this our design approach? If I remember correctly our FOM
>> discussions, "less is more", right?
>
>
>
> Well, time for a bit of rant on this.
>
> I'm personally not that happy with "less is more" as it was applied to
> FOM. Although I agree that bloated APIs should be avoided, restricting
> the Cocoon core APIs (the environment) in some specific area of Cocoon
> (flowscript) seems to me an arbitrary constraint.
>
> Yes, not that many people have asked for more of the Java environment
> APIs to be visible. But why so? Simply because people (and I talk
> about what I've seen in real customer projects) often end up writing a
> simple Java class that allow them to access the real Java object and
> therefore use the *full* environment API in their flowscripts. This
> leads to clumsy constructs that overcomplexify the flow scripts.
>
> That's why I don't like the JS-specific APIs, except those that allow
> shorter notations through properties.
>
> Furthemore, this makes learning more difficult, as people have to
> learn *two* APIs to know what is (or is not) available in flowscript.
> And as we have no explicit auto-generated documentation for the
> flowscript APIs, this is a lot of trial and error.
Well, the JS Flowscript API is documented:
http://cocoon.apache.org/2.1/userdocs/flow/api.html.
Although I agree with you that there should not be unnecessary
limitations in the JS API as compared to Java, nevertheless I think
it's unavoidable that there will be some differences. This seems to be
the case more generally with any Java scripting language. For example,
JS String and java.lang.String do not have the same API:
var length = "Hello".length;
var length = new java.lang.String("Hello").length();
Compare also JS DOM versus Java DOM. I really don't see how such
mismatches can be avoided completely. You'll run into the same thing
with Jython, Groovy, etc. The net result of this is that, yes, the user
will have to learn two API's (although similar).
Nevertheless, at least in my experience the combination of a scripting
language and a system programming language has always been a winning
combination. At my previous company, we developed tools for the abstract
syntax language ASN.1. We provided a mapping to C++ classes, but we also
implemented an ASN.1 API for the TCL scripting language. In constrast to
JS/Java, TCL syntax is drastically different from C++. So the API's were
not identical but however provided equivalent functionality in their own
way. With the close similarity between JS and Java syntax it's tempting
to try to make the API's identical, but there are important features
only in JS (first class functions, closures, etc) that can and should be
exploited.
My opinion is that any Cocoon JS API's should be developed to provide
the best possible JS programming environment for the user. If this
results in a different API than that provided in Java, so be it
(although I think we should strive to make them the same where possible).
Chris
Less is more... or less? (was Re: v2 forms flowscript example)
Posted by Sylvain Wallez <sy...@apache.org>.
Vadim Gritsenko wrote:
>>> Sylvain Wallez wrote:
>>>
>>>> Why is there a need to have a different API for widgets when used
>>>> from JS than when used from Java? IMO, this is arbitrarily limiting
>>>> the features available in flowscript.
>>>
>
> But isn't this our design approach? If I remember correctly our FOM
> discussions, "less is more", right?
Well, time for a bit of rant on this.
I'm personally not that happy with "less is more" as it was applied to
FOM. Although I agree that bloated APIs should be avoided, restricting
the Cocoon core APIs (the environment) in some specific area of Cocoon
(flowscript) seems to me an arbitrary constraint.
Yes, not that many people have asked for more of the Java environment
APIs to be visible. But why so? Simply because people (and I talk about
what I've seen in real customer projects) often end up writing a simple
Java class that allow them to access the real Java object and therefore
use the *full* environment API in their flowscripts. This leads to
clumsy constructs that overcomplexify the flow scripts.
That's why I don't like the JS-specific APIs, except those that allow
shorter notations through properties.
Furthemore, this makes learning more difficult, as people have to learn
*two* APIs to know what is (or is not) available in flowscript. And as
we have no explicit auto-generated documentation for the flowscript
APIs, this is a lot of trial and error. We had IDL, which was abandonned
because it wasn't maintained. I won't blame anyone for this as I'm the
first one to dislike writing docs, but I do write javadoc in the code.
Javadoc *is* the reference for our APIs, and where users dig to find
what's available, even those who don't write a single line of Java but
use only flowscript. Imagine how frustrating it is to see some feature
you need available on the Java object, but not on the JS one...
So less is less when you have more on the *same* object accessed
directly in Java.
WDYT?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: v2 forms flowscript example
Posted by Vadim Gritsenko <va...@reverycodes.com>.
>> Sylvain Wallez wrote:
>>
>>> Why is there a need to have a different API for widgets when used
>>> from JS than when used from Java? IMO, this is arbitrarily limiting
>>> the features available in flowscript.
>>
But isn't this our design approach? If I remember correctly our FOM
discussions, "less is more", right?
Vadim
Re: v2 forms flowscript example
Posted by Christopher Oliver <re...@verizon.net>.
Sylvain Wallez wrote:
> Christopher Oliver wrote:
>
>> Sylvain Wallez wrote:
>>
>>> Christopher Oliver wrote:
>>>
>>>> Tim Larson wrote:
>>>>
>>>>> In: cocoon-2.1/src/blocks/forms/samples/v2/forms_flow_example.js
>>>>> Should this:
>>>>> // 'wid' is a javascript wrapper of the Cocoon Form widget.
>>>>> //
>>>>> // Its subwidgets can be accessed by id.
>>>>> be changed to this:
>>>>> // 'wid' is a javascript wrapper of the Cocoon Form widget.
>>>>> //
>>>>> // The javascript wrappers of its subwidgets can be accessed by
>>>>> id.
>>>>> to be accurate?
>>>>>
>>>>> --Tim Larson
>>>>>
>>>> Actually, I don't think it should even mention "wrappers". IMO, the
>>>> underlying Java widgets are an implementation detail of the
>>>> Flowscript API and should never be used directly in a script. The
>>>> documentation should simply say that the return value of
>>>> Form.getWidget() is the JS representation of <fd:form> instance.
>>>
>>>
>>>
>>>
>>> Why is there a need to have a different API for widgets when used
>>> from JS than when used from Java? IMO, this is arbitrarily limiting
>>> the features available in flowscript.
>>>
>>> The good thing of these wrappers is that they simplify the notation
>>> for browsing the widget tree (by avoiding 'getWidget()'), but the
>>> fact that some limits come with this simplified notation is IMO not
>>> good.
>>
>>
>>
>>
>> There isn't (or shouldn't be) any limitation in functionality in the
>> V2 API. Do you see a limitation?
>
>
>
> I haven't made the exhaustive comparision between ScriptableWidget and
> every Widget implementation, but my bell rang when seeing all methods
> of all widgets gathered in a single class.
>
From my experience this is a common design pattern for wrapping
existing API's. Other approaches are of course possible.
>>> Furthermore, what if someone designs their own new widget with some
>>> specific APIs? They simply cannot access them unless they modify the
>>> ScriptableWidget class, which will hold all APIs of all widgets
>>> (this is already the case with e.g. repeater-specific functions).
>>
>>
>>
>> It wasn't my goal to allow user-defined widgets, but if that is
>> desired it should be possible to refactor ScriptableWidget to make it
>> easy to do that.
>
>
>
> AFAIU, this could be achieved by extending NativeJavaObject and just
> adding shortcut access to child widgets in has() and get(). Am I right?
>
If adding "shortcut access" was all that was required, perhaps. However,
extending Rhino internal classes (like NativeJavaObject) is not a good
idea in my opinion. Moreover, ScriptableWidget provides additional
functionality beyond that, namely the ability to set JS functions as
event handlers, coerecions of JS Number to CForms numeric datatypes,
initialization of complex widgets using JS objects, and notification of
validation errors.
Regards,
Chris
Re: v2 forms flowscript example
Posted by Sylvain Wallez <sy...@apache.org>.
Christopher Oliver wrote:
> Sylvain Wallez wrote:
>
>> Christopher Oliver wrote:
>>
>>> Tim Larson wrote:
>>>
>>>> In: cocoon-2.1/src/blocks/forms/samples/v2/forms_flow_example.js
>>>> Should this:
>>>> // 'wid' is a javascript wrapper of the Cocoon Form widget.
>>>> //
>>>> // Its subwidgets can be accessed by id.
>>>> be changed to this:
>>>> // 'wid' is a javascript wrapper of the Cocoon Form widget.
>>>> //
>>>> // The javascript wrappers of its subwidgets can be accessed by id.
>>>> to be accurate?
>>>>
>>>> --Tim Larson
>>>>
>>> Actually, I don't think it should even mention "wrappers". IMO, the
>>> underlying Java widgets are an implementation detail of the
>>> Flowscript API and should never be used directly in a script. The
>>> documentation should simply say that the return value of
>>> Form.getWidget() is the JS representation of <fd:form> instance.
>>
>>
>>
>> Why is there a need to have a different API for widgets when used
>> from JS than when used from Java? IMO, this is arbitrarily limiting
>> the features available in flowscript.
>>
>> The good thing of these wrappers is that they simplify the notation
>> for browsing the widget tree (by avoiding 'getWidget()'), but the
>> fact that some limits come with this simplified notation is IMO not
>> good.
>
>
>
> There isn't (or shouldn't be) any limitation in functionality in the
> V2 API. Do you see a limitation?
I haven't made the exhaustive comparision between ScriptableWidget and
every Widget implementation, but my bell rang when seeing all methods of
all widgets gathered in a single class.
>> Furthermore, what if someone designs their own new widget with some
>> specific APIs? They simply cannot access them unless they modify the
>> ScriptableWidget class, which will hold all APIs of all widgets (this
>> is already the case with e.g. repeater-specific functions).
>
>
> It wasn't my goal to allow user-defined widgets, but if that is
> desired it should be possible to refactor ScriptableWidget to make it
> easy to do that.
AFAIU, this could be achieved by extending NativeJavaObject and just
adding shortcut access to child widgets in has() and get(). Am I right?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: v2 forms flowscript example
Posted by Christopher Oliver <re...@verizon.net>.
Sylvain Wallez wrote:
> Christopher Oliver wrote:
>
>> Tim Larson wrote:
>>
>>> In: cocoon-2.1/src/blocks/forms/samples/v2/forms_flow_example.js
>>> Should this:
>>> // 'wid' is a javascript wrapper of the Cocoon Form widget.
>>> //
>>> // Its subwidgets can be accessed by id.
>>> be changed to this:
>>> // 'wid' is a javascript wrapper of the Cocoon Form widget.
>>> //
>>> // The javascript wrappers of its subwidgets can be accessed by id.
>>> to be accurate?
>>>
>>> --Tim Larson
>>>
>> Actually, I don't think it should even mention "wrappers". IMO, the
>> underlying Java widgets are an implementation detail of the
>> Flowscript API and should never be used directly in a script. The
>> documentation should simply say that the return value of
>> Form.getWidget() is the JS representation of <fd:form> instance.
>
>
>
> Why is there a need to have a different API for widgets when used from
> JS than when used from Java? IMO, this is arbitrarily limiting the
> features available in flowscript.
>
> The good thing of these wrappers is that they simplify the notation
> for browsing the widget tree (by avoiding 'getWidget()'), but the fact
> that some limits come with this simplified notation is IMO not good.
There isn't (or shouldn't be) any limitation in functionality in the V2
API. Do you see a limitation?
>
> Furthermore, what if someone designs their own new widget with some
> specific APIs? They simply cannot access them unless they modify the
> ScriptableWidget class, which will hold all APIs of all widgets (this
> is already the case with e.g. repeater-specific functions).
It wasn't my goal to allow user-defined widgets, but if that is desired
it should be possible to refactor ScriptableWidget to make it easy to do
that.
Chris.
Re: v2 forms flowscript example
Posted by Sylvain Wallez <sy...@apache.org>.
Christopher Oliver wrote:
> Tim Larson wrote:
>
>> In: cocoon-2.1/src/blocks/forms/samples/v2/forms_flow_example.js
>> Should this:
>> // 'wid' is a javascript wrapper of the Cocoon Form widget.
>> //
>> // Its subwidgets can be accessed by id.
>> be changed to this:
>> // 'wid' is a javascript wrapper of the Cocoon Form widget.
>> //
>> // The javascript wrappers of its subwidgets can be accessed by id.
>> to be accurate?
>>
>> --Tim Larson
>>
> Actually, I don't think it should even mention "wrappers". IMO, the
> underlying Java widgets are an implementation detail of the Flowscript
> API and should never be used directly in a script. The documentation
> should simply say that the return value of Form.getWidget() is the JS
> representation of <fd:form> instance.
Why is there a need to have a different API for widgets when used from
JS than when used from Java? IMO, this is arbitrarily limiting the
features available in flowscript.
The good thing of these wrappers is that they simplify the notation for
browsing the widget tree (by avoiding 'getWidget()'), but the fact that
some limits come with this simplified notation is IMO not good.
Furthermore, what if someone designs their own new widget with some
specific APIs? They simply cannot access them unless they modify the
ScriptableWidget class, which will hold all APIs of all widgets (this is
already the case with e.g. repeater-specific functions).
Isn't there a way with Rhino to simply augment a wrapped Java object
with new properties (here the children widgets) without having to fully
reimplement all of its methods?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: v2 forms flowscript example
Posted by Christopher Oliver <re...@verizon.net>.
Tim Larson wrote:
>In: cocoon-2.1/src/blocks/forms/samples/v2/forms_flow_example.js
>Should this:
> // 'wid' is a javascript wrapper of the Cocoon Form widget.
> //
> // Its subwidgets can be accessed by id.
>be changed to this:
> // 'wid' is a javascript wrapper of the Cocoon Form widget.
> //
> // The javascript wrappers of its subwidgets can be accessed by id.
>to be accurate?
>
>--Tim Larson
>
>
>
>
Actually, I don't think it should even mention "wrappers". IMO, the
underlying Java widgets are an implementation detail of the Flowscript
API and should never be used directly in a script. The documentation
should simply say that the return value of Form.getWidget() is the JS
representation of <fd:form> instance.
My $0.02,
Chris
RE: woody2.js: custom validation issue in cocoon-2.1.2 to 2.1.4
Posted by Alex Kovacs <al...@fast.fujitsu.com.au>.
Hi Tim,
I have a task to port an older demo to the new cocoon version so I will
try it in the next few days.
Alex
> -----Original Message-----
> From: Tim Larson [mailto:tim@keow.org]
> Sent: Monday, 22 March 2004 12:04 PM
> To: dev@cocoon.apache.org
> Subject: Re: woody2.js: custom validation issue in cocoon-2.1.2 to
2.1.4
>
> On Mon, Mar 22, 2004 at 10:55:34AM +1100, Alex Kovacs wrote:
> > Hi Tim,
> >
> > Do you mean the new v2 validation framework (per widget)? I only had
a
> > quick look at the v2 and liked it very much but require some porting
> > from previous version and I do not have time to try it yet.
> > Alex
>
> Yes, that is what I meant. Actually the whole v2/flow.js.
> I was just letting you know about it as an option and checking
> with you to see if you saw any of the same issues or other
> problems in it that we should fix before too many people
> migrate to it.
>
> --Tim Larson
Re: woody2.js: custom validation issue in cocoon-2.1.2 to 2.1.4
Posted by Tim Larson <ti...@keow.org>.
On Mon, Mar 22, 2004 at 10:55:34AM +1100, Alex Kovacs wrote:
> Hi Tim,
>
> Do you mean the new v2 validation framework (per widget)? I only had a
> quick look at the v2 and liked it very much but require some porting
> from previous version and I do not have time to try it yet.
> Alex
Yes, that is what I meant. Actually the whole v2/flow.js.
I was just letting you know about it as an option and checking
with you to see if you saw any of the same issues or other
problems in it that we should fix before too many people
migrate to it.
--Tim Larson
RE: woody2.js: custom validation issue in cocoon-2.1.2 to 2.1.4
Posted by Alex Kovacs <al...@fast.fujitsu.com.au>.
Hi Tim,
Do you mean the new v2 validation framework (per widget)? I only had a
quick look at the v2 and liked it very much but require some porting
from previous version and I do not have time to try it yet.
Alex
> -----Original Message-----
> From: Tim Larson [mailto:tim@keow.org]
> Sent: Saturday, 20 March 2004 3:47 AM
> To: dev@cocoon.apache.org
> Subject: Re: woody2.js: custom validation issue in cocoon-2.1.2 to
2.1.4
>
> On Fri, Mar 19, 2004 at 04:43:34PM +1100, Alex Kovacs wrote:
> > Tested and it behaves the same way, i.e. does not show any custom
> > validation errors until all other fields are validated correctly.
> > However, this is not the change that I was hoping for ;-).
>
> Have you checked the v2 flowscript? Does it do what you want?
> I think we are slowly migrating toward using it.
>
> --Tim Larson
Re: woody2.js: custom validation issue in cocoon-2.1.2 to 2.1.4
Posted by Tim Larson <ti...@keow.org>.
On Fri, Mar 19, 2004 at 04:43:34PM +1100, Alex Kovacs wrote:
> Tested and it behaves the same way, i.e. does not show any custom
> validation errors until all other fields are validated correctly.
> However, this is not the change that I was hoping for ;-).
Have you checked the v2 flowscript? Does it do what you want?
I think we are slowly migrating toward using it.
--Tim Larson
Re: woody2.js: custom validation issue in cocoon-2.1.2 to 2.1.4
Posted by Sylvain Wallez <sy...@apache.org>.
Joerg Heinicke wrote:
>Sylvain Wallez <sylvain <at> apache.org> writes:
>
>
>
>>>I have committed it this way to the forms block in CVS:
>>>
>>>if (finished) {
>>> if (this.validator == null) {
>>> this.isValid = this.form.isValid();
>>> } else {
>>> this.isValid = this.form.isValid()
>>> & this.validator(this.form, bizData);
>>> }
>>> finished = this.isValid;
>>>}
>>>
>>>Should work as well. Can you test it?
>>>
>>>
>>>
>>>
>>This was written that way on purpose, in order for the flow-level
>>validation do be assured that the form was valid and not to care about
>>it. This change means that flow-level validation has now to check if the
>>form is valid, which may break some of the existing uses.
>>
>>
>
>IMO it's really bad usability to present the user the validation results in
>multiple steps. I have the same problem at the moment for the
>wd:validation/wd:javascript, this is also only executed after the form itself is
>valid. If you add in the form1.xml a @required="true" to the email and make a
>duplicate entry for the firstname, you first have to fill all emails to get the
>validation on unique names running.
>
>
I see your point. So we may change the semantics of validators and say
that they're *always* called and should take care that they may act on
invalid widgets.
>IMO it must be possible to get a form validated completely in one submit, not
>"fixing the last issue, submit, ... again three errors :-(".
>
>
That totally makes sense.
>>Note that I plan to remove this feature in CForms as we can now add
>>arbitrary validators on the Form itself.
>>
>>
>
>"this feature" is this.validator? What exactly does "this" refer to at the
>moment? And later it will be this.form.validator or
>this.form.addValidator(validator) or something similar?
>
>
The "this" refers to the fact that we can add a validator at the
flowscript level. As we can add regular WidgetValidators on the Form
(and on any widget, BTW), there's no need anymore for this flow-specific
feature.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: woody2.js: custom validation issue in cocoon-2.1.2 to 2.1.4
Posted by Joerg Heinicke <jo...@gmx.de>.
Sylvain Wallez <sylvain <at> apache.org> writes:
> >I have committed it this way to the forms block in CVS:
> >
> >if (finished) {
> > if (this.validator == null) {
> > this.isValid = this.form.isValid();
> > } else {
> > this.isValid = this.form.isValid()
> > & this.validator(this.form, bizData);
> > }
> > finished = this.isValid;
> >}
> >
> >Should work as well. Can you test it?
> >
> >
>
> This was written that way on purpose, in order for the flow-level
> validation do be assured that the form was valid and not to care about
> it. This change means that flow-level validation has now to check if the
> form is valid, which may break some of the existing uses.
IMO it's really bad usability to present the user the validation results in
multiple steps. I have the same problem at the moment for the
wd:validation/wd:javascript, this is also only executed after the form itself is
valid. If you add in the form1.xml a @required="true" to the email and make a
duplicate entry for the firstname, you first have to fill all emails to get the
validation on unique names running.
IMO it must be possible to get a form validated completely in one submit, not
"fixing the last issue, submit, ... again three errors :-(".
> Note that I plan to remove this feature in CForms as we can now add
> arbitrary validators on the Form itself.
"this feature" is this.validator? What exactly does "this" refer to at the
moment? And later it will be this.form.validator or
this.form.addValidator(validator) or something similar?
Joerg
Re: woody2.js: custom validation issue in cocoon-2.1.2 to 2.1.4
Posted by Sylvain Wallez <sy...@apache.org>.
Joerg Heinicke wrote:
>Alex Kovacs <alexk <at> fast.fujitsu.com.au> writes:
>
>
>> if (this.validator == null) {
>> //if no custom validation
>> this.isValid = this.form.isValid();
>> } else {
>> var validated = true;
>>
>> if(!this.validator(this.form, bizData))
>> validated = false;
>>
>> if(!this.form.isValid())
>> validated = false;
>>
>> this.isValid = validated;
>> finished = this.isValid;
>> }
>>
>>
>
>I have committed it this way to the forms block in CVS:
>
>if (finished) {
> if (this.validator == null) {
> this.isValid = this.form.isValid();
> } else {
> this.isValid = this.form.isValid() & this.validator(this.form, bizData);
> }
> finished = this.isValid;
>}
>
>Should work as well. Can you test it?
>
>
This was written that way on purpose, in order for the flow-level
validation do be assured that the form was valid and not to care about
it. This change means that flow-level validation has now to check if the
form is valid, which may break some of the existing uses.
Note that I plan to remove this feature in CForms as we can now add
arbitrary validators on the Form itself.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: woody2.js: custom validation issue in cocoon-2.1.2 to 2.1.4
Posted by Joerg Heinicke <jo...@gmx.de>.
On 19.03.2004 06:43, Alex Kovacs wrote:
> Tested and it behaves the same way, i.e. does not show any custom
> validation errors until all other fields are validated correctly.
> However, this is not the change that I was hoping for ;-).
>
> I think the test "if (finished)" is the problem. It only allows for
> custom validation just after the form is finished. The finished variable
> comes from some lines above in woody2.js:
> finished = this.form.process(formContext);
> So it seems the form is validated (i.e. finished) only if the built-in
> validation is completed. And my understanding is that the form is not
> finished until there are no errors, regardless if they are coming from
> the custom validation or not. Therefore, I still think the fix above
> does not solve my issues. I my code above I've actually removed the "if
> (finished ...)" statement to make the fix working ok.
>
> What do you think?
Ah, sorry for that. I hadn't the finished in mind and did not thought
that you removed this first completely from your snippet. I will have a
look on it.
Joerg
RE: woody2.js: custom validation issue in cocoon-2.1.2 to 2.1.4
Posted by Alex Kovacs <al...@fast.fujitsu.com.au>.
> Alex Kovacs <alexk <at> fast.fujitsu.com.au> writes:
>
> > if (this.validator == null) {
> > //if no custom validation
> > this.isValid = this.form.isValid();
> > } else {
> > var validated = true;
> >
> > if(!this.validator(this.form, bizData))
> > validated = false;
> >
> > if(!this.form.isValid())
> > validated = false;
> >
> > this.isValid = validated;
> > finished = this.isValid;
> > }
>
> I have committed it this way to the forms block in CVS:
>
> if (finished) {
> if (this.validator == null) {
> this.isValid = this.form.isValid();
> } else {
> this.isValid = this.form.isValid() & this.validator(this.form,
> bizData);
> }
> finished = this.isValid;
> }
>
> Should work as well. Can you test it?
>
Tested and it behaves the same way, i.e. does not show any custom
validation errors until all other fields are validated correctly.
However, this is not the change that I was hoping for ;-).
I think the test "if (finished)" is the problem. It only allows for
custom validation just after the form is finished. The finished variable
comes from some lines above in woody2.js:
finished = this.form.process(formContext);
So it seems the form is validated (i.e. finished) only if the built-in
validation is completed. And my understanding is that the form is not
finished until there are no errors, regardless if they are coming from
the custom validation or not. Therefore, I still think the fix above
does not solve my issues. I my code above I've actually removed the "if
(finished ...)" statement to make the fix working ok.
What do you think?
Alex
Re: woody2.js: custom validation issue in cocoon-2.1.2 to 2.1.4
Posted by Joerg Heinicke <jo...@gmx.de>.
Alex Kovacs <alexk <at> fast.fujitsu.com.au> writes:
> if (this.validator == null) {
> //if no custom validation
> this.isValid = this.form.isValid();
> } else {
> var validated = true;
>
> if(!this.validator(this.form, bizData))
> validated = false;
>
> if(!this.form.isValid())
> validated = false;
>
> this.isValid = validated;
> finished = this.isValid;
> }
I have committed it this way to the forms block in CVS:
if (finished) {
if (this.validator == null) {
this.isValid = this.form.isValid();
} else {
this.isValid = this.form.isValid() & this.validator(this.form, bizData);
}
finished = this.isValid;
}
Should work as well. Can you test it?
Thanks,
Joerg
woody2.js: custom validation issue in cocoon-2.1.2 to 2.1.4
Posted by Alex Kovacs <al...@fast.fujitsu.com.au>.
I may be wrong, but it seems the current implementation of woody2.js
flowscript has a problem when using custom validation together with the
woody's built-in validation.
The following is the current fragment in question:
// Additional flow-level validation
if (finished && this.form.isValid()) {
if (this.validator == null) {
this.isValid = true;
} else {
this.isValid = this.validator(this.form, bizData);
finished = this.isValid;
}
}
The "if" statement is evaluated to true only if the form built-in
validation is successful. Therefore, we will not be able to show any
custom validation messages to the user, until she re-submits the form.
IMHO this is not efficient or intuitive to the user. I would rather have
all the invalid fields displaying the associated error messages and ask
the user to correct them in one go. The code could be restructured like
in the following example:
if (this.validator == null) {
//if no custom validation
this.isValid = this.form.isValid();
} else {
var validated = true;
if(!this.validator(this.form, bizData))
validated = false;
if(!this.form.isValid())
validated = false;
this.isValid = validated;
finished = this.isValid;
}
We are using the above fix in our development and we thought it would be
good to have a fix in cocoon so we do not need to patch it every time we
get a new release.
Rgds,
Alex