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