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 > >> > >> >