Hi Alec,
If Sven or Martin agree with this solution for 1.5.9 & 6.3.0, I can attach
the patch(es) to the opened ticket if needed. (but to replace a word by
another, I am not sure my support will help that much! :) )
I also think that we can keep this AttributeAppender even with the changes
to be done for wicket7 (with the Martin's suggestion for instance). At
least I do not see yet any potential issue / unexpected behavior that can
happens, and we keep the advantage it provides...
Best regards,
Sebastien.
On Fri, Nov 2, 2012 at 4:21 PM, Alec Swan <alecs...@gmail.com> wrote:
> Sebastien, thanks for reviewing and approving the proposal. So, what
> do we need to do to make it in 1.5.9? Or did you already check it in
> there?
>
> Thanks,
>
> Alec
>
> On Thu, Nov 1, 2012 at 6:04 PM, Sebastien <seb...@gmail.com> wrote:
> > Hi Alec,
> >
> > Thanks for having taking time to write the code snippet bellow, I better
> > understand your idea!..
> > I did not realized you didn't want to use getCssClass, but I think it is
> > good solution anyway! It is easy for the user to replace
> > message.isInfo() ? ".my-ui-info" : ".my-ui-error"
> > by its custom method: getMessageCssClass(message.getLevel()) or something
> > equivalent as we spoke before, so that's fine for me. Well done!
> >
> > Thanks again & best regards,
> > Sebastien.
> >
> >
> > On Thu, Nov 1, 2012 at 11:57 PM, Alec Swan <alecs...@gmail.com> wrote:
> >
> >> @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
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
