myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam Winer" <awi...@gmail.com>
Subject Re: [Trinidad] Components provided by issues 663 and 664 - overview and chance to vote
Date Thu, 06 Sep 2007 23:45:54 GMT
On 9/5/07, Andrew Robinson <andrew.rw.robinson@gmail.com> wrote:
>
> > That's not a concrete example.  What UI functionality are you
> > trying to achieve that you cannot achieve today?
>
> Example for using immediate = true for a partial trigger (also shows
> usage of the partialRendered component)
>
> <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.


> > > > 664: ...
>
> I am using the alwaysRendered="true" like this:
>
> <h:panelGroup id="messagesPane">
>   <tr:partialRendered alwaysRendered="true" />
>   <ts:roundedDiv
>     id="messagesTableContainer"
>     borderWidth="0"
>     radius="5"
>     borderColor="#{roundedCornerColorLight}"
>     rendered="#{cf:hasGlobalMessages()}"
>     color="#{roundedCornerColorLight}"
>     layout="table">
>     <tr:panelPopup triggerType="hover">
>       <f:facet name="trigger">
>         <tr:outputText value="#{messages.messages_present}"
>           styleClass="messagesTitle
> messagesLevel#{facesContext.maximumSeverity}" />
>       </f:facet>
>       <tr:panelBox
>         id="messagesBox"
>         background="light">
>         <tr:panelHeader
>           text="#{messages.messages_title}" />
>         <t:messages
>           styleClass="messages"
>           globalOnly="true"
>           infoClass="messagesLevelInfo"
>           warnClass="messagesLevelWarn"
>           errorClass="messagesLevelError"
>           fatalClass="messagesLevelFatal"
>           layout="list" />
>       </tr:panelBox>
>     </tr:panelPopup>
>   </ts:roundedDiv>
> </h:panelGroup>
>
> Since my messages component is actually inside of a popup dialog, I
> need it to be always rendered, since only re-rendering just the
> messages component is not enough.
>
> Also, I am using the Tomahawk messages component as it has more
> rendering flexibility than the Trinidad one (I already submitted a
> wish JIRA to get similar capabilities for style classes on each
> message).

Without the alwaysRendered="true", I would have to hard code a
> component or phase listener to do this programmatically, but it was
> much easier to user a re-usable component that can do this for me.


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.

>
> > Could you move the code for these two components over
> > to a branch and out of trunk?
>
> If you still don't see the need after this email sure. If so, should
> it be a generic 1.0.3 sandbox for everyone, or should the branch be
> more personal. Example SVN URL would be helpful, to make sure I don't
> clutter up SVN in a way that isn't viewed as the most appropriate.


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

-- Adam

Mime
View raw message