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
