> 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.
Just as long as it supports server-side errors, it may be enough. Although, it will not work with any 3rd party components, will it? If so, users would be required to use only Trinidad components and I doubt if that is a good requirement/restriction. CSS styling of error components may not always be enough, for example the label component may also need to be styled. Programmers may also want the ability to scroll the page and put focus into the first invalid component. Getting away from the standard component->renderer->HTML approach seems a bit risky to me. If you are to have this custom solution, you will need to make sure that other components, that are not the ones that have errors can also make rendering changes (like the label component for example). I still don't like the idea the Trinidad will not let you have the ability to trigger the partial-update immediately based on a form submittal from a component. I have never thought it to be a good idea for re-usable UI components to force programmers to code a certain way and not leave room for flexibility of less than standard use cases. I guess that is where custom components or code must be written? As for client side validation, it will never cover all validations, and it cannot perform conversion (at least not Java Object conversion, it can do very simplistic conversions like numbers), so it is never a 100% catch-all for validation errors and conversion errors. So even with client side validation enabled, some validation and conversion errors may occur on the server (like database unique violations, database optimistic locking concurrency check errors for 2 examples). ..... > I don't buy this as a sufficiently strong reason to add alwaysRendered, > given how I think that it will break when we functionality that I consider > absolutely critical for addition in JSF 1.2 - we have to stop requiring > decode() > and encodeXYZ() be called on every component on every AJAX request. Understood. How will component developers be able to guarantee that their components are called with those changes? Would they register for some kind of callback in the encode phase to be notified when the view is decoded and then use invokeOnComponent to be called? For example, how would someone go about doing what I did in your mind (updating a global message component that isn't a Trinidad component or at least is more than just the tr:messages that has to be updated)? > A sandbox would be great, but we don't have one set up. > > A branch would go somewhere like: > > http://svn.apache.org/repos/asf/myfaces/trinidad/branches/arobinson-ppr-components I'll move them soon. Without a separate jar (sandbox) the code will be unusable except for code reviews unfortunately. For a sandbox idea, were you thinking of a different JAR, or including them in the current folders in different packages (org.apache.myfaces.trinidad.sandbox...) and a different namespace (trs prefix or something)? -Andrew
