You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Luca Garulli <l....@gmail.com> on 2004/11/22 17:31:38 UTC
Client side controls
Hi,
does CForms support minimal client-side validation? Such as
field-length, field-presence, etc.?
Thank you
bye,
Luca Garulli
www.Pro-Netics.com (member of Orixo.com - The XML business alliance)
OrienTechnologies.com - Light ODBMS, All in one JDO solution
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Client side controls
Posted by Reinhard Poetz <re...@apache.org>.
Luca Garulli wrote:
> I try to explain more: for "client side controls" I mean a sort of
> client-side validation using the form-definition rules.
No, not that I know. Patches would be welcome :-)
--
Reinhard
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Client side validation
Posted by Micah Dubinko <md...@snapbridge.com>.
Sylvain Wallez wrote:
> I once proposed that validators could produce a small snippet of JS
> that would be included in the produced page. However, this somehow
> mixes some client-side technology in the validators which isn't a good
> thing.
>
> So the idea now is that a validator produces an XML representation of
> itself, which could be a simple as it's definition translated to the
> "fi:" namespace.
>
> E.g.
>
> <fd:field id="foo" required="true">
> <fd:datatype base="integer"/>
> <fd:validation>
> <fd:range min="1" max="10"/>
> </fd:validation>
> </fd:field>
>
> would produce
> <fi:field id="foo">
> <fi:datatype type="integer"/>
> <fi:validation>
> <fi:required>
> <fi:range min="1" max="10"/>
> </fi:validation>
> </fi:field>
>
> It's then the job of the presentation XSLs to transform <fi:range>
> into something useful.
>
> Only those validators where a client-side implementation is possible
> would produce an XML fragment in the <fi:validation> element.
>
> WDYT?
>
> Sylvain
In my previous work, I did something much like this, and it worked quite
well. I'm heading out the door for travel, but when I return I'll jump
in here.
Thanks,
.micah
Re: Client side validation
Posted by Guido Casper <gc...@s-und-n.de>.
Bertrand Delacretaz wrote:
>> This may be a little off topic and I'm asking out of curiosity what
>> others think. But I wonder if flow (and continuations in particular)
>> and cforms really is an appropriate technology for "rich" (and
>> potentially stateful) clients?
>
>
> It's hard to say without having a concrete example to judge, and I have
> none at this time ;-)
Yes :-) I was hoping someone might already have experience with rich
clients served by Cocoon.
>
> My point was that saying "client-side validation will always be done in
> javascript" sounds a bit too restrictive, I' d rather say "although
> client-side validation will be done in javascript in 95% of the cases,
> we allow other options even if javascript is the standard."
Yes, I agree.
Guido
Re: Client side validation
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 24 nov. 04, à 12:42, Guido Casper a écrit :
> Bertrand Delacretaz wrote:
>> Le 23 nov. 04, à 10:53, oceatoon a écrit :
>>> ...Is different JS really coded for different browsers? I thought
>>> there were
>>> only those with JS and those without, in the second case validation
>>> would
>>> go back to Server Side but no different version of scripts...
>> your (future) client might *not* even be a browser per se. Think
>> Flash, XUL, and related stuff.
>
> This may be a little off topic and I'm asking out of curiosity what
> others think. But I wonder if flow (and continuations in particular)
> and cforms really is an appropriate technology for "rich" (and
> potentially stateful) clients?
It's hard to say without having a concrete example to judge, and I have
none at this time ;-)
My point was that saying "client-side validation will always be done in
javascript" sounds a bit too restrictive, I' d rather say "although
client-side validation will be done in javascript in 95% of the cases,
we allow other options even if javascript is the standard."
-Bertrand
Re: Client side validation
Posted by Reinhard Poetz <re...@apache.org>.
oceatoon wrote:
> Luca Garulli wrote:
>
>
>>On Thu, 25 Nov 2004 16:48:16 +0100, oceatoon <t....@systheo.com>
>>wrote:
>>
>>
>>>No pb , but if you send me your xsl's I can integrate them and help debug
>>>or test drive it, and maybe contribute(t dot katelbach at systheo dot
>>>com)
>>
>>Tibor, I've just sent the component. Let me know.
>
> Thanks will integrate it to my situation
>
>
>>In the meanwhile where can I post it? Wiki?
>>
>
> I'm not quite sure maybe someone else should answer this, but I think the
> way it goes is by sending in a patch through Bugzilla, once validated it'll
> be integrated
Yes that's correct. Open an issue in Bugzilla and use the prefix "[patch]".
That's the safest (and IMH only) way that it doesn't get forgotten.
--
Reinhard
Re: Client side validation
Posted by oceatoon <t....@systheo.com>.
Luca Garulli wrote:
> On Thu, 25 Nov 2004 16:48:16 +0100, oceatoon <t....@systheo.com>
> wrote:
>
>> No pb , but if you send me your xsl's I can integrate them and help debug
>> or test drive it, and maybe contribute(t dot katelbach at systheo dot
>> com)
>
> Tibor, I've just sent the component. Let me know.
Thanks will integrate it to my situation
>
> In the meanwhile where can I post it? Wiki?
>
I'm not quite sure maybe someone else should answer this, but I think the
way it goes is by sending in a patch through Bugzilla, once validated it'll
be integrated
Regards
Tibor
Re: Client side validation
Posted by Luca Garulli <l....@gmail.com>.
On Thu, 25 Nov 2004 16:48:16 +0100, oceatoon <t....@systheo.com> wrote:
> No pb , but if you send me your xsl's I can integrate them and help debug or
> test drive it, and maybe contribute(t dot katelbach at systheo dot com)
Tibor, I've just sent the component. Let me know.
In the meanwhile where can I post it? Wiki?
--
bye,
Luca Garulli
www.Pro-Netics.com (member of Orixo.com - The XML business alliance)
OrienTechnologies.com - Light ODBMS, All in one JDO solution
Re: Client side validation
Posted by oceatoon <t....@systheo.com>.
Luca Garulli wrote:
> On Thu, 25 Nov 2004 13:33:17 +0100, oceatoon <t....@systheo.com>
> wrote:
>> >> But then don't you have double validation ?
>> >
>> > Yes, server side validation must be always guarantee. Client side
>> > validation is useful basically for two reasons:
>> >
>> > 1. avoid unnecessary server load
>> > 2. some customer doesn't want page refresh. There are other techniques
>> > to avoid page reload, but it's a little bit more complex...
>> Yes, with CJS there wouldn't be long reloads, but many reactive
>> validations and one longer send in the end. I'm curious of what you mean
>> by more complex techniques to avoid reload ?
>>
>> Thanks, I guess double validation has to be then,
>> will you publish your transformer to CJS ?
>
> Yes, but I don't know where to post it. Current version of transformer
> generates one function per widget. The transformer gets the "mode"
> parameter:
> = form: checks all fields in one shot, generally in the submit button
> = field: checks each field when the focus is lost, using onBlur()
> event in javascript
ok great, so all potential errors are validated instantly as the user leaves
the widget
>
> Inside the function:
>
> - if required='true', checks if the value is not null
> - if datatype=integer|long, checks the number
> - if datatype=double|decimal, checks the number considering also the
> decimals - if datatype=date, then checks the date format in the (optional)
> format specified in fi:convertor/@pattern
>
> After all single validate functions, the validate_form() function will
> be generated with the call to each functions, aggregating the error
> fields name in the array returned.
correct me if I misunderstood, this is for the case if the user didn't enter
some of the widget? in which case they couldn't be singularely validated,
so you return an array of the remaining errors? sounds good :)
>
> So you can customize the error management with a function like this:
>
> function validate()
> {
> var results = validate_form();
> var msg = "";
> for( var i = 0; i < results.length; ++i )
> {
> msg += "\nError on filed: " + results[i];
> }
> if( results.length > 0 )
> alert( "Error on validation:" + msg );
> }
>
> Please, tell me suggestion and improvement to insert at the fly.
No pb , but if you send me your xsl's I can integrate them and help debug or
test drive it, and maybe contribute(t dot katelbach at systheo dot com)
Thanks
Tibor
Re: Client side validation
Posted by Luca Garulli <l....@gmail.com>.
On Thu, 25 Nov 2004 13:33:17 +0100, oceatoon <t....@systheo.com> wrote:
> >> But then don't you have double validation ?
> >
> > Yes, server side validation must be always guarantee. Client side
> > validation is useful basically for two reasons:
> >
> > 1. avoid unnecessary server load
> > 2. some customer doesn't want page refresh. There are other techniques
> > to avoid page reload, but it's a little bit more complex...
> Yes, with CJS there wouldn't be long reloads, but many reactive validations
> and one longer send in the end. I'm curious of what you mean by more
> complex techniques to avoid reload ?
>
> Thanks, I guess double validation has to be then,
> will you publish your transformer to CJS ?
Yes, but I don't know where to post it. Current version of transformer
generates one function per widget. The transformer gets the "mode"
parameter:
= form: checks all fields in one shot, generally in the submit button
= field: checks each field when the focus is lost, using onBlur()
event in javascript
Inside the function:
- if required='true', checks if the value is not null
- if datatype=integer|long, checks the number
- if datatype=double|decimal, checks the number considering also the decimals
- if datatype=date, then checks the date format in the (optional)
format specified in fi:convertor/@pattern
After all single validate functions, the validate_form() function will
be generated with the call to each functions, aggregating the error
fields name in the array returned.
So you can customize the error management with a function like this:
function validate()
{
var results = validate_form();
var msg = "";
for( var i = 0; i < results.length; ++i )
{
msg += "\nError on filed: " + results[i];
}
if( results.length > 0 )
alert( "Error on validation:" + msg );
}
Please, tell me suggestion and improvement to insert at the fly.
> Thanks
> Tibor
bye,
Luca Garulli
www.Pro-Netics.com (member of Orixo.com - The XML business alliance)
OrienTechnologies.com - Light ODBMS, All in one JDO solution
Re: Client side validation
Posted by oceatoon <t....@systheo.com>.
>> But then don't you have double validation ?
>
> Yes, server side validation must be always guarantee. Client side
> validation is useful basically for two reasons:
>
> 1. avoid unnecessary server load
> 2. some customer doesn't want page refresh. There are other techniques
> to avoid page reload, but it's a little bit more complex...
Yes, with CJS there wouldn't be long reloads, but many reactive validations
and one longer send in the end. I'm curious of what you mean by more
complex techniques to avoid reload ?
Thanks, I guess double validation has to be then,
will you publish your transformer to CJS ?
Thanks
Tibor
Re: Client side validation
Posted by Luca Garulli <l....@gmail.com>.
On Wed, 24 Nov 2004 13:37:06 +0100, oceatoon <t....@systheo.com> wrote:
> But then don't you have double validation ?
Yes, server side validation must be always guarantee. Client side
validation is useful basically for two reasons:
1. avoid unnecessary server load
2. some customer doesn't want page refresh. There are other techniques
to avoid page reload, but it's a little bit more complex...
> talking about performance client side validation removes some load
> (execution time) off the server, which is allways appreciated
Yes (see above)
--
bye,
Luca Garulli
www.Pro-Netics.com (member of Orixo.com - The XML business alliance)
OrienTechnologies.com - Light ODBMS, All in one JDO solution
Re: Client side validation
Posted by Ralph Goers <Ra...@dslextreme.com>.
oceatoon wrote:
>But then don't you have double validation ?
>talking about performance client side validation removes some load
>(execution time) off the server, which is allways appreciated
>
>
>
Yes, you have double validation. But when an error occurs it is more
responsive to the client. Server side validation MUST be performed or
you have a security hole that you can drive a truck through.
Ralph
Re: Client side validation
Posted by Glen Ezkovich <ge...@mac.com>.
On Nov 24, 2004, at 6:37 AM, oceatoon wrote:
> Luca Garulli wrote:
>
>> I think that client-side validation is a very common use case. I'm
>> writing a XSL to apply in the pipeline just after the cform
>> generation.
>>
>> If anyone want client-side validation (always in adding to the
>> server-side validation and never in place of) just insert a
>> transformer specifyng the XSL and some optional parameters.
> But then don't you have double validation ?
> talking about performance client side validation removes some load
> (execution time) off the server, which is allways appreciated
Unfortunately, there are evil users who can circumvent client side
validation and some users whose browsers do not support javascript or
choose to disable it, so you should always have server side validation.
>
> Tibor
>
>
>
>
>
Glen Ezkovich
HardBop Consulting
glen at hard-bop.com
http://www.hard-bop.com
A Proverb for Paranoids:
"If they can get you asking the wrong questions, they don't have to
worry about answers."
- Thomas Pynchon Gravity's Rainbow
Re: Client side validation
Posted by oceatoon <t....@systheo.com>.
Luca Garulli wrote:
> I think that client-side validation is a very common use case. I'm
> writing a XSL to apply in the pipeline just after the cform
> generation.
>
> If anyone want client-side validation (always in adding to the
> server-side validation and never in place of) just insert a
> transformer specifyng the XSL and some optional parameters.
But then don't you have double validation ?
talking about performance client side validation removes some load
(execution time) off the server, which is allways appreciated
Tibor
Re: Client side validation
Posted by Luca Garulli <l....@gmail.com>.
I think that client-side validation is a very common use case. I'm
writing a XSL to apply in the pipeline just after the cform
generation.
If anyone want client-side validation (always in adding to the
server-side validation and never in place of) just insert a
transformer specifyng the XSL and some optional parameters.
bye,
Luca Garulli
www.Pro-Netics.com (member of Orixo.com - The XML business alliance)
OrienTechnologies.com - Light ODBMS, All in one JDO solution
On Wed, 24 Nov 2004 12:42:33 +0100, Guido Casper <gc...@s-und-n.de> wrote:
> Bertrand Delacretaz wrote:
>
>
> > Le 23 nov. 04, à 10:53, oceatoon a écrit :
> >
> >> ...Is different JS really coded for different browsers? I thought
> >> there were
> >> only those with JS and those without, in the second case validation would
> >> go back to Server Side but no different version of scripts...
> >
> >
> > your (future) client might *not* even be a browser per se. Think Flash,
> > XUL, and related stuff.
>
> This may be a little off topic and I'm asking out of curiosity what
> others think. But I wonder if flow (and continuations in particular) and
> cforms really is an appropriate technology for "rich" (and potentially
> stateful) clients?
>
> Guido
Re: Client side validation
Posted by Guido Casper <gc...@s-und-n.de>.
Bertrand Delacretaz wrote:
> Le 23 nov. 04, à 10:53, oceatoon a écrit :
>
>> ...Is different JS really coded for different browsers? I thought
>> there were
>> only those with JS and those without, in the second case validation would
>> go back to Server Side but no different version of scripts...
>
>
> your (future) client might *not* even be a browser per se. Think Flash,
> XUL, and related stuff.
This may be a little off topic and I'm asking out of curiosity what
others think. But I wonder if flow (and continuations in particular) and
cforms really is an appropriate technology for "rich" (and potentially
stateful) clients?
Guido
Re: Client side validation
Posted by oceatoon <t....@systheo.com>.
Bertrand Delacretaz wrote:
> Le 23 nov. 04, à 10:53, oceatoon a écrit :
>> ...Is different JS really coded for different browsers? I thought
>> there were
>> only those with JS and those without, in the second case validation
>> would
>> go back to Server Side but no different version of scripts...
>
> your (future) client might *not* even be a browser per se. Think Flash,
> XUL, and related stuff.
thanks for putting it back into the real Cocoon context of abstraction which
us multiple final layouts, I sometimes get cornered in my use case,the web.
But please correct me I might be completly off track, but if the entier
snippets are written directly as blocks of code, specific to "one" final
result ( otherwise resutl specific validations are needed) , these could
concirn as much actionscript for Flash, i don't know much about XUL but
also for it's own language. and the validation would still be functionnal.
IMHO, it is easier to produce the validation(complex or complex) in the
code we are actively using (coding). Adding more layers of abstraction
seems a complication (I dear to say) that is justified when multiple types
of finale results use one same validation rule translated into each of it's
specific codes.
These solutions being in no way blocking for one another, I hope they both
find there way ;)
Regards
Tibor
Re: Client side validation
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 23 nov. 04, à 10:53, oceatoon a écrit :
> ...Is different JS really coded for different browsers? I thought
> there were
> only those with JS and those without, in the second case validation
> would
> go back to Server Side but no different version of scripts...
your (future) client might *not* even be a browser per se. Think Flash,
XUL, and related stuff.
-Bertrand
Re: Client side validation
Posted by oceatoon <t....@systheo.com>.
>> I once proposed that validators could produce a small snippet of JS that
>> would be included in the produced page. However, this somehow mixes some
>> client-side technology in the validators which isn't a good thing.
>>
>> So the idea now is that a validator produces an XML representation of
>> itself, which could be a simple as it's definition translated to the
>> "fi:" namespace.
>>
>> E.g.
>>
>> <fd:field id="foo" required="true">
>> <fd:datatype base="integer"/>
>> <fd:validation>
>> <fd:range min="1" max="10"/>
>> </fd:validation>
>> </fd:field>
>>
>> would produce
>> <fi:field id="foo">
>> <fi:datatype type="integer"/>
>> <fi:validation>
>> <fi:required>
>> <fi:range min="1" max="10"/>
>> </fi:validation>
>> </fi:field>
>>
>> It's then the job of the presentation XSLs to transform <fi:range> into
>> something useful.
Yes but isn't this restrained to very simple validations?
>>
>> Only those validators where a client-side implementation is possible
>> would produce an XML fragment in the <fi:validation> element.
>>
> yep, that's the way to go! If widgets produced Javascript themselves, we
> would mix concerns because not all clients support Javascript or you need
> different Javascript "dialects" for different clients.
Is different JS really coded for different browsers? I thought there were
only those with JS and those without, in the second case validation would
go back to Server Side but no different version of scripts
> Following Sylvain's
> proposal it's the stylesheet's job to create working valdiation programms.
>
> We should also think of a way how and where we can add custom client-side
> validators. If we add this to the form defintion we would need some kind
> of abstract language, or at least Javascript with an abstract object
> model:
Yes, but we could also directly code the outcoming code, therefore no
generalised translation, no limits of complexity in CJS, and a brut copy of
the JS snippet into xhtml using the XSL if fi:CJS exist
>
> <ft:client-side-validation>
> if($widgetXY.value$ <= $widgetZZ.value$ {
> return "i18:value-to-high";
> }
> return true;
> </ft:client-side-validation>
CJS validation is in the template in this case, why not keep it in the model
<fd:validation>
<fd:range min="1" max="10"/>
</fd:validation>
<fd:cjsvalidation>
if(this.value >= 1 and this.value <= 10) {
return "cocoricco";
}
</fd:cjsvalidation>
(This translation could be done in the stylesheet by translating the server
validation as Luca Garulli proposed but this is restrained to the basic
valdiation rules)
or
for widgetXY for your example
<fd:cjsvalidation>
if(this.value >= forms_getForm(widgetZZ).widgetZZ.vlue) {
return "cocoricco";
}
</fd:cjsvalidation>
Regards,
Tibor
Re: Client side validation
Posted by Reinhard Poetz <re...@apache.org>.
Sylvain Wallez wrote:
> Reinhard Poetz wrote:
>>
>> yep, that's the way to go! If widgets produced Javascript themselves,
>> we would mix concerns because not all clients support Javascript or
>> you need different Javascript "dialects" for different clients.
>> Following Sylvain's proposal it's the stylesheet's job to create
>> working valdiation programms.
>>
>> We should also think of a way how and where we can add custom
>> client-side validators. If we add this to the form defintion we would
>> need some kind of abstract language, or at least Javascript with an
>> abstract object model:
>>
>> <ft:client-side-validation>
>> if($widgetXY.value$ <= $widgetZZ.value$ {
>> return "i18:value-to-high";
>> }
>> return true;
>> </ft:client-side-validation>
>>
>> This could be transformed into something valid for the client by
>> replacing the $...$-tokens through valid pointers to the client's
>> object model.
>
>
>
> Or simply an abstract getWidgetValue(name) function that would have
> different implementations server-side and client-side? That way, we
> don't need macro expansion and we can use a single JS snippet for both
> client and server-side validation.
>
> Of course, not every JS validator can run client-side, and that needs to
> be distinguished with a particular attribute:
Should work either. Maybe the guys with the usecases can tell us more and then
we talk about the abstraction level.
--
Reinhard
Re: Client side validation
Posted by Luca Garulli <l....@gmail.com>.
On Tue, 23 Nov 2004 10:12:52 +0100, Sylvain Wallez <sy...@apache.org> wrote:
> Or simply an abstract getWidgetValue(name) function that would have
> different implementations server-side and client-side? That way, we
> don't need macro expansion and we can use a single JS snippet for both
> client and server-side validation.
>
> Of course, not every JS validator can run client-side, and that needs to
> be distinguished with a particular attribute:
Great!
--
bye,
Luca Garulli
www.Pro-Netics.com (member of Orixo.com - The XML business alliance)
OrienTechnologies.com - Light ODBMS, All in one JDO solution
Re: Client side validation
Posted by Sylvain Wallez <sy...@apache.org>.
Reinhard Poetz wrote:
> Sylvain Wallez wrote:
>> I once proposed that validators could produce a small snippet of JS
>> that would be included in the produced page. However, this somehow
>> mixes some client-side technology in the validators which isn't a
>> good thing.
>>
>> So the idea now is that a validator produces an XML representation of
>> itself, which could be a simple as it's definition translated to the
>> "fi:" namespace.
>>
>> E.g.
>>
>> <fd:field id="foo" required="true">
>> <fd:datatype base="integer"/>
>> <fd:validation>
>> <fd:range min="1" max="10"/>
>> </fd:validation>
>> </fd:field>
>>
>> would produce
>> <fi:field id="foo">
>> <fi:datatype type="integer"/>
>> <fi:validation>
>> <fi:required>
>> <fi:range min="1" max="10"/>
>> </fi:validation>
>> </fi:field>
>>
>> It's then the job of the presentation XSLs to transform <fi:range>
>> into something useful.
>>
>> Only those validators where a client-side implementation is possible
>> would produce an XML fragment in the <fi:validation> element.
>>
>> WDYT?
>
>
> yep, that's the way to go! If widgets produced Javascript themselves,
> we would mix concerns because not all clients support Javascript or
> you need different Javascript "dialects" for different clients.
> Following Sylvain's proposal it's the stylesheet's job to create
> working valdiation programms.
>
> We should also think of a way how and where we can add custom
> client-side validators. If we add this to the form defintion we would
> need some kind of abstract language, or at least Javascript with an
> abstract object model:
>
> <ft:client-side-validation>
> if($widgetXY.value$ <= $widgetZZ.value$ {
> return "i18:value-to-high";
> }
> return true;
> </ft:client-side-validation>
>
> This could be transformed into something valid for the client by
> replacing the $...$-tokens through valid pointers to the client's
> object model.
Or simply an abstract getWidgetValue(name) function that would have
different implementations server-side and client-side? That way, we
don't need macro expansion and we can use a single JS snippet for both
client and server-side validation.
Of course, not every JS validator can run client-side, and that needs to
be distinguished with a particular attribute:
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Client side validation
Posted by Reinhard Poetz <re...@apache.org>.
Sylvain Wallez wrote:
> oceatoon wrote:
>
>> Sylvain Wallez wrote:
>>
>>
>>
>>> [Moving a private email to dev@ as it's really where it should be
>>> [discussed]
>>>
>>> Luca Garulli wrote:
>>>
>>>
>>>
>>>> Hi,
>>>> my customer want a minimal client-side validation for same fields. We
>>>> are using CForms and seems to be lack of this feature.
>>>>
>>>> I'd like to have a single place where to describe validation rules:
>>>> the form definition. Anyone has implemented something like a
>>>> client-side validation that use the form-definition rules?
>>>>
>>>> If not I can start to write it. I think that it's a common use case.
>>>>
>>>>
>>>>
>>>
>>> Yes, that's a common use case and we already talked about it but never
>>> got the time to implement it.
>>>
>>> There are different kinds of client-side validation
>>> - field presence for required fields
>>> - datatype syntax : integer, date, taking the locale-dependent format
>>> into account
>>> - additional validations.
>>>
>>> The first item should be easy, and the second one can leverage the
>>> datatype information that is already present in a field's XML output
>>> (used e.g. to trigger the use of the calendar widget)
>>>
>>> The third one is trickier, as some validation rules can be controlled on
>>> the client (e.g. range, regexp) whereas others can't. What we can do
>>> here is adding a generateSAXFragment to validation rules also, so that
>>> those rule that can be implemented on the client can produce an XML
>>> description that will be translated to JavaScript by the presentation
>>> stylesheets.
>>>
>>> WDYT?
>>>
>>
>>
>> Sorry to walk into post but this mailing list is amasing, answers come up
>> simultaneously to my personnal questions, thx for reading my mind ;) I am
>> exactly on this problem coz formy case Server side validations is a
>> bit too
>> heavy. I'd be glad to help if needed since our project will need it too
>>
>> Would this mean, Client side JS would be written in the models validation
>> tags, and the form generator would return something like this:
>> <fi:CJS>
>> JScode or call2function.....
>> </fi:CJS>
>> where JScode would be directly connected to the input @onchange for
>> example : <intput type="text" onchange="JScode"/>
>>
>> and
>> call2function would call a function that is either written in the
>> model and
>> iserted, either written or included directly in the page containing the
>> ft:form-template and the concirned widget .
>> unfortunetly I'm more of a user and I can deal with the stylesheet or JS
>> development if the SaxFragment sends the fi:CJS, but I'm not familiar
>> with
>> insides of CForms.
>>
>>
>
> I once proposed that validators could produce a small snippet of JS that
> would be included in the produced page. However, this somehow mixes some
> client-side technology in the validators which isn't a good thing.
>
> So the idea now is that a validator produces an XML representation of
> itself, which could be a simple as it's definition translated to the
> "fi:" namespace.
>
> E.g.
>
> <fd:field id="foo" required="true">
> <fd:datatype base="integer"/>
> <fd:validation>
> <fd:range min="1" max="10"/>
> </fd:validation>
> </fd:field>
>
> would produce
> <fi:field id="foo">
> <fi:datatype type="integer"/>
> <fi:validation>
> <fi:required>
> <fi:range min="1" max="10"/>
> </fi:validation>
> </fi:field>
>
> It's then the job of the presentation XSLs to transform <fi:range> into
> something useful.
>
> Only those validators where a client-side implementation is possible
> would produce an XML fragment in the <fi:validation> element.
>
> WDYT?
yep, that's the way to go! If widgets produced Javascript themselves, we would
mix concerns because not all clients support Javascript or you need different
Javascript "dialects" for different clients. Following Sylvain's proposal it's
the stylesheet's job to create working valdiation programms.
We should also think of a way how and where we can add custom client-side
validators. If we add this to the form defintion we would need some kind of
abstract language, or at least Javascript with an abstract object model:
<ft:client-side-validation>
if($widgetXY.value$ <= $widgetZZ.value$ {
return "i18:value-to-high";
}
return true;
</ft:client-side-validation>
This could be transformed into something valid for the client by replacing the
$...$-tokens through valid pointers to the client's object model.
--
Reinhard
Re: Client side validation
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 22 nov. 04, à 23:44, Sylvain Wallez a écrit :
> ...So the idea now is that a validator produces an XML representation
> of itself, which could be a simple as it's definition translated to
> the "fi:" namespace....
>
> ...It's then the job of the presentation XSLs to transform <fi:range>
> into something useful.
>
> Only those validators where a client-side implementation is possible
> would produce an XML fragment in the <fi:validation> element.
I like the idea, +1
-Bertrand
Re: Client side validation
Posted by Luca Garulli <l....@gmail.com>.
On Mon, 22 Nov 2004 23:44:33 +0100, Sylvain Wallez <sy...@apache.org> wrote:
> So the idea now is that a validator produces an XML representation of
> itself, which could be a simple as it's definition translated to the
> "fi:" namespace.
>
> E.g.
>
> <fd:field id="foo" required="true">
> <fd:datatype base="integer"/>
> <fd:validation>
> <fd:range min="1" max="10"/>
> </fd:validation>
> </fd:field>
>
> would produce
> <fi:field id="foo">
> <fi:datatype type="integer"/>
> <fi:validation>
> <fi:required>
> <fi:range min="1" max="10"/>
> </fi:validation>
> </fi:field>
>
> It's then the job of the presentation XSLs to transform <fi:range> into
> something useful.
>
> Only those validators where a client-side implementation is possible
> would produce an XML fragment in the <fi:validation> element.
>
> WDYT?
IMHO the idea to move the <fi:required/> tag inside <fi:validation>
it's conceptually better than leaving it as attribute of field tag.
However "required" it's always a validation concept.
--
bye,
Luca Garulli
www.Pro-Netics.com (member of Orixo.com - The XML business alliance)
OrienTechnologies.com - Light ODBMS, All in one JDO solution
Re: Client side validation
Posted by Sylvain Wallez <sy...@apache.org>.
oceatoon wrote:
>Sylvain Wallez wrote:
>
>
>
>>[Moving a private email to dev@ as it's really where it should be
>>[discussed]
>>
>>Luca Garulli wrote:
>>
>>
>>
>>>Hi,
>>>my customer want a minimal client-side validation for same fields. We
>>>are using CForms and seems to be lack of this feature.
>>>
>>>I'd like to have a single place where to describe validation rules:
>>>the form definition. Anyone has implemented something like a
>>>client-side validation that use the form-definition rules?
>>>
>>>If not I can start to write it. I think that it's a common use case.
>>>
>>>
>>>
>>>
>>Yes, that's a common use case and we already talked about it but never
>>got the time to implement it.
>>
>>There are different kinds of client-side validation
>>- field presence for required fields
>>- datatype syntax : integer, date, taking the locale-dependent format
>>into account
>>- additional validations.
>>
>>The first item should be easy, and the second one can leverage the
>>datatype information that is already present in a field's XML output
>>(used e.g. to trigger the use of the calendar widget)
>>
>>The third one is trickier, as some validation rules can be controlled on
>>the client (e.g. range, regexp) whereas others can't. What we can do
>>here is adding a generateSAXFragment to validation rules also, so that
>>those rule that can be implemented on the client can produce an XML
>>description that will be translated to JavaScript by the presentation
>>stylesheets.
>>
>>WDYT?
>>
>>
>
>Sorry to walk into post but this mailing list is amasing, answers come up
>simultaneously to my personnal questions, thx for reading my mind ;) I am
>exactly on this problem coz formy case Server side validations is a bit too
>heavy. I'd be glad to help if needed since our project will need it too
>
>Would this mean, Client side JS would be written in the models validation
>tags, and the form generator would return something like this:
><fi:CJS>
> JScode or call2function.....
></fi:CJS>
>where JScode would be directly connected to the input @onchange for
>example : <intput type="text" onchange="JScode"/>
>
>and
>
>call2function would call a function that is either written in the model and
>iserted, either written or included directly in the page containing the
>ft:form-template and the concirned widget .
>
>unfortunetly I'm more of a user and I can deal with the stylesheet or JS
>development if the SaxFragment sends the fi:CJS, but I'm not familiar with
>insides of CForms.
>
>
I once proposed that validators could produce a small snippet of JS that
would be included in the produced page. However, this somehow mixes some
client-side technology in the validators which isn't a good thing.
So the idea now is that a validator produces an XML representation of
itself, which could be a simple as it's definition translated to the
"fi:" namespace.
E.g.
<fd:field id="foo" required="true">
<fd:datatype base="integer"/>
<fd:validation>
<fd:range min="1" max="10"/>
</fd:validation>
</fd:field>
would produce
<fi:field id="foo">
<fi:datatype type="integer"/>
<fi:validation>
<fi:required>
<fi:range min="1" max="10"/>
</fi:validation>
</fi:field>
It's then the job of the presentation XSLs to transform <fi:range> into
something useful.
Only those validators where a client-side implementation is possible
would produce an XML fragment in the <fi:validation> element.
WDYT?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Client side validation
Posted by Ralph Goers <Ra...@dslextreme.com>.
oceatoon said:
>
> Sorry to walk into post but this mailing list is amasing, answers come up
> simultaneously to my personnal questions, thx for reading my mind ;) I am
> exactly on this problem coz formy case Server side validations is a bit
> too
> heavy. I'd be glad to help if needed since our project will need it too
>
While client side validation is a good thing as it can give the user
faster validation and uses up less server side resources, IMO validation
should ALWAYS be also done on the server side. Without it you are setting
yourself up for security holes since requests can always be hand-crafted
to bypass your client-side validation. I can think of a few exceptional
cases to this, but over time as the site grows this is probably bound to
change.
Ralph
Re: Client side validation
Posted by Luca Garulli <l....@gmail.com>.
On Mon, 22 Nov 2004 23:49:04 +0100, Sylvain Wallez <sy...@apache.org> wrote:
> Considering that the object model are very different in the form and in
> the client, that seems difficult to me.
Think to a function that make some checks on date values. If this JS
doesn't contain any references to the server-side object model
(cocoon, java snippets, etc.) it may be deployed in both sides: client
and server. Obviously any dependency with the server side object model
should be passed by function parameters.
This feature (shoulds) already works in current cocoon.
> Please consider my proposal of having validators output an XML fragment
> that is later transformed to JS by the presentation stylesheets. It
> would just require to upgrade the XSLs.
Yes, a XSL it's better than a transformer, something like
client-validation-js.xsl ?
--
bye,
Luca Garulli
www.Pro-Netics.com (member of Orixo.com - The XML business alliance)
OrienTechnologies.com - Light ODBMS, All in one JDO solution
Re: Client side validation
Posted by Sylvain Wallez <sy...@apache.org>.
Luca Garulli wrote:
>In theory we can have some JS script that can be usable in client AND
>server sides. If these scripts contains no dependencies with
>flowscript objects (cocoon, etc) and Java code we can deploy to both
>sides!
>
>
Considering that the object model are very different in the form and in
the client, that seems difficult to me.
>However what I'd like to see is to reuse the validation rules in the
>form-definition. Implementing "assert" is much more difficult. As
>Sylvain wrote, should be quite simple to implement three kinds of
>validations: check on field presence, basic format checks and a custom
>function.
>
>This should cover the 90% of user requirements.
>
>We need this feature soon, so I've thinked to write a transformer that
>enrich the form instance with javascript functions (Decorator Pattern)
>and can be placed in the pipeline just before the final XSL.
>
>
Please consider my proposal of having validators output an XML fragment
that is later transformed to JS by the presentation stylesheets. It
would just require to upgrade the XSLs.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Client side validation
Posted by Luca Garulli <l....@gmail.com>.
In theory we can have some JS script that can be usable in client AND
server sides. If these scripts contains no dependencies with
flowscript objects (cocoon, etc) and Java code we can deploy to both
sides!
However what I'd like to see is to reuse the validation rules in the
form-definition. Implementing "assert" is much more difficult. As
Sylvain wrote, should be quite simple to implement three kinds of
validations: check on field presence, basic format checks and a custom
function.
This should cover the 90% of user requirements.
We need this feature soon, so I've thinked to write a transformer that
enrich the form instance with javascript functions (Decorator Pattern)
and can be placed in the pipeline just before the final XSL.
The generation should write one check-function per widget since the
control may occurs on focus change (onBlur) or on submit.
If the transformer works fine some committer may decide to englobe it
in the CForm lib.
Bye,
Luca Garulli
www.Pro-Netics.com (member of Orixo.com - The XML business alliance)
OrienTechnologies.com - Light ODBMS, All in one JDO solution
On Mon, 22 Nov 2004 20:05:58 +0100, oceatoon <t....@systheo.com> wrote:
> Sylvain Wallez wrote:
>
> > [Moving a private email to dev@ as it's really where it should be
> > [discussed]
> >
> > Luca Garulli wrote:
> >
> >>Hi,
> >>my customer want a minimal client-side validation for same fields. We
> >>are using CForms and seems to be lack of this feature.
> >>
> >>I'd like to have a single place where to describe validation rules:
> >>the form definition. Anyone has implemented something like a
> >>client-side validation that use the form-definition rules?
> >>
> >>If not I can start to write it. I think that it's a common use case.
> >>
> >>
> >
> > Yes, that's a common use case and we already talked about it but never
> > got the time to implement it.
> >
> > There are different kinds of client-side validation
> > - field presence for required fields
> > - datatype syntax : integer, date, taking the locale-dependent format
> > into account
> > - additional validations.
> >
> > The first item should be easy, and the second one can leverage the
> > datatype information that is already present in a field's XML output
> > (used e.g. to trigger the use of the calendar widget)
> >
> > The third one is trickier, as some validation rules can be controlled on
> > the client (e.g. range, regexp) whereas others can't. What we can do
> > here is adding a generateSAXFragment to validation rules also, so that
> > those rule that can be implemented on the client can produce an XML
> > description that will be translated to JavaScript by the presentation
> > stylesheets.
> >
> > WDYT?
>
> Sorry to walk into post but this mailing list is amasing, answers come up
> simultaneously to my personnal questions, thx for reading my mind ;) I am
> exactly on this problem coz formy case Server side validations is a bit too
> heavy. I'd be glad to help if needed since our project will need it too
>
> Would this mean, Client side JS would be written in the models validation
> tags, and the form generator would return something like this:
> <fi:CJS>
> JScode or call2function.....
> </fi:CJS>
> where JScode would be directly connected to the input @onchange for
> example : <intput type="text" onchange="JScode"/>
>
> and
>
> call2function would call a function that is either written in the model and
> iserted, either written or included directly in the page containing the
> ft:form-template and the concirned widget .
>
> unfortunetly I'm more of a user and I can deal with the stylesheet or JS
> development if the SaxFragment sends the fi:CJS, but I'm not familiar with
> insides of CForms.
>
> Regards
> Tibor
Re: Client side validation
Posted by oceatoon <t....@systheo.com>.
Sylvain Wallez wrote:
> [Moving a private email to dev@ as it's really where it should be
> [discussed]
>
> Luca Garulli wrote:
>
>>Hi,
>>my customer want a minimal client-side validation for same fields. We
>>are using CForms and seems to be lack of this feature.
>>
>>I'd like to have a single place where to describe validation rules:
>>the form definition. Anyone has implemented something like a
>>client-side validation that use the form-definition rules?
>>
>>If not I can start to write it. I think that it's a common use case.
>>
>>
>
> Yes, that's a common use case and we already talked about it but never
> got the time to implement it.
>
> There are different kinds of client-side validation
> - field presence for required fields
> - datatype syntax : integer, date, taking the locale-dependent format
> into account
> - additional validations.
>
> The first item should be easy, and the second one can leverage the
> datatype information that is already present in a field's XML output
> (used e.g. to trigger the use of the calendar widget)
>
> The third one is trickier, as some validation rules can be controlled on
> the client (e.g. range, regexp) whereas others can't. What we can do
> here is adding a generateSAXFragment to validation rules also, so that
> those rule that can be implemented on the client can produce an XML
> description that will be translated to JavaScript by the presentation
> stylesheets.
>
> WDYT?
Sorry to walk into post but this mailing list is amasing, answers come up
simultaneously to my personnal questions, thx for reading my mind ;) I am
exactly on this problem coz formy case Server side validations is a bit too
heavy. I'd be glad to help if needed since our project will need it too
Would this mean, Client side JS would be written in the models validation
tags, and the form generator would return something like this:
<fi:CJS>
JScode or call2function.....
</fi:CJS>
where JScode would be directly connected to the input @onchange for
example : <intput type="text" onchange="JScode"/>
and
call2function would call a function that is either written in the model and
iserted, either written or included directly in the page containing the
ft:form-template and the concirned widget .
unfortunetly I'm more of a user and I can deal with the stylesheet or JS
development if the SaxFragment sends the fi:CJS, but I'm not familiar with
insides of CForms.
Regards
Tibor
Re: Client side validation
Posted by Sylvain Wallez <sy...@apache.org>.
[Moving a private email to dev@ as it's really where it should be discussed]
Luca Garulli wrote:
>Hi,
>my customer want a minimal client-side validation for same fields. We
>are using CForms and seems to be lack of this feature.
>
>I'd like to have a single place where to describe validation rules:
>the form definition. Anyone has implemented something like a
>client-side validation that use the form-definition rules?
>
>If not I can start to write it. I think that it's a common use case.
>
>
Yes, that's a common use case and we already talked about it but never
got the time to implement it.
There are different kinds of client-side validation
- field presence for required fields
- datatype syntax : integer, date, taking the locale-dependent format
into account
- additional validations.
The first item should be easy, and the second one can leverage the
datatype information that is already present in a field's XML output
(used e.g. to trigger the use of the calendar widget)
The third one is trickier, as some validation rules can be controlled on
the client (e.g. range, regexp) whereas others can't. What we can do
here is adding a generateSAXFragment to validation rules also, so that
those rule that can be implemented on the client can produce an XML
description that will be translated to JavaScript by the presentation
stylesheets.
WDYT?
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Client side controls
Posted by Luca Garulli <l....@gmail.com>.
I try to explain more: for "client side controls" I mean a sort of
client-side validation using the form-definition rules.
bye,
Luca Garulli
www.Pro-Netics.com (member of Orixo.com - The XML business alliance)
OrienTechnologies.com - Light ODBMS, All in one JDO solution
On Mon, 22 Nov 2004 17:31:38 +0100, Luca Garulli <l....@gmail.com> wrote:
> Hi,
> does CForms support minimal client-side validation? Such as
> field-length, field-presence, etc.?
>
> Thank you
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org