+1 for deprecating forceSpan and adding generic renderedIfEmpty. On Wed, Mar 26, 2008 at 1:34 AM, Ernst Fastl <[EMAIL PROTECTED]> wrote:
> that would be another advantage of the simple default behavior to > render whatever (ul, table, span, ...) the component usually > renders also if there are no messages wouldn't it? > > On Tue, Mar 25, 2008 at 11:51 PM, Andrew Robinson > <[EMAIL PROTECTED]> wrote: > > I would not recommend forceSpan as an attribute as the use of a span > > is renderer specific, not component specific. The component should not > > care how the renderer works > > > > > > > > On Tue, Mar 25, 2008 at 4:41 PM, Ernst Fastl <[EMAIL PROTECTED]> > wrote: > > > Hi, > > > > > > I like the idea of making that the default behavior. I think for > > > t:messages it should be save to do > > > so. As for h:messages I'm not sure how detailed the spec is there. > > > I'll better check that before > > > touching h:messages. I also don't know what mojarra does, but I > would > > > guess that they do > > > the same thing as we do at the moment. > > > > > > forceSpan would also work for me I guess. But if there it is ok to > > > ajust the default behavior > > > of t:messages I'd prefer that solution because its one parameter > less > > > the user needs to > > > know and think about. > > > > > > thanks for your ideas guys > > > > > > Ernst > > > > > > > > > > > > On Tue, Mar 25, 2008 at 10:27 PM, Cagatay Civici > > > <[EMAIL PROTECTED]> wrote: > > > > Hi, > > > > > > > > For t:message and t:messages, there's already a forceSpan > attribute, will it > > > > work for you Ernst? > > > > > > > > Cagatay > > > > > > > > > > > > > > > > On Tue, Mar 25, 2008 at 11:17 PM, simon <[EMAIL PROTECTED]> > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Tue, 2008-03-25 at 21:45 +0100, simon wrote: > > > > > > On Tue, 2008-03-25 at 20:50 +0100, Ernst Fastl wrote: > > > > > > > Hi, > > > > > > > > > > > > > > I would like to add renderedIfEmpty to the t:messages > component which > > > > > > > per default is false (current behaviour) > > > > > > > The reason for that: To update/append FacesMessages to a > > > > > > > messages-component after AJAX requests (e.g. PPR) > > > > > > > it has to be possible to locate a DOM element to which this > messages > > > > > > > can be appended. > > > > > > > > > > > > > > One could also think of automatically adding a CSS-style > display:none > > > > > > > if the empty table/list is rendered which is > > > > > > > reset by any JavaScript updates to the messages. > > > > > > > > > > > > > > Alternatively we could create a new messages-component which > supports > > > > that. > > > > > > > > > > > > > > If anybody can think of reasons why this parameter should > not be added > > > > > > > please tell. Otherwise I'll file a JIRA issue > > > > > > > and start implementing on thursday evening. > > > > > > > > > > > > Does your second suggestion ("CSS-style display:none") mean to > always > > > > > > render the div, but when there are no messages do: > > > > > > <div id=".." style="display:none"/> > > > > > > and let javascript modify the style if messages need to be > added to it > > > > > > after a ppr request? > > > > > > > > > > > > If so, I think that is nicer. Logically, it makes sense too; > the > > > > > > h:messages has not been marked with rendered=false, it just > happens to > > > > > > have no messages. So the div should be present, but hidden. > > > > > > > > > > > > And it means that no extra attribute is needed. > > > > > > > > > > > > I cannot imagine any application that would break because of > the > > > > > > introduction of a div with display:none set. > > > > > > > > > > BTW, I was thinking about making this change in h:messages, not > just in > > > > > t:messages. > > > > > > > > > > However even if the change is done in core, the same > functionality would > > > > > still be needed in t:messages unless Sun Mojarra's h:messages > component > > > > > also renders a hidden div when empty. Any idea what Mojarra does > here? > > > > > > > > > > Regards, > > > > > Simon > > > > > > > > > > > > > > > > > > > > > > > >