So, the patch can be applied to 1.5.8 and will replace
label.add(levelModifier);
with
label.add(new AttributeAppender("class", replacementModel))You may want to add AttributeAppender to <li> as well. Alec On Wed, Oct 31, 2012 at 4:33 PM, Alec Swan <alecs...@gmail.com> wrote: > I suggest that instead of overriding CSS class on the <span> you > APPEND it to existing CSS classes. This will allow the user to specify > their own <span> CSS class in newMessageDisplayComponent(..) AND will > support backward compatibility. > > Sounds like a win-win to me. Thoughts? > > Thanks, > > Alec > > On Wed, Oct 31, 2012 at 1:17 AM, Sven Meier <s...@meiers.net> wrote: >> Hi, >> >> the CSS class could be changed in Wicket 7 only. Until you've migrated you >> can easily just use your own feedback component. >> >> Best regards >> Sven >> >> >> On 10/30/2012 11:24 PM, Sebastien wrote: >>> >>> Hi, >>> >>> I also agree with Martin's points. Having no css-class on the span is the >>> best solution from my point of view too. >>> A little concern however. I think this kind of change is not exactly >>> "backward compatible". Sure, it is, for the java side, but I figure that >>> *many* users have wrote their own CSS for feedback panels and this will >>> probably results to bad display with this change. So, I am wondering if >>> this change will be considered as an "API break"? If yes, will you apply >>> it >>> also to 1.5.x (the original demand)? And, if the new version numbering >>> system in place applies to 1.5.x, does that means that it should be 1.6.0? >>> You see what I mean... it could lead to some misunderstanding!.. >>> >>> Also I like Sven's suggestion, but I am afraid that it will overlap with >>> #newMessageDisplayComponent(). As ListItem IS-A WebMarkupContainer, we >>> could do any customization from here. But, in this case (there is a new >>> #newMessageItem() method), the span element is not needed anymore and >>> therefore #newMessageDisplayComponent() neither. So, about the API break, >>> we are in situation :) >>> >>> Thanks & best regards, >>> Sebastien. >>> >>> >>> On Mon, Oct 29, 2012 at 6:18 PM, Joachim Schrod <jsch...@acm.org> wrote: >>> >>>> Hi, >>>> >>>> This would change be very well received, from my side. :-) :-) >>>> >>>> Cheers, >>>> Joachim >>>> >>>> >>>> Martin Grigorov wrote: >>>>> >>>>> Hi, >>>>> >>>>> [X] Other suggestion: (please specify) >>>>> >>>>> Here is what I think it should be: >>>>> - <div> element should have class "feedbackPanel" (this is already the >>>> >>>> case) >>>>> >>>>> - <li> element(s) should have class that specifies the feedback >>>>> message level (currently by default Wicket sets "feedbackPanelLEVEL", >>>>> but this is configurable with >>>>> >>>> >>>> org.apache.wicket.markup.html.panel.FeedbackPanel#getCSSClass(FeedbackMessage)) >>>>> >>>>> - the <span> should not have class at all (currently it has the same >>>>> class as the <li> element) >>>>> - the styling should be done with CSS selectors (e.g. >>>>> div.feedbackPanel; div.feedbackPanel li.alert-warn; div.feedbackPanel >>>>> li.alert-warn span; ...) >>>>> - if custom markup is needed then a custom FeedbackPanel is needed >>>>> (one that extends from the default FeedbackPanel or a completely new >>>>> one, it depends on the use case) >>>>> >>>>> >>>>> On Sun, Oct 28, 2012 at 6:03 PM, Sebastien <seb...@gmail.com> wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> To sum-up this thread: we have a (not huge, but still) design issue >>>>>> that >>>>>> annoys several users. A patch* has been provided but some questions >>>>>> remains... >>>>>> Given this, I would suggest a kind-of vote about the several points >>>>>> discussed earlier, in order to enlighten the dev-team about the >>>> >>>> preferred >>>>>> >>>>>> choice of their (beloved) users.** >>>>>> >>>>>> Here are some possible options: >>>>>> [ ] Please apply the patch as-is. It currently provides 2 methods >>>>>> (#getListCSSClass and #getLabelCSSClass), #getCSSClass is marked a >>>>>> deprecated until marked as private (or removed) >>>>>> [ ] Do not apply the patch as-is, #getCSSClass should be kept (not >>>> >>>> marked >>>>>> >>>>>> as deprecated) >>>>>> [ ] Do not apply the patch as-is, I do not agree with the 2 method >>>> >>>> names. I >>>>>> >>>>>> would have preferred: (please specify) >>>>>> [ ] This is not an issue; this does not need to be "corrected" >>>>>> [ ] Other suggestion: (please specify) >>>>>> >>>>>> Thanks in advance for your contribution, >>>>>> Sebastien >>>>>> >>>>>> (*) https://issues.apache.org/jira/browse/WICKET-4831 >>>>>> (**) Sure, dev-team opinion is also kindly asked! :) >>>>> >>>>> >>>>> >>>> >>>> >>>> Joachim >>>> >>>> -- >>>> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >>>> Joachim Schrod, Roedermark, Germany >>>> Email: jsch...@acm.org >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >>>> For additional commands, e-mail: users-h...@wicket.apache.org >>>> >>>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
