@Sebastien, my original post in this thread would have been satisfied
with my solution which appends the CSS class instead of replacing it.
And this solution is backward compatible.
If there is a different scenario which required *not* having a
message-level-css-class, maybe we should start a separate email thread
for it. BTW, in case I missed it in this email thread what is that
scenario?
Thanks,
Alec
On Thu, Nov 1, 2012 at 8:38 AM, Sebastien <seb...@gmail.com> wrote:
> 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
