I'll take care.
On Fri, Nov 2, 2012 at 5:59 PM, Sebastien <seb...@gmail.com> wrote:
> 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
>>
>>
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
