@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
