> > <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.
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
