Re: Logging and Form Validation

[Ivelin Ivanov]

Actually I realized that you probably meant to write:

http://xml.apache.org/cocoon/howto/xmlform-wizard/howto-xmlform-wizard.html

which works.


Ivelin Ivanov wrote:
> 
> The original link still works.
> The new one is 404.
> Did you mean that it will be like that after the next live site update.
> When is it? Would there be a redirect in place for people who bookmarked 
> the old link?
> 
> Ivelin
> 
> 
> Diana Shannon wrote:
> 
>>
>> On Saturday, June 8, 2002, at 12:27  AM, Ivelin Ivanov wrote:
>>
>>>
>>> You may want to look at this:
>>> http://xml.apache.org/cocoon/xmlform/index.html
>>
>>
>>
>> Please note that this link was just changed to:
>>  http://xml.apache.org/cocoon/howto/xmlform-wizard/howto-xmlform-
>> wizard.html
>>
>> Diana
>>
>>>
>>>
>>> - Original Message -
>>> From: <[EMAIL PROTECTED]>
>>> To: <[EMAIL PROTECTED]>
>>> Sent: Friday, June 07, 2002 11:58 AM
>>> Subject: Logging and Form Validation
>>>
>>>
 Group,

 I am implmenting a five page form, and I am wondering how I should 
 do the
 validation of fields.

 Can anyone give me a good comparison in brief of javascript vs. 
 cocoon for
 doing the validation?

 I am looking for how it would be accomplished pass content of forms to
>>>
>>>
>>> bean
>>>
 through servlet, etc...

 I need this for our exploration phase of XP, where we are choosing
 architecture.  This is a major
 sticking point for my developers that like and are comfortable with jsp
 with javascript embedded.
 They want to keep it at the client and I am trying to build a case 
 for the
 server through cocoon.

 Thanks,
 Adam



 -
 Please check that your question has not already been answered in the
 FAQ before posting. 

 To unsubscribe, e-mail: <[EMAIL PROTECTED]>
 For additional commands, e-mail: <[EMAIL PROTECTED]>

>>>
>>>
>>> -
>>> Please check that your question has not already been answered in the
>>> FAQ before posting. 
>>>
>>> To unsubscribe, e-mail: <[EMAIL PROTECTED]>
>>> For additional commands, e-mail: <[EMAIL PROTECTED]>
>>>
>>
>>
>> -
>> Please check that your question has not already been answered in the
>> FAQ before posting. 
>>
>> To unsubscribe, e-mail: <[EMAIL PROTECTED]>
>> For additional commands, e-mail: <[EMAIL PROTECTED]>
>>
>>
> 
> 
> 



-- 

-= Ivelin =-


-
Please check that your question has not already been answered in the
FAQ before posting. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail: <[EMAIL PROTECTED]>

Re: Logging and Form Validation

[Ivelin Ivanov]

The original link still works.
The new one is 404.
Did you mean that it will be like that after the next live site update.
When is it? Would there be a redirect in place for people who bookmarked 
the old link?

Ivelin


Diana Shannon wrote:
> 
> On Saturday, June 8, 2002, at 12:27  AM, Ivelin Ivanov wrote:
> 
>>
>> You may want to look at this:
>> http://xml.apache.org/cocoon/xmlform/index.html
> 
> 
> Please note that this link was just changed to:
>  http://xml.apache.org/cocoon/howto/xmlform-wizard/howto-xmlform-
> wizard.html
> 
> Diana
> 
>>
>>
>> - Original Message -
>> From: <[EMAIL PROTECTED]>
>> To: <[EMAIL PROTECTED]>
>> Sent: Friday, June 07, 2002 11:58 AM
>> Subject: Logging and Form Validation
>>
>>
>>> Group,
>>>
>>> I am implmenting a five page form, and I am wondering how I should do 
>>> the
>>> validation of fields.
>>>
>>> Can anyone give me a good comparison in brief of javascript vs. 
>>> cocoon for
>>> doing the validation?
>>>
>>> I am looking for how it would be accomplished pass content of forms to
>>
>> bean
>>
>>> through servlet, etc...
>>>
>>> I need this for our exploration phase of XP, where we are choosing
>>> architecture.  This is a major
>>> sticking point for my developers that like and are comfortable with jsp
>>> with javascript embedded.
>>> They want to keep it at the client and I am trying to build a case 
>>> for the
>>> server through cocoon.
>>>
>>> Thanks,
>>> Adam
>>>
>>>
>>>
>>> -
>>> Please check that your question has not already been answered in the
>>> FAQ before posting. 
>>>
>>> To unsubscribe, e-mail: <[EMAIL PROTECTED]>
>>> For additional commands, e-mail: <[EMAIL PROTECTED]>
>>>
>>
>>
>> -
>> Please check that your question has not already been answered in the
>> FAQ before posting. 
>>
>> To unsubscribe, e-mail: <[EMAIL PROTECTED]>
>> For additional commands, e-mail: <[EMAIL PROTECTED]>
>>
> 
> 
> -
> Please check that your question has not already been answered in the
> FAQ before posting. 
> 
> To unsubscribe, e-mail: <[EMAIL PROTECTED]>
> For additional commands, e-mail: <[EMAIL PROTECTED]>
> 
> 



-- 

-= Ivelin =-


-
Please check that your question has not already been answered in the
FAQ before posting. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail: <[EMAIL PROTECTED]>

Re: Logging and Form Validation

[Diana Shannon]

On Saturday, June 8, 2002, at 12:27  AM, Ivelin Ivanov wrote:

>
> You may want to look at this:
> http://xml.apache.org/cocoon/xmlform/index.html

Please note that this link was just changed to:
  http://xml.apache.org/cocoon/howto/xmlform-wizard/howto-xmlform-
wizard.html

Diana
>
>
> - Original Message -
> From: <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Friday, June 07, 2002 11:58 AM
> Subject: Logging and Form Validation
>
>
>> Group,
>>
>> I am implmenting a five page form, and I am wondering how I should do 
>> the
>> validation of fields.
>>
>> Can anyone give me a good comparison in brief of javascript vs. cocoon 
>> for
>> doing the validation?
>>
>> I am looking for how it would be accomplished pass content of forms to
> bean
>> through servlet, etc...
>>
>> I need this for our exploration phase of XP, where we are choosing
>> architecture.  This is a major
>> sticking point for my developers that like and are comfortable with jsp
>> with javascript embedded.
>> They want to keep it at the client and I am trying to build a case for 
>> the
>> server through cocoon.
>>
>> Thanks,
>> Adam
>>
>>
>>
>> -
>> Please check that your question has not already been answered in the
>> FAQ before posting. 
>>
>> To unsubscribe, e-mail: <[EMAIL PROTECTED]>
>> For additional commands, e-mail: <[EMAIL PROTECTED]>
>>
>
>
> -
> Please check that your question has not already been answered in the
> FAQ before posting. 
>
> To unsubscribe, e-mail: <[EMAIL PROTECTED]>
> For additional commands, e-mail: <[EMAIL PROTECTED]>
>


-
Please check that your question has not already been answered in the
FAQ before posting. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail: <[EMAIL PROTECTED]>

Re: Logging and Form Validation

[Ivelin Ivanov]

You may want to look at this:
http://xml.apache.org/cocoon/xmlform/index.html


- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, June 07, 2002 11:58 AM
Subject: Logging and Form Validation


> Group,
>
> I am implmenting a five page form, and I am wondering how I should do the
> validation of fields.
>
> Can anyone give me a good comparison in brief of javascript vs. cocoon for
> doing the validation?
>
> I am looking for how it would be accomplished pass content of forms to
bean
> through servlet, etc...
>
> I need this for our exploration phase of XP, where we are choosing
> architecture.  This is a major
> sticking point for my developers that like and are comfortable with jsp
> with javascript embedded.
> They want to keep it at the client and I am trying to build a case for the
> server through cocoon.
>
> Thanks,
> Adam
>
>
>
> -
> Please check that your question has not already been answered in the
> FAQ before posting. 
>
> To unsubscribe, e-mail: <[EMAIL PROTECTED]>
> For additional commands, e-mail: <[EMAIL PROTECTED]>
>


-
Please check that your question has not already been answered in the
FAQ before posting. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail: <[EMAIL PROTECTED]>

RE: Logging and Form Validation

[Artur Bialecki]

This is what we do for client side validation.
WARNING: requires javascript but my clients are not
"regular" web users.

For my app I provide validation in my XSP, eg:
  

  
   ^$|^[0-9a-zA-Z_]+$/ig
  
  


  
   ^$|^[0-9a-zA-Z.,_\\-]+\\@[0-9a-zA-Z._\\-]+\\.[a-zA-Z]+$/ig
  
 
   

so for each from field that needs to be validated I have 
 with id of the form field and one or more rules.
I also provide validation template that reads the /page/validators
and creates validateAndSubmit() javascript function that
validates all fileds specified in XSP.
Form filed name must match validator names but that's easy.
I define validators in XSP since some of them are based
on DB queries.

This works great for us.

We also validate on server side with automagic annotation
of errors and from field repopulation since not everything
can be validated on the client side (eg: does city Bumbomie
exsits?) so I our clients ask for support for javascripless
browers (which they wont) it will still work.

Just my 2 cents.

Artur


-
Please check that your question has not already been answered in the
FAQ before posting. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail: <[EMAIL PROTECTED]>

Re: Logging and Form Validation

[Lajos Moczar]

Another point worth mentioning is complexity. I have done some sites 
stuffed so full of JS that things started breaking without any reason. 
JS has inherent flaws (in my experience) that prevent it from doing the 
complex sorts of things many clients need. For small-scale validation, 
no problem. But for complex operations, like Adam's example, I'll stick 
with Cocoon and have the client upgrade their servers, if need be.

Lajos
galatea.com


Andrew Savory wrote:

> Hi,
> 
> On Fri, 7 Jun 2002, Luca Morandini wrote:
> 
> 
>>wait: how many users out there are without JavaScript support ?
>>
> 
> Irrelevant question - if there is only one user without javascript
> support, you should support that user, surely? The point of the web being
> accessibility and the point of a web developer being to develop for the
> *web* and not for specific web browsers? It's frustrating that people are
> STILL assuming support for X, Y and Z in browsers even after so many years
> of browser wars.
> 
> 
>>I won't write both validations, I don't simply cater to people wihout
>>Javascript... and I wonder how many developers pay attention to those
>>unlucky fellows.
>>
> 
> Well, if you're lucky enough to have clients that are happy with sites
> that only do client-side validation that only works in specific browsers
> with specific options enabled, fair enough. I could rant on here about
> text-mode browsers, line readers, security-conscious users that surf with
> scripting turned off, etc, but given you're using Cocoon, I'm sure you
> know how easy it is to provide support for these other browsers simply by
> adding more stylesheets ;-)
> 
> Adam: in answer to your question, take a look at:
>   src/webapp/docs/samples/formvalidation/descriptor.xml
> ...which gives a nice example of doing form validation using XML
> descriptors. See also:
>   http://xml.apache.org/cocoon/xmlform/step2-xmlform-howto.html
> ...for the new way of doing things.
> 
> Hope that helps,
> 
> 
> Andrew.
> 
> 


-- 
Lajos

Cocoon training, consulting & support
galatea.com


-
Please check that your question has not already been answered in the
FAQ before posting. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail: <[EMAIL PROTECTED]>

RE: Logging and Form Validation

[Andrew Savory]

Hi,

On Fri, 7 Jun 2002, Luca Morandini wrote:

> wait: how many users out there are without JavaScript support ?

Irrelevant question - if there is only one user without javascript
support, you should support that user, surely? The point of the web being
accessibility and the point of a web developer being to develop for the
*web* and not for specific web browsers? It's frustrating that people are
STILL assuming support for X, Y and Z in browsers even after so many years
of browser wars.


> I won't write both validations, I don't simply cater to people wihout
> Javascript... and I wonder how many developers pay attention to those
> unlucky fellows.

Well, if you're lucky enough to have clients that are happy with sites
that only do client-side validation that only works in specific browsers
with specific options enabled, fair enough. I could rant on here about
text-mode browsers, line readers, security-conscious users that surf with
scripting turned off, etc, but given you're using Cocoon, I'm sure you
know how easy it is to provide support for these other browsers simply by
adding more stylesheets ;-)

Adam: in answer to your question, take a look at:
  src/webapp/docs/samples/formvalidation/descriptor.xml
...which gives a nice example of doing form validation using XML
descriptors. See also:
  http://xml.apache.org/cocoon/xmlform/step2-xmlform-howto.html
...for the new way of doing things.

Hope that helps,


Andrew.

-- 
Andrew SavoryEmail: [EMAIL PROTECTED]
Managing Director  Tel:  +44 (0)870 741 6658
Luminas Internet Applications  Fax:  +44 (0)700 598 1135
This is not an official statement or order.Web:www.luminas.co.uk


-
Please check that your question has not already been answered in the
FAQ before posting. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail: <[EMAIL PROTECTED]>

RE: Logging and Form Validation

[Hunsberger, Peter]

> Well... you are making a very general statement.

Yes, the original start of this conversation qualified when you don't need
to worry about JavaScript being enabled...

I don't have a problem with people requiring JavaScript; they just need to
understand the consequences;  if they are writing for the general Internet
population they should always make sure the site works both ways...


-
Please check that your question has not already been answered in the
FAQ before posting. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail: <[EMAIL PROTECTED]>

Re: Logging and Form Validation

[Robert Koberg]

Well... you are making a very general statement.

Not all implementations of forms need to be accessible to everyone. In my
case (a wysiwyg editor, cms), there is no way to do what I want to do
without JavaScript. My clients think they have gone to heaven. Also, they
happily go and download IE6 for windows if they don't already have it
(except for those dang Mac users :) [I do most of my work on an OSX box]
They don't even know what JS is half of the time. If they have JS turned off
they would not make it into the app, but be presented with a default page
saying the required browsers and that JavaScript is necessary. That being
the case, what is the problem?

-Rob

- Original Message -
From: "Hunsberger, Peter" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, June 07, 2002 1:28 PM
Subject: RE: Logging and Form Validation


> > How about
> >
> > 
>
> Guaranteed to produce lots and lots of calls to the help desk, or perhaps
> just people that don't use your site (particularly attractive for someone
> running an e-commerce site).
>
> The fact of the matter is that some of your average users have heard that
> Javascript is dangerous and opens them up to viruses, worms, etc.  As a
> result, for a web site that must work on the general Internet, it is not
> only unfriendly, but down right myopic, to require that the end user have
> JavaScript enabled.
>



-
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail: <[EMAIL PROTECTED]>

RE: Logging and Form Validation

[Hunsberger, Peter]

> wait: how many users out there are without JavaScript support ?
> Not many I think, and I have yet to find a customer of mine saying "it has
> to work on *every* browser", usually they say "IE 5.x, IE 6.x... maybe
> Netscape 6.x... possibly Opera 5" and that's it.

I've done three e-commerce sites.  The numbers vary for each site, but there
is always a trickle of users who do not have JavaScript.  I've never
bothered to check the numbers on other sites, but I'd guess the results to
be the same (many of the others don't have forms validation to worry about).

> I won't write both validations, I don't simply cater to people wihout
> Javascript... and I wonder how many developers pay attention to those
> unlucky fellows.

If you really care about your public then you pay attention to such
details

-
Please check that your question has not already been answered in the
FAQ before posting. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail: <[EMAIL PROTECTED]>

Re: Logging and Form Validation

[Adam_Waldal]

The server should be demystified for Web Developers.  If you can't handle
it stick to Photoshop and Dreamweaver!
Separation of Concerns is what Cocoon is all about right.  So HTML junkies
can be just that, they just need to learn xsl as well.

I personally think xsl is much cooler anyways.

Can anyone answer my question about those missing Classes?  I still can't
find them, and the Web Server is configured right.

-Adam


   

  Lajos Moczar 

  <[EMAIL PROTECTED]To:   [EMAIL PROTECTED]   

  m>   cc: 

       Subject:  Re: Logging and Form 
Validation   
  06/07/02 03:30 PM

  Please respond to

  cocoon-users 

   

   





web developers could always learn Cocoon ...

Vadim Gritsenko wrote:

>>From: Hunsberger, Peter [mailto:[EMAIL PROTECTED]]
>>
>>
>>>(remember, you still must have validation on the backend)
>>>
>>Precisely my original point: since you have to write the server side
>>validation anyway, do you really want to write both client and server
>>
> side
>
>>validation?
>>
>
> It is standard to have client-side validation in my current client
> company. And it makes sense most of the time - you want to keep count of
> round trips low.
>
> Otherwise, what web developers would do? ;)
>
> Vadim
>
>
>
>>I only do so if there is a real performance penalty with the
>>page validation/regeneration on the server side...
>>
>>
>
>
> -
> Please check that your question has not already been answered in the
> FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
>
> To unsubscribe, e-mail: <[EMAIL PROTECTED]>
> For additional commands, e-mail: <[EMAIL PROTECTED]>
>
>


--
Lajos

Cocoon training, consulting & support
galatea.com


-
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail: <[EMAIL PROTECTED]>







-
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail: <[EMAIL PROTECTED]>

RE: Logging and Form Validation

[Adam_Waldal]

Vadim,

Smaller round trips in my case are more important.  The XML coming in the
final Post is quite large.  I think as a best practice when a form goes
more than a page and a half and requires thorough validation on the client
javascript starts to become less desirable.  For us, catching the errors on
the front app server effectively is more important.  In fact it can be
optimized specifically to handle this and Cocoon, while the back-end app
server does Product specific processing and deals with the database.  The
back-end can also be optimized for transforming and handling distributed
transactions that hits two or more financial products.

-Adam


   
 
  "Vadim Gritsenko"
 
   
  erizon.net>   cc:
 
    Subject:  RE: Logging and Form 
Validation   
  06/07/02 03:24 PM
 
  Please respond to
 
  cocoon-users 
 
   
 
   
 




> From: Hunsberger, Peter [mailto:[EMAIL PROTECTED]]
>
> > (remember, you still must have validation on the backend)
>
> Precisely my original point: since you have to write the server side
> validation anyway, do you really want to write both client and server
side
> validation?

It is standard to have client-side validation in my current client
company. And it makes sense most of the time - you want to keep count of
round trips low.

Otherwise, what web developers would do? ;)

Vadim


> I only do so if there is a real performance penalty with the
> page validation/regeneration on the server side...
>


-
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail: <[EMAIL PROTECTED]>







-
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail: <[EMAIL PROTECTED]>

RE: Logging and Form Validation

[Hunsberger, Peter]

> How about
> 
> 

Guaranteed to produce lots and lots of calls to the help desk, or perhaps
just people that don't use your site (particularly attractive for someone
running an e-commerce site).  

The fact of the matter is that some of your average users have heard that
Javascript is dangerous and opens them up to viruses, worms, etc.  As a
result, for a web site that must work on the general Internet, it is not
only unfriendly, but down right myopic, to require that the end user have
JavaScript enabled.



-
Please check that your question has not already been answered in the
FAQ before posting. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail: <[EMAIL PROTECTED]>

Re: Logging and Form Validation

[Lajos Moczar]

web developers could always learn Cocoon ...

Vadim Gritsenko wrote:

>>From: Hunsberger, Peter [mailto:[EMAIL PROTECTED]]
>>
>>
>>>(remember, you still must have validation on the backend)
>>>
>>Precisely my original point: since you have to write the server side
>>validation anyway, do you really want to write both client and server
>>
> side
> 
>>validation? 
>>
> 
> It is standard to have client-side validation in my current client
> company. And it makes sense most of the time - you want to keep count of
> round trips low.
> 
> Otherwise, what web developers would do? ;)
> 
> Vadim
> 
> 
> 
>>I only do so if there is a real performance penalty with the
>>page validation/regeneration on the server side...
>>
>>
> 
> 
> -
> Please check that your question has not already been answered in the
> FAQ before posting. 
> 
> To unsubscribe, e-mail: <[EMAIL PROTECTED]>
> For additional commands, e-mail: <[EMAIL PROTECTED]>
> 
> 


-- 
Lajos

Cocoon training, consulting & support
galatea.com


-
Please check that your question has not already been answered in the
FAQ before posting. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail: <[EMAIL PROTECTED]>

RE: Logging and Form Validation

[Vadim Gritsenko]

> From: Hunsberger, Peter [mailto:[EMAIL PROTECTED]]
> 
> > (remember, you still must have validation on the backend)
> 
> Precisely my original point: since you have to write the server side
> validation anyway, do you really want to write both client and server
side
> validation? 

It is standard to have client-side validation in my current client
company. And it makes sense most of the time - you want to keep count of
round trips low.

Otherwise, what web developers would do? ;)

Vadim


> I only do so if there is a real performance penalty with the
> page validation/regeneration on the server side...
> 


-
Please check that your question has not already been answered in the
FAQ before posting. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail: <[EMAIL PROTECTED]>

RE: Logging and Form Validation

[Luca Morandini]

Adam,

yours is a sensible choice... however, most of form handling is, happily,
much simpler than yours.

Hence, I think there is scope for a little form handling template language
with client-side validation.

Best regards,

-
   Luca Morandini
   GIS Consultant
  [EMAIL PROTECTED]
http://utenti.tripod.it/lmorandini/index.html
-


> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Friday, June 07, 2002 10:17 PM
> To: [EMAIL PROTECTED]
> Subject: RE: Logging and Form Validation
>
>
>
> Luca,
>
> That would work for me as well, but I have multiple forms that need to be
> incrementally validated.  The application that is being replaced
> implemented client-side validation with five large forms(financial stuff)
> on six layers in one page.  The javascript was a nightmare to support.  I
> think the cleanest solution is an incremental server-side validation that
> is driven from parameters passed through an XML file.
>
> If cocoon can give me such a component, I will send a big fat stoggy to
> each member of the development team.
>
> If this works, Cocoon will become the standard for us in doing Content
> management with form validations, which is a lot!
>
> We have six large servlets with too many jsps implementing the same thing.
> I would like to shoot the consultant that advised that architecture!
>
> My Perspective.
>
> Thanks,
> Adam
>
>
>
>
>   "Luca Morandini"
>
><[EMAIL PROTECTED]>
>
>       tin.it>  cc:
>
>Subject:  RE:
> Logging and Form Validation
>   06/07/02 02:37 PM
>
>   Please respond to
>
>   cocoon-users
>
>
>
>
>
>
>
>
>
> Peter,
>
> I beg to differ. The most part of validation is a trivial matter (minimum
> lenght of fields, bounds checking, ...) and this should, in my eyes, be
> done
> on the client: max performance, min hassles for the user (errors are
> interactivaley corrected).
>
> Moreover, I haven't understood (probably my fault) how XMLForms can be
> rendered on the client with all the bells and whistles the user wants
> (styles, images, ...).
>
> Hence, I think I'll roll my own client-side form handling package, using
> the
> template language envisaged in
> http://www.xml.com/pub/a/2002/03/27/templatexslt.html by Jason Diamond.
>
> Best regards,
>
> -
>Luca Morandini
>GIS Consultant
>   [EMAIL PROTECTED]
> http://utenti.tripod.it/lmorandini/index.html
> -
>
>
> > -Original Message-
> > From: Hunsberger, Peter [mailto:[EMAIL PROTECTED]]
> > Sent: Friday, June 07, 2002 7:06 PM
> > To: '[EMAIL PROTECTED]'
> > Subject: RE: Logging and Form Validation
> >
> >
> > > This is a major
> > > sticking point for my developers that like and are
> comfortable with jsp
> > > with javascript embedded.
> > > They want to keep it at the client and I am trying to build a
> > case for the
> > > server through cocoon.
> >
> > IMNSHO, the only way you can justify client side validation is
> if you are
> > running an Intranet and you have an organization that somehow
> > restricts the
> > users capability to modify browsers settings so that you can ensure
> > JavaScript is enabled.  Otherwise, you can receive unvalidated data...
> >
> > If you're running over the Internet it's fine to use client side
> > validation
> > in addition to server side if you want to have some extra performance
> > benefits for those who have JavaScript enabled.  However, who wants to
> > maintain both?
> >
> > Even if you have an Intranet and locked down browser settings, client
> side
> > validation can be a real pain to maintain over time.  In particular,
> there
> > is (usually) no good coupling between the validation and the rest of the
> > server side code.  The exception is if you generate your client side
> > validation code from server side templates.  That's quite
> possible, but I
> > suspect that once you developers jump through the hoops of embedding
> > JavaScript within  XML ( lot's of escaping and/or CDATA) they won't
> object
> > to server side validation nearly so much...
> >
>

RE: Logging and Form Validation

[Luca Morandini]

Peter,

wait: how many users out there are without JavaScript support ?
Not many I think, and I have yet to find a customer of mine saying "it has
to work on *every* browser", usually they say "IE 5.x, IE 6.x... maybe
Netscape 6.x... possibly Opera 5" and that's it.

I won't write both validations, I don't simply cater to people wihout
Javascript... and I wonder how many developers pay attention to those
unlucky fellows.

Best regards,


-
   Luca Morandini
   GIS Consultant
  [EMAIL PROTECTED]
http://utenti.tripod.it/lmorandini/index.html
-


> -Original Message-
> From: Hunsberger, Peter [mailto:[EMAIL PROTECTED]]
> Sent: Friday, June 07, 2002 10:06 PM
> To: '[EMAIL PROTECTED]'
> Subject: RE: Logging and Form Validation
>
>
>
> > (remember, you still must have validation on the backend)
>
> Precisely my original point: since you have to write the server side
> validation anyway, do you really want to write both client and server side
> validation?  I only do so if there is a real performance penalty with the
> page validation/regeneration on the server side...
>
>
> -
> Please check that your question has not already been answered in the
> FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
>
> To unsubscribe, e-mail: <[EMAIL PROTECTED]>
> For additional commands, e-mail: <[EMAIL PROTECTED]>
>


-
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail: <[EMAIL PROTECTED]>

RE: Logging and Form Validation

[Adam_Waldal]

Luca,

That would work for me as well, but I have multiple forms that need to be
incrementally validated.  The application that is being replaced
implemented client-side validation with five large forms(financial stuff)
on six layers in one page.  The javascript was a nightmare to support.  I
think the cleanest solution is an incremental server-side validation that
is driven from parameters passed through an XML file.

If cocoon can give me such a component, I will send a big fat stoggy to
each member of the development team.

If this works, Cocoon will become the standard for us in doing Content
management with form validations, which is a lot!

We have six large servlets with too many jsps implementing the same thing.
I would like to shoot the consultant that advised that architecture!

My Perspective.

Thanks,
Adam


   

  "Luca Morandini" 

   

  tin.it>  cc: 

   Subject:  RE: Logging and Form 
Validation   
  06/07/02 02:37 PM

  Please respond to

  cocoon-users 

   

   





Peter,

I beg to differ. The most part of validation is a trivial matter (minimum
lenght of fields, bounds checking, ...) and this should, in my eyes, be
done
on the client: max performance, min hassles for the user (errors are
interactivaley corrected).

Moreover, I haven't understood (probably my fault) how XMLForms can be
rendered on the client with all the bells and whistles the user wants
(styles, images, ...).

Hence, I think I'll roll my own client-side form handling package, using
the
template language envisaged in
http://www.xml.com/pub/a/2002/03/27/templatexslt.html by Jason Diamond.

Best regards,

-
   Luca Morandini
   GIS Consultant
  [EMAIL PROTECTED]
http://utenti.tripod.it/lmorandini/index.html
-


> -Original Message-
> From: Hunsberger, Peter [mailto:[EMAIL PROTECTED]]
> Sent: Friday, June 07, 2002 7:06 PM
> To: '[EMAIL PROTECTED]'
> Subject: RE: Logging and Form Validation
>
>
> > This is a major
> > sticking point for my developers that like and are comfortable with jsp
> > with javascript embedded.
> > They want to keep it at the client and I am trying to build a
> case for the
> > server through cocoon.
>
> IMNSHO, the only way you can justify client side validation is if you are
> running an Intranet and you have an organization that somehow
> restricts the
> users capability to modify browsers settings so that you can ensure
> JavaScript is enabled.  Otherwise, you can receive unvalidated data...
>
> If you're running over the Internet it's fine to use client side
> validation
> in addition to server side if you want to have some extra performance
> benefits for those who have JavaScript enabled.  However, who wants to
> maintain both?
>
> Even if you have an Intranet and locked down browser settings, client
side
> validation can be a real pain to maintain over time.  In particular,
there
> is (usually) no good coupling between the validation and the rest of the
> server side code.  The exception is if you generate your client side
> validation code from server side templates.  That's quite possible, but I
> suspect that once you developers jump through the hoops of embedding
> JavaScript within  XML ( lot's of escaping and/or CDATA) they won't
object
> to server side validation nearly so much...
>
>
> -
> Please check that your question has not already been answered in the
> FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
>
> To unsubscribe, e-mail: <[EMAIL PROTECTE

Re: Logging and Form Validation

[Robert Koberg]

How about:



-Rob

- Original Message -
From: "Hunsberger, Peter" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, June 07, 2002 12:58 PM
Subject: RE: Logging and Form Validation


> > I beg to differ. The most part of validation is a trivial matter
(minimum
> > lenght of fields, bounds checking, ...) and this should, in my eyes, be
> done
> > on the client: max performance, min hassles for the user (errors are
> > interactivaley corrected).
>
> It's not the complexity of the validation that's at issue.  The real
> question is: HOW THE HECK DO YOU ENSURE THAT THE BROWSER HAS JAVASCRIPT
AND
> HAS IT ENABLED?
>
> Excuse the shouting, but unless you address this issue nothing else
> matters...
>
>
>
> -
> Please check that your question has not already been answered in the
> FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
>
> To unsubscribe, e-mail: <[EMAIL PROTECTED]>
> For additional commands, e-mail: <[EMAIL PROTECTED]>


-
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail: <[EMAIL PROTECTED]>

RE: Logging and Form Validation

[Hunsberger, Peter]

> (remember, you still must have validation on the backend)

Precisely my original point: since you have to write the server side
validation anyway, do you really want to write both client and server side
validation?  I only do so if there is a real performance penalty with the
page validation/regeneration on the server side...


-
Please check that your question has not already been answered in the
FAQ before posting. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail: <[EMAIL PROTECTED]>

RE: Logging and Form Validation

[Vadim Gritsenko]

> From: Hunsberger, Peter [mailto:[EMAIL PROTECTED]]
> 
> > I beg to differ. The most part of validation is a trivial matter
(minimum
> > lenght of fields, bounds checking, ...) and this should, in my eyes,
be
> done
> > on the client: max performance, min hassles for the user (errors are
> > interactivaley corrected).
> 
> It's not the complexity of the validation that's at issue.  The real
> question is: HOW THE HECK DO YOU ENSURE THAT THE BROWSER HAS
JAVASCRIPT AND
> HAS IT ENABLED?

If it is not - bad for the user - he will have to go to server just to
get an error - he will get slower service.

(remember, you still must have validation on the backend)


Vadim

> 
> Excuse the shouting, but unless you address this issue nothing else
> matters...



-
Please check that your question has not already been answered in the
FAQ before posting. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail: <[EMAIL PROTECTED]>

RE: Logging and Form Validation

[Hunsberger, Peter]

> I beg to differ. The most part of validation is a trivial matter (minimum
> lenght of fields, bounds checking, ...) and this should, in my eyes, be
done
> on the client: max performance, min hassles for the user (errors are
> interactivaley corrected).

It's not the complexity of the validation that's at issue.  The real
question is: HOW THE HECK DO YOU ENSURE THAT THE BROWSER HAS JAVASCRIPT AND
HAS IT ENABLED?

Excuse the shouting, but unless you address this issue nothing else
matters...



-
Please check that your question has not already been answered in the
FAQ before posting. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail: <[EMAIL PROTECTED]>

RE: Logging and Form Validation

[Vadim Gritsenko]

> From: Luca Morandini [mailto:[EMAIL PROTECTED]]
> 
> Peter,
> 
> I beg to differ. The most part of validation is a trivial matter
(minimum
> lenght of fields, bounds checking, ...) and this should, in my eyes,
be done
   ^^
*must*

:)

Vadim

> on the client: max performance, min hassles for the user (errors are
> interactivaley corrected).
> 
> Moreover, I haven't understood (probably my fault) how XMLForms can be
> rendered on the client with all the bells and whistles the user wants
> (styles, images, ...).
> 
> Hence, I think I'll roll my own client-side form handling package,
using the
> template language envisaged in
> http://www.xml.com/pub/a/2002/03/27/templatexslt.html by Jason
Diamond.
> 
> Best regards,
> 
> -
>Luca Morandini
>GIS Consultant
>   [EMAIL PROTECTED]
> http://utenti.tripod.it/lmorandini/index.html
> -
> 
> 
> > -Original Message-
> > From: Hunsberger, Peter [mailto:[EMAIL PROTECTED]]
> > Sent: Friday, June 07, 2002 7:06 PM
> > To: '[EMAIL PROTECTED]'
> > Subject: RE: Logging and Form Validation
> >
> >
> > > This is a major
> > > sticking point for my developers that like and are comfortable
with jsp
> > > with javascript embedded.
> > > They want to keep it at the client and I am trying to build a
> > case for the
> > > server through cocoon.
> >
> > IMNSHO, the only way you can justify client side validation is if
you are
> > running an Intranet and you have an organization that somehow
> > restricts the
> > users capability to modify browsers settings so that you can ensure
> > JavaScript is enabled.  Otherwise, you can receive unvalidated
data...
> >
> > If you're running over the Internet it's fine to use client side
> > validation
> > in addition to server side if you want to have some extra
performance
> > benefits for those who have JavaScript enabled.  However, who wants
to
> > maintain both?
> >
> > Even if you have an Intranet and locked down browser settings,
client side
> > validation can be a real pain to maintain over time.  In particular,
there
> > is (usually) no good coupling between the validation and the rest of
the
> > server side code.  The exception is if you generate your client side
> > validation code from server side templates.  That's quite possible,
but I
> > suspect that once you developers jump through the hoops of embedding
> > JavaScript within  XML ( lot's of escaping and/or CDATA) they won't
object
> > to server side validation nearly so much...


-
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail: <[EMAIL PROTECTED]>

RE: Logging and Form Validation

[Luca Morandini]

Peter,

I beg to differ. The most part of validation is a trivial matter (minimum
lenght of fields, bounds checking, ...) and this should, in my eyes, be done
on the client: max performance, min hassles for the user (errors are
interactivaley corrected).

Moreover, I haven't understood (probably my fault) how XMLForms can be
rendered on the client with all the bells and whistles the user wants
(styles, images, ...).

Hence, I think I'll roll my own client-side form handling package, using the
template language envisaged in
http://www.xml.com/pub/a/2002/03/27/templatexslt.html by Jason Diamond.

Best regards,

-
   Luca Morandini
   GIS Consultant
  [EMAIL PROTECTED]
http://utenti.tripod.it/lmorandini/index.html
-


> -Original Message-
> From: Hunsberger, Peter [mailto:[EMAIL PROTECTED]]
> Sent: Friday, June 07, 2002 7:06 PM
> To: '[EMAIL PROTECTED]'
> Subject: RE: Logging and Form Validation
>
>
> > This is a major
> > sticking point for my developers that like and are comfortable with jsp
> > with javascript embedded.
> > They want to keep it at the client and I am trying to build a
> case for the
> > server through cocoon.
>
> IMNSHO, the only way you can justify client side validation is if you are
> running an Intranet and you have an organization that somehow
> restricts the
> users capability to modify browsers settings so that you can ensure
> JavaScript is enabled.  Otherwise, you can receive unvalidated data...
>
> If you're running over the Internet it's fine to use client side
> validation
> in addition to server side if you want to have some extra performance
> benefits for those who have JavaScript enabled.  However, who wants to
> maintain both?
>
> Even if you have an Intranet and locked down browser settings, client side
> validation can be a real pain to maintain over time.  In particular, there
> is (usually) no good coupling between the validation and the rest of the
> server side code.  The exception is if you generate your client side
> validation code from server side templates.  That's quite possible, but I
> suspect that once you developers jump through the hoops of embedding
> JavaScript within  XML ( lot's of escaping and/or CDATA) they won't object
> to server side validation nearly so much...
>
>
> -
> Please check that your question has not already been answered in the
> FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
>
> To unsubscribe, e-mail: <[EMAIL PROTECTED]>
> For additional commands, e-mail: <[EMAIL PROTECTED]>
>


-
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail: <[EMAIL PROTECTED]>

Re: Logging and Form Validation

[Lajos Moczar]

Sorry, read "logicsheet" instead of "action". Don't know where my mind 
has gone ...

Lajos


Lajos Moczar wrote:

> There is already an action included in Cocoon that does validation. 
> What's nice is that you define the validation parameters in a definition 
>  files and the action takes care of applying them. I suppose you might 
> need to define your own action to actually send the data where you want it.
> 
> Lajos
> 
> galatea.com
> Cocoon training, consulting & support
> 
> 
> [EMAIL PROTECTED] wrote:
> 
>> So how would I accomplish this with Cocoon.  Could I just create a
>> component for doing that validation and treat it as a self contained 
>> pipe?
>>
>> -Adam
>>
>>
>> 
>
>>   
>> "Hunsberger,
>  
>>   Peter"To:   
>> "'[EMAIL PROTECTED]'" 
>> <[EMAIL PROTECTED]>               
>> > cc: 
>
>>   stjude.org>   Subject:  RE: Logging 
>> and Form Validation   
>> 
>
>>   06/07/02 12:06 
>> PM  
>   
>>   Please respond 
>> to  
>   
>>   
>> cocoon-users
>  
>> 
>
>> 
>
>>
>>
>>
>>
>>
>>> This is a major
>>> sticking point for my developers that like and are comfortable with jsp
>>> with javascript embedded.
>>> They want to keep it at the client and I am trying to build a case for
>>>
>> the
>>
>>> server through cocoon.
>>>
>>
>> IMNSHO, the only way you can justify client side validation is if you are
>> running an Intranet and you have an organization that somehow 
>> restricts the
>> users capability to modify browsers settings so that you can ensure
>> JavaScript is enabled.  Otherwise, you can receive unvalidated data...
>>
>> If you're running over the Internet it's fine to use client side 
>> validation
>> in addition to server side if you want to have some extra performance
>> benefits for those who have JavaScript enabled.  However, who wants to
>> maintain both?
>>
>> Even if you have an Intranet and locked down browser settings, client 
>> side
>> validation can be a real pain to maintain over time.  In particular, 
>> there
>> is (usually) no good coupling between the validation and the rest of the
>> server side code.  The exception is if you generate your client side
>> validation code from server side templates.  That's quite possible, but I
>> suspect that once you developers jump through the hoops of embedding
>> JavaScript within  XML ( lot's of escaping and/or CDATA) they won't 
>> object
>> to server side validation nearly so much...
>>
>>
>> -
>> Please check that your question has not already been answered in the
>> FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
>>
>> To unsubscribe, e-mail: <[EMAIL PROTECTED]>
>> For additional commands, e-mail: <[EMAIL PROTECTED]>
>>
>>
>>
>>
>>
>>
>>
>> -
>> Please check that your question has not already been answered in the
>> FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
>>
>> To unsubscribe, e-mail: <[EMAIL PROTECTED]>
>> For additional commands, e-mail: <[EMAIL PROTECTED]>
>>
>>
> 
> 
> 
> -
> Please check that your question has not already been answered in the
> FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
> 
> To unsubscribe, e-mail: <[EMAIL PROTECTED]>
> For additional commands, e-mail: <[EMAIL PROTECTED]>
> 
> 



-
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail: <[EMAIL PROTECTED]>

Re: Logging and Form Validation

[Lajos Moczar]

There is already an action included in Cocoon that does validation. 
What's nice is that you define the validation parameters in a definition 
  files and the action takes care of applying them. I suppose you might 
need to define your own action to actually send the data where you want it.

Lajos

galatea.com
Cocoon training, consulting & support


[EMAIL PROTECTED] wrote:

> So how would I accomplish this with Cocoon.  Could I just create a
> component for doing that validation and treat it as a self contained pipe?
> 
> -Adam
> 
> 
>  
>   
>   "Hunsberger,   
>   
>   Peter"To:   
>"'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]> 
>                  
>   stjude.org>   Subject:  RE: Logging and Form 
>Validation   
>  
>   
>   06/07/02 12:06 PM  
>   
>   Please respond to  
>   
>   cocoon-users   
>   
>  
>   
>  
>   
> 
> 
> 
> 
> 
>>This is a major
>>sticking point for my developers that like and are comfortable with jsp
>>with javascript embedded.
>>They want to keep it at the client and I am trying to build a case for
>>
> the
> 
>>server through cocoon.
>>
> 
> IMNSHO, the only way you can justify client side validation is if you are
> running an Intranet and you have an organization that somehow restricts the
> users capability to modify browsers settings so that you can ensure
> JavaScript is enabled.  Otherwise, you can receive unvalidated data...
> 
> If you're running over the Internet it's fine to use client side validation
> in addition to server side if you want to have some extra performance
> benefits for those who have JavaScript enabled.  However, who wants to
> maintain both?
> 
> Even if you have an Intranet and locked down browser settings, client side
> validation can be a real pain to maintain over time.  In particular, there
> is (usually) no good coupling between the validation and the rest of the
> server side code.  The exception is if you generate your client side
> validation code from server side templates.  That's quite possible, but I
> suspect that once you developers jump through the hoops of embedding
> JavaScript within  XML ( lot's of escaping and/or CDATA) they won't object
> to server side validation nearly so much...
> 
> 
> -
> Please check that your question has not already been answered in the
> FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
> 
> To unsubscribe, e-mail: <[EMAIL PROTECTED]>
> For additional commands, e-mail: <[EMAIL PROTECTED]>
> 
> 
> 
> 
> 
> 
> 
> -
> Please check that your question has not already been answered in the
> FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
> 
> To unsubscribe, e-mail: <[EMAIL PROTECTED]>
> For additional commands, e-mail: <[EMAIL PROTECTED]>
> 
> 



-
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail: <[EMAIL PROTECTED]>

RE: Logging and Form Validation

[Hunsberger, Peter]

> So how would I accomplish this with Cocoon.  Could I just create a
> component for doing that validation and treat it as a self contained pipe?

I suspect our case won't apply to you: we drive validation out of the
database through some EJB's using XML templates that describe what
validation rules to pick up.  We also have a requirement to ensure that our
validators can work with frameworks other than Cocoon without a lot of work.

However, if you look at the validation examples that come with Cocoon you
should probably get several ideas on ways to proceed.  


-
Please check that your question has not already been answered in the
FAQ before posting. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail: <[EMAIL PROTECTED]>

RE: Logging and Form Validation

[Adam_Waldal]

So how would I accomplish this with Cocoon.  Could I just create a
component for doing that validation and treat it as a self contained pipe?

-Adam


   
 
  "Hunsberger, 
 
  Peter"To:   
"'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]> 
                 Subject:  RE: Logging and Form 
Validation   
   
 
  06/07/02 12:06 PM
 
  Please respond to
 
  cocoon-users 
 
   
 
   
 




> This is a major
> sticking point for my developers that like and are comfortable with jsp
> with javascript embedded.
> They want to keep it at the client and I am trying to build a case for
the
> server through cocoon.

IMNSHO, the only way you can justify client side validation is if you are
running an Intranet and you have an organization that somehow restricts the
users capability to modify browsers settings so that you can ensure
JavaScript is enabled.  Otherwise, you can receive unvalidated data...

If you're running over the Internet it's fine to use client side validation
in addition to server side if you want to have some extra performance
benefits for those who have JavaScript enabled.  However, who wants to
maintain both?

Even if you have an Intranet and locked down browser settings, client side
validation can be a real pain to maintain over time.  In particular, there
is (usually) no good coupling between the validation and the rest of the
server side code.  The exception is if you generate your client side
validation code from server side templates.  That's quite possible, but I
suspect that once you developers jump through the hoops of embedding
JavaScript within  XML ( lot's of escaping and/or CDATA) they won't object
to server side validation nearly so much...


-
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail: <[EMAIL PROTECTED]>







-
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail: <[EMAIL PROTECTED]>

RE: Logging and Form Validation

[Hunsberger, Peter]

> This is a major
> sticking point for my developers that like and are comfortable with jsp
> with javascript embedded.
> They want to keep it at the client and I am trying to build a case for the
> server through cocoon.

IMNSHO, the only way you can justify client side validation is if you are
running an Intranet and you have an organization that somehow restricts the
users capability to modify browsers settings so that you can ensure
JavaScript is enabled.  Otherwise, you can receive unvalidated data...  

If you're running over the Internet it's fine to use client side validation
in addition to server side if you want to have some extra performance
benefits for those who have JavaScript enabled.  However, who wants to
maintain both?  

Even if you have an Intranet and locked down browser settings, client side
validation can be a real pain to maintain over time.  In particular, there
is (usually) no good coupling between the validation and the rest of the
server side code.  The exception is if you generate your client side
validation code from server side templates.  That's quite possible, but I
suspect that once you developers jump through the hoops of embedding
JavaScript within  XML ( lot's of escaping and/or CDATA) they won't object
to server side validation nearly so much...


-
Please check that your question has not already been answered in the
FAQ before posting. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail: <[EMAIL PROTECTED]>