On 9/7/07, Andrew Robinson <[EMAIL PROTECTED]> wrote:
> > > <seam:decorate id="decorateUsername">
> > > <tr:inputText id="username" required="true" styleClass="#{invalid ?
> > > 'error' : ''}"
> > > value="#{ user.username}">
> > > <seam:validate />
> > > </tr:inputText>
> > > </seam:decorate>
> > > <tr:partialRendered for="decorateUsername" partialTriggers="saveTrigger"
> > />
> > > <tr:partialTrigger id="saveTrigger" immediate="true">
> > > <tr:commandLink partialSubmit="true" text="Save" />
> > > </tr:partialTrigger>
> > >
> > > The seam:decorate needs to re-render on the validation error to ensure
> > > that the text box is now rendered with the "error" CSS style class.
> > > Simply supporting updating client-side messages only would not work
> > > here.
> >
> > This isn't a great example, because you wouldn't get that styling
> > with client-side validation (which, I know you've turned off,
> > but that is a minority view). The appropriate way to tackle
> > that requirement is to support full CSS styling of error components
> > (which, is in fact exactly what the Oracle rich client code does)
> > beyond just attaching messages and error icons.
>
> I have been thinking more about this, and the more I do, the more your
> response really bothers me. Your are justifying denying functionality
> from users because of client-side validation not supporting it.
> Client-side validation is a very limiting technology, bounded by
> having to write and maintain JavaScript, and the industry has
> definitely not shown that it should be the mainstream for internet
> applications. Look at how very few sites on the internet use it, and
> you will see that. If this was the way to go, GWT would be a much
> better solution than JSF, with the argument that if you are going to
> push validation to the client, you may as well push rendering to the
> client.
I'm not saying client-side validation is the one true way to go,.
I'm saying that DHTML that can *insert messages on the client-side*
is the right way to go. We happen to have implemented exactly this
technology as part of our client-side validation layer, but there is
no necessary requirement at all that the validation actually happen
on the client-side in order for that code to function. (Today,
we don't render the placeholders for the messages unless client-side
validation is enabled, but that's 5 minutes of work to change.)
IMO, I think it's lame that so many server-side tools are failing
to grasp the value in generating client-side validation off of
server-side validation metadata. User responsiveness is a huge
gain for web applications.
-- Adam
>
> For most users of JBoss-Seam, client-side validation will probably not
> be used (I am one user who proves this to be a valid use case). I
> don't feel that just Trinidad supports some client-side validation
> that users should be limited to its functionality if they decide not
> to use it.
>
> With that said, my example is a perfect one and very valid. It just
> isn't applicable to the entire user base. But that has never been a
> good reason in a programming platform for not supporting it. I could
> go on and on about features in programming languages that many users
> will never use, but that is never a good reason that they shouldn't be
> provided.
>
> My use case is also very valid in a PDA or non-JavaScript environment.
> My solution would work in both a desktop-AJAX environment and would
> degrade with the same level of functionality in a PDA/non-JavaScript
> environment. People supporting PDA sites really don't care what
> javascript validation is available.
>
> -Andrew
>
