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"
>
>                       <luca.morandini1@        To:
> <[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...
> >
> >
> > ---------------------------------------------------------------------
> > 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]>

Reply via email to