@Sebastien The scenario you described it exactly the scenario I used to start this thread. Please read my original post.
So, the solution is to change Wicket code FeedbackPanel.MessageListView#populateItem to use AttributeAppender instead of AttributeModifier as I suggested in my previous message. In addition, your code should override newMessageDisplayComponent(..) as follows: protected Component newMessageDisplayComponent(String id, FeedbackMessage message) { Component label = super.newMessageDisplayComponent(id, message); label.add(new AttributeAppender("class", new Model<String>(message.isInfo() ? ".my-ui-info" : ".my-ui-error"), " ")); return label; } This will set the style you want on <span> and will leave <li> unmodified. Why doesn't it work for you? Thanks, Alec On Thu, Nov 1, 2012 at 9:55 AM, Sebastien <seb...@gmail.com> wrote: > Hi, > > @Alec, the use case is the following: > Consider you are not the "owner" of the css-class(es). The css provider (a > ui-framework, a designer, ...) will provide one style by message level > (let's say .my-ui-warn, .my-ui-error, .my-ui-info, etc). So you will > override #getCssClass in order to return the corresponding css-class > depending of the level type (supplied as method's argument). But... the > provided class/style is designed to be applied *only* to one element. So, > if the css-class is applied onto both LI and SPAN, there will be a style > overlap which will result to a bad display... As the > message-level-css-class is *always* appended to both elements, there is yet > no other choice (I think) to have our own FeedbackPanel or extending the > existing one with the "hack" I provided earlier... > > @Sven: Thanks for your suggestion! It would result to a different component > but it is certainly more relevant... > > Best regards, > Sebastien. > > > On Thu, Nov 1, 2012 at 4:17 PM, Sven Meier <s...@meiers.net> wrote: > >> If you want to group messages you can easily use multiple feedback panels, >> each filtering by severity. >> >> Sven >> >> Sebastien <seb...@gmail.com> schrieb: >> >> >Hi, >> > >> >@Alec, unfortunately I think your workaround does not handle the case we >> do >> >*not* want the message-level-css-class on the SPAN, and that we still want >> >it on the LI... >> > >> >@Sven, well if the refactoring is planned for Wicket 7 (a question will >> >remain about doing something, backward compatible, for current versions), >> >then it changes things... >> >Then, I would maybe have a request about this refactored FeedbackPanel: I >> >would like to be able to have/display messages grouped by levels (so each >> >level is enclosed in its own container). That would simply mean that the >> UL >> >will becomes a repeater. For instance, if this 'grouping option' is not >> >activated, the repeater will iterate only once, with all feedback message >> >of any level type. If it is activated, the repeater will iterate as many >> >times as there is distinct message level types. And, last but not least, >> we >> >should be able to apply the message-level-css-class to this repeater (and >> >be able to *not* apply it to LI nor SPAN... so the loop is looped*). >> > >> >If you, dev-team, think this request is not relevant for wicket-core, >> >please keep in mind this need while refactoring so you may provide the >> >necessary/accessible things for the user wishing to *override* >> >FeedbackPanel to achieve this goal... >> > >> >Thanks in advance & best regards, >> >Sebastien >> > >> >(*) hazardous translation from French... >> > >> > >> >On Wed, Oct 31, 2012 at 11:37 PM, Alec Swan <alecs...@gmail.com> wrote: >> > >> >> 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 >> >> >> >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org