I've now migrated the MessageBoxRenderer, but I have a few questions
remaining:
The old implementation defers the rendering of the header, and used a
_RESOURCE_KEY_MAP to map messages skin selectors to panelHeader skin
selectors as below:
_RESOURCE_KEY_MAP.put("af_panelHeader.INFORMATION",
"af_messages.INFORMATION");
The updated implementation uses "private class HeaderRenderer extends
PanelHeaderRenderer" to delegate the header rendering to panelHeader.
However, there doesn't seem a standard mechansim to influence styles in the
way it was previously used. The only simple way seems to be to modify
"private String PanelHeaderRenderer._getMessageIconName()" to allow the
superclass to override the method and substitute its icons.
I'm also hesitant to migrate the existing skin selectors for
af|messages::top-start-icon etc., which allow the component to have rounded
corners etc. It would seem better to have a generic Renderer that we could
delegate to for this similar to the roundedDiv component. Until we have
this, it would mean the af|messages::top-start-icon etc. styles would be
removed.
Danny
On 7/10/07, Adam Winer <[EMAIL PROTECTED]> wrote:
On 7/10/07, Danny Robinson <[EMAIL PROTECTED]> wrote:
> I'm currently moving the tr:messages code from the old 'laf' package
into
>
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.MessageBoxRenderer
> (extends XhtmlRenderer) unless someone tells me otherwise.
Sounds great!
> Once working, we can factor this into the inline validation so messages
are
> also posted there. If simple="true" and tr:messages doesn't exist, I
> propose we then pop an alert.
+1
-- Adam
>
> Danny
>
> Any thoughts on how we'd like the MessageBoxRenderer to handle other
>
>
> On 7/10/07, Adam Winer < [EMAIL PROTECTED]> wrote:
> > Now http://issues.apache.org/jira/browse/TRINIDAD-94
> >
> > Thanks, Adam
> >
> >
> > On 7/9/07, noah <[EMAIL PROTECTED] > wrote:
> > > On 7/6/07, Adam Winer <[EMAIL PROTECTED] > wrote:
> > > > If you remove simple="true" from the inputText, what happens?
> > > > Or, if you set an "id" on the tr:inputText and add a tr:message
> > > > component, what happens?
> > >
> > > Removing it and clicking the link prints a nice message next to the
> > > form field. Also, adding
> > > <tr:message for="foo" />
> > > and setting the input's id to foo gives the same effect. So I think
> > > you're right, it silently chokes if there isn't anywhere to show the
> > > message.
> > >
> > > > simple="true" means
> > > > there's no implict message component in the content.
> > > >
> > > > My suspicion is that the client-side validation is trying
> > > > to show the error message inline, failing to find anywhere
> > > > to write the message, and just swallowing it. We
> > > > could either:
> > > > 1. show these messages as JS alerts
> > > > 2. show these messages in some other block of content,
> > > > picked perhaps arbitrarily (in tr:messages by default,
> > > > otherwise at the head of the page?)
> > > > 3. blow off client-side validation altogether for those elements
> > > >
> > > > -- Adam
> > > >
> > > >
> > > >
> > > > On 7/6/07, noah < [EMAIL PROTECTED]> wrote:
> > > > > I'm getting weird client side behavior with the tr:inputs. It
seems
> > > > > to be connected to validation. The example below just has one
> required
> > > > > field, but I get the same behavior on larger forms when other
> > > > > validation rules are not satisfied.
> > > > >
> > > > > <tr:document xmlns=" http://www.w3.org/1999/xhtml";
> > > > > xmlns:ui=" http://java.sun.com/jsf/facelets";
> > > > > xmlns:f=" http://java.sun.com/jsf/core";
> > > > > xmlns:h=" http://java.sun.com/jsf/html";
> > > > > xmlns:tr=" http://myfaces.apache.org/trinidad";>
> > > > > <tr:form>
> > > > > <tr:messages />
> > > > >
> > > > > <h:outputText value="Foo=#{pageFlowScope.foo }" />
> > > > > <tr:inputText required="true" simple="true"
> > > > > value="#{pageFlowScope.bar}" />
> > > > > <tr:commandLink text="foo">
> > > > > <f:setPropertyActionListener
> target="#{pageFlowScope.foo}"
> > > > > value="bar" />
> > > > > </tr:commandLink>
> > > > > </tr:form>
> > > > > </tr:document>
> > > > >
> > > > > Anyhow, if the input field is blank clicking the link does
nothing.
> No
> > > > > messages, nothing. If I switch to an h:inputText, the form
submits
> > > > > and I get a message. Do I need to do something special to get
> > > > > messages from the client side validation that appears to be
going
> on?
> > > > >
> > > >
> > >
> >
>
>
>
> --
> Chordiant Software Inc.
> www.chordiant.com
--
Chordiant Software Inc.
www.chordiant.com
