Re: Custom CSS for Feedback message is broken in 1.5
Hi Alec, Please use the mailing lists. Don't write private messages. On Wed, Nov 7, 2012 at 8:02 PM, Alec Swan wrote: > I verified that the change is in master branch, but not in > wicket-1.5.x branch. What is wicket-1.5.x branch used for? > martin@martin-laptop:~/git/apache/wicket-1.5.x(wicket-1.5.x=)$ git log --grep=WICKET-4831 commit d7e019152df0756d307d8136dd94fcdb819823a6 Author: svenmeier Date: Fri Nov 2 21:31:46 2012 +0100 WICKET-4831 removed class attribute from markup commit afec3a61ccd63e833586be33867eb873a721a941 Author: Martin Tzvetanov Grigorov Date: Fri Nov 2 19:01:09 2012 +0200 WICKET-4831 Append the feedback message CSS class instead of overriding it > > On Tue, Nov 6, 2012 at 11:44 PM, Martin Grigorov > wrote: > > The ticket says that the improvement is in 1.5.9, no ? > > > > > > On Wed, Nov 7, 2012 at 1:45 AM, Alec Swan wrote: > >> > >> Martin, could you please merge your changes to 1.5.9 branch? > >> > >> Thanks, > >> > >> Alec > >> > >> > >> ------ Forwarded message ---------- > >> From: Alec Swan > >> Date: Fri, Nov 2, 2012 at 1:48 PM > >> Subject: Re: Custom CSS for Feedback message is broken in 1.5 > >> To: users@wicket.apache.org > >> > >> > >> I don't see 1.5.9 branch either and I don't see the changes in 1.5.x > >> branch. Martin, where did you check your changes in? > >> > >> Thanks, > >> > >> Alec > >> > >> On Fri, Nov 2, 2012 at 12:56 PM, Sebastien wrote: > >> > Hi Martin, > >> > > >> > Tested & approved! Works like a charm... > >> > > >> > I tested upon master branch (6.3.0-SNAPSHOT), because I do not see > were > >> > wicket-1.5.9 branch is... But I guess it behaves exactly the same. > >> > Just a little note; on the version I pulled I still have > >> > class="errorlevel" > >> > in the associated markup (Sven's added a comment in the ticket about > >> > this, > >> > I don't know if you had it)... > >> > > >> > Thanks again & best regards, > >> > Sebastien. > >> > > >> > On Fri, Nov 2, 2012 at 6:08 PM, Martin Grigorov > >> > wrote: > >> > > >> >> Done! > >> >> > >> >> Please confirm that this is enough for now. > >> >> > >> >> On Fri, Nov 2, 2012 at 7:01 PM, Sebastien wrote: > >> >> > Great! Thanks Martin! > >> >> > > >> >> > On Fri, Nov 2, 2012 at 5:01 PM, Martin Grigorov < > mgrigo...@apache.org > >> >> >wrote: > >> >> > > >> >> >> I'll take care. > >> >> >> > >> >> >> On Fri, Nov 2, 2012 at 5:59 PM, Sebastien > 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 > >> >> >> > 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 > >> >> >> >>
Re: Custom CSS for Feedback message is broken in 1.5
Is anybody merging this in 1.5.9? On Fri, Nov 2, 2012 at 11:37 PM, miteshaegis wrote: > Hi, > > You can use set of class and set css on div class easily. > > Thanks! > > > > - > JBoss Developers || JBPM Workflow > -- > View this message in context: > http://apache-wicket.1842946.n4.nabble.com/Custom-CSS-for-Feedback-message-is-broken-in-1-5-tp4653166p4653593.html > Sent from the Users forum mailing list archive at Nabble.com. > > - > 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
Re: Custom CSS for Feedback message is broken in 1.5
Hi, You can use set of class and set css on div class easily. Thanks! - JBoss Developers || JBPM Workflow -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Custom-CSS-for-Feedback-message-is-broken-in-1-5-tp4653166p4653593.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Custom CSS for Feedback message is broken in 1.5
I've removed the class attribute from markup. The changes are on master and wicket-1.5.x branch. Sven On 11/02/2012 08:48 PM, Alec Swan wrote: I don't see 1.5.9 branch either and I don't see the changes in 1.5.x branch. Martin, where did you check your changes in? Thanks, Alec On Fri, Nov 2, 2012 at 12:56 PM, Sebastien wrote: Hi Martin, Tested & approved! Works like a charm... I tested upon master branch (6.3.0-SNAPSHOT), because I do not see were wicket-1.5.9 branch is... But I guess it behaves exactly the same. Just a little note; on the version I pulled I still have class="errorlevel" in the associated markup (Sven's added a comment in the ticket about this, I don't know if you had it)... Thanks again & best regards, Sebastien. On Fri, Nov 2, 2012 at 6:08 PM, Martin Grigorov wrote: Done! Please confirm that this is enough for now. On Fri, Nov 2, 2012 at 7:01 PM, Sebastien wrote: Great! Thanks Martin! On Fri, Nov 2, 2012 at 5:01 PM, Martin Grigorov I'll take care. On Fri, Nov 2, 2012 at 5:59 PM, Sebastien 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 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 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. -- 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 - 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
Re: Custom CSS for Feedback message is broken in 1.5
I don't see 1.5.9 branch either and I don't see the changes in 1.5.x branch. Martin, where did you check your changes in? Thanks, Alec On Fri, Nov 2, 2012 at 12:56 PM, Sebastien wrote: > Hi Martin, > > Tested & approved! Works like a charm... > > I tested upon master branch (6.3.0-SNAPSHOT), because I do not see were > wicket-1.5.9 branch is... But I guess it behaves exactly the same. > Just a little note; on the version I pulled I still have class="errorlevel" > in the associated markup (Sven's added a comment in the ticket about this, > I don't know if you had it)... > > Thanks again & best regards, > Sebastien. > > On Fri, Nov 2, 2012 at 6:08 PM, Martin Grigorov wrote: > >> Done! >> >> Please confirm that this is enough for now. >> >> On Fri, Nov 2, 2012 at 7:01 PM, Sebastien wrote: >> > Great! Thanks Martin! >> > >> > On Fri, Nov 2, 2012 at 5:01 PM, Martin Grigorov > >wrote: >> > >> >> I'll take care. >> >> >> >> On Fri, Nov 2, 2012 at 5:59 PM, Sebastien 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 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 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. >> >> >> > >> >> >> >> >> >> -- >> 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 >> >> - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Custom CSS for Feedback message is broken in 1.5
Hi Martin, Tested & approved! Works like a charm... I tested upon master branch (6.3.0-SNAPSHOT), because I do not see were wicket-1.5.9 branch is... But I guess it behaves exactly the same. Just a little note; on the version I pulled I still have class="errorlevel" in the associated markup (Sven's added a comment in the ticket about this, I don't know if you had it)... Thanks again & best regards, Sebastien. On Fri, Nov 2, 2012 at 6:08 PM, Martin Grigorov wrote: > Done! > > Please confirm that this is enough for now. > > On Fri, Nov 2, 2012 at 7:01 PM, Sebastien wrote: > > Great! Thanks Martin! > > > > On Fri, Nov 2, 2012 at 5:01 PM, Martin Grigorov >wrote: > > > >> I'll take care. > >> > >> On Fri, Nov 2, 2012 at 5:59 PM, Sebastien 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 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 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. > >> >> > > >> > > > > -- > 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 > >
Re: Custom CSS for Feedback message is broken in 1.5
Done! Please confirm that this is enough for now. On Fri, Nov 2, 2012 at 7:01 PM, Sebastien wrote: > Great! Thanks Martin! > > On Fri, Nov 2, 2012 at 5:01 PM, Martin Grigorov wrote: > >> I'll take care. >> >> On Fri, Nov 2, 2012 at 5:59 PM, Sebastien 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 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 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. >> >> > >> -- 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
Re: Custom CSS for Feedback message is broken in 1.5
Great! Thanks Martin! On Fri, Nov 2, 2012 at 5:01 PM, Martin Grigorov wrote: > I'll take care. > > On Fri, Nov 2, 2012 at 5:59 PM, Sebastien 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 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 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. > >> > >
Re: Custom CSS for Feedback message is broken in 1.5
I'll take care.
On Fri, Nov 2, 2012 at 5:59 PM, Sebastien 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 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 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 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(message.isInfo() ? ".my-ui-info" : ".my-ui-error"), "
>> >> "));
>> >> return label;
>> >> }
>> >>
>> >> This will set the style you want on and will leave
>> unmodified.
>> >>
>> >> Why doesn't it work for you?
>> >>
>> >> Thanks,
>> >>
>> >> Alec
>> >>
>> >> On Thu, Nov 1, 2012 at 9:55 AM, Sebastien 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 wrote:
>> >> >
>> >> >> If you want to group messages you can easily use multiple feedback
>> >> panels,
>> >> >> each filtering by severity.
>> >> >>
>> >> >> Sven
>> >> >>
>> >> >> Sebastien 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,
>> >>
Re: Custom CSS for Feedback message is broken in 1.5
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 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 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 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(message.isInfo() ? ".my-ui-info" : ".my-ui-error"), "
> >> "));
> >> return label;
> >> }
> >>
> >> This will set the style you want on and will leave
> unmodified.
> >>
> >> Why doesn't it work for you?
> >>
> >> Thanks,
> >>
> >> Alec
> >>
> >> On Thu, Nov 1, 2012 at 9:55 AM, Sebastien 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 wrote:
> >> >
> >> >> If you want to group messages you can easily use multiple feedback
> >> panels,
> >> >> each filtering by severity.
> >> >>
> >> >> Sven
> >> >>
> >> >> Sebastien 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
Re: Custom CSS for Feedback message is broken in 1.5
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 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 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(message.isInfo() ? ".my-ui-info" : ".my-ui-error"), "
>> "));
>> return label;
>> }
>>
>> This will set the style you want on and will leave unmodified.
>>
>> Why doesn't it work for you?
>>
>> Thanks,
>>
>> Alec
>>
>> On Thu, Nov 1, 2012 at 9:55 AM, Sebastien 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 wrote:
>> >
>> >> If you want to group messages you can easily use multiple feedback
>> panels,
>> >> each filtering by severity.
>> >>
>> >> Sven
>> >>
>> >> Sebastien 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
>> 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 as well.
>> >> >>
>> >> >> Alec
>> >> >>
>> >> >> On Wed, Oct 31, 2012 at 4:33 PM, Alec Swan
>> wrote:
>> >> >> > I suggest that instead of
Re: Custom CSS for Feedback message is broken in 1.5
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 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(message.isInfo() ? ".my-ui-info" : ".my-ui-error"), "
> "));
> return label;
> }
>
> This will set the style you want on and will leave unmodified.
>
> Why doesn't it work for you?
>
> Thanks,
>
> Alec
>
> On Thu, Nov 1, 2012 at 9:55 AM, Sebastien 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 wrote:
> >
> >> If you want to group messages you can easily use multiple feedback
> panels,
> >> each filtering by severity.
> >>
> >> Sven
> >>
> >> Sebastien 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
> 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 as well.
> >> >>
> >> >> Alec
> >> >>
> >> >> On Wed, Oct 31, 2012 at 4:33 PM, Alec Swan
> wrote:
> >> >> > I suggest that instead of overriding CSS class on the you
> >> >> > APPEND it to existing CSS classes. This will allow the user to
> specify
> >> >> > their own CSS class in newMessageDisplayComponent(..) AND
> will
> >> >> > support backward compatibility.
> >> >> >
> >> >> > Sounds like a win-win to me. Thoughts?
> >> >> >
> >> >> > Thanks,
> >> >> >
> >> >> > Alec
> >> >> >
>
Re: Custom CSS for Feedback message is broken in 1.5
@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(message.isInfo() ? ".my-ui-info" : ".my-ui-error"), "
"));
return label;
}
This will set the style you want on and will leave unmodified.
Why doesn't it work for you?
Thanks,
Alec
On Thu, Nov 1, 2012 at 9:55 AM, Sebastien 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 wrote:
>
>> If you want to group messages you can easily use multiple feedback panels,
>> each filtering by severity.
>>
>> Sven
>>
>> Sebastien 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 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 as well.
>> >>
>> >> Alec
>> >>
>> >> On Wed, Oct 31, 2012 at 4:33 PM, Alec Swan wrote:
>> >> > I suggest that instead of overriding CSS class on the you
>> >> > APPEND it to existing CSS classes. This will allow the user to specify
>> >> > their own 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 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
>>
Re: Custom CSS for Feedback message is broken in 1.5
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 wrote:
> If you want to group messages you can easily use multiple feedback panels,
> each filtering by severity.
>
> Sven
>
> Sebastien 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 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 as well.
> >>
> >> Alec
> >>
> >> On Wed, Oct 31, 2012 at 4:33 PM, Alec Swan wrote:
> >> > I suggest that instead of overriding CSS class on the you
> >> > APPEND it to existing CSS classes. This will allow the user to specify
> >> > their own 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 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.
> >> >>>
>
Re: Custom CSS for Feedback message is broken in 1.5
If you want to group messages you can easily use multiple feedback panels, each
filtering by severity.
Sven
Sebastien 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 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 as well.
>>
>> Alec
>>
>> On Wed, Oct 31, 2012 at 4:33 PM, Alec Swan wrote:
>> > I suggest that instead of overriding CSS class on the you
>> > APPEND it to existing CSS classes. This will allow the user to specify
>> > their own 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 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
>> 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:
>> > - element should have class "feedbackPanel" (this is already
>> the
>>
>> case)
>> >
>> > - 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 should not have class at all (currently it has the same
>> > class as the 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 Feedba
Re: Custom CSS for Feedback message is broken in 1.5
@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 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 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 as well.
>>
>> Alec
>>
>> On Wed, Oct 31, 2012 at 4:33 PM, Alec Swan wrote:
>> > I suggest that instead of overriding CSS class on the you
>> > APPEND it to existing CSS classes. This will allow the user to specify
>> > their own 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 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
>> 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:
>> > - element should have class "feedbackPanel" (this is already
>> the
>>
>> case)
>> >
>> > - 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 should not have class at all (currentl
Re: Custom CSS for Feedback message is broken in 1.5
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 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 as well.
>
> Alec
>
> On Wed, Oct 31, 2012 at 4:33 PM, Alec Swan wrote:
> > I suggest that instead of overriding CSS class on the you
> > APPEND it to existing CSS classes. This will allow the user to specify
> > their own 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 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
> 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:
> > - element should have class "feedbackPanel" (this is already
> the
>
> case)
> >
> > - 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 should not have class at all (currently it has the same
> > class as the 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 wrote:
> >>
> >> Hi,
> >>
> >> To sum-up this thread: we have a (not huge, but still) design issue
> >> that
>
Re: Custom CSS for Feedback message is broken in 1.5
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 as well.
Alec
On Wed, Oct 31, 2012 at 4:33 PM, Alec Swan wrote:
> I suggest that instead of overriding CSS class on the you
> APPEND it to existing CSS classes. This will allow the user to specify
> their own 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 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 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:
> - element should have class "feedbackPanel" (this is already the
case)
>
> - 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 should not have class at all (currently it has the same
> class as the 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 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
>>
>>
>> --
Re: Custom CSS for Feedback message is broken in 1.5
I suggest that instead of overriding CSS class on the you APPEND it to existing CSS classes. This will allow the user to specify their own 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 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 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: - element should have class "feedbackPanel" (this is already the >>> >>> case) - 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 should not have class at all (currently it has the same class as the 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 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
Re: Custom CSS for Feedback message is broken in 1.5
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 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: - element should have class "feedbackPanel" (this is already the case) - 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 should not have class at all (currently it has the same class as the 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 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
Re: Custom CSS for Feedback message is broken in 1.5
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 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: > > - element should have class "feedbackPanel" (this is already the > case) > > - 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 should not have class at all (currently it has the same > > class as the 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 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 > >
Re: Custom CSS for Feedback message is broken in 1.5
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: > - element should have class "feedbackPanel" (this is already the case) > - 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 should not have class at all (currently it has the same > class as the 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 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
Re: Custom CSS for Feedback message is broken in 1.5
[X] Other suggestion: don't have a class on the span, or even better, don't have the span element at all inside the list-item For any customisations beyound this, just create your own FeedbackPanel, it's easy and gives complete control. On Sun, Oct 28, 2012, at 17:03, Sebastien 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! :) - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Custom CSS for Feedback message is broken in 1.5
[X] Other suggestion: I agree with Martin's points, especially the 3rd one (span should have no CSS class). To ease extending of FeedbackPanel I'd suggest to delegate #newItem() of the nested MessageListView to a new protected method #newMessageItem() in FeedbackPanel. (Similar to DataTable#newRowItem()) Best regards Sven On 10/29/2012 08:53 AM, Martin Grigorov wrote: Hi, [X] Other suggestion: (please specify) Here is what I think it should be: - element should have class "feedbackPanel" (this is already the case) - 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 should not have class at all (currently it has the same class as the 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 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! :) - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Custom CSS for Feedback message is broken in 1.5
Hi, [X] Other suggestion: (please specify) Here is what I think it should be: - element should have class "feedbackPanel" (this is already the case) - 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 should not have class at all (currently it has the same class as the 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 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! :) -- 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
Re: Custom CSS for Feedback message is broken in 1.5
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! :)
Re: Custom CSS for Feedback message is broken in 1.5
Martin Grigorov wrote:
> Hi,
>
> Here is an example of the produced markup for an single INFO message:
>
>
>
>
>
> Saved model [TestInputObject
> stringProperty = 'test', integerProperty = 100, doubleProperty = 20.5,
> booleanProperty = false, integerInRangeProperty = 50, urlProperty =
> http://wicket.apache.org, phoneNumberUS = (123) 456-1234,
> numberRadioChoice = 1, numbersCheckgroup [], numberRadioGroup= null,
> selected sites {], lines [line one, line two, line three]]
>
>
>
>
>
> Why do we need the new getters when you can just use normal CSS selectors:
>
> div.feedbackPanel {}
> div.feedbackPanel span {}
> ul.feedbackPanel {}
> li.feedbackPanelINFO {}
> span.feedbackPanelINFO {}
>
> What is the big CSS/HTML design problem that I miss ?
That feedbackPanelINFO is set both on li and on span.
In my current project, CSS styling is not done by us, but by a
designer and is shared over several projects, most of them who
don't use Wicket. The CSS styling is just for feedbackPanelINFO,
not for li.feedbackPanelINFO.
AFAIU, similar problems appear in portlet situations, or in other
situations where you don't control CSS fully. As Alec mentions,
Twitter bootstrap is an other example.
Btw, I never wrote that this is a "big" design problem. I just say
that IMHO it's an existing one that goes beyond a single project.
The standard way we cope in our projects is a more-or-less empty
FeedbackPanel subclass with replaced HTML. Not pretty, as we ignore
module boundaries for wicket identifiers; but the alternative --
copying the complete code of FeedbackPanel to a project specific
class -- wouldn't be good either.
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
Re: Custom CSS for Feedback message is broken in 1.5
Hi, >that a CSS class applies both to LI and to below-SPAN element I agree, applying the CSS class on the LI would be sufficient. But the current duplication should do no harm in most situations. Except where you cannot change the CSS, of course. Sven On 10/25/2012 01:07 AM, Joachim Schrod wrote: Paul Bors wrote: Yes, but how would that affect other projects that do expect the CSS to be applied to the LI or SPAN? Come to think about it, I could very simple replace the content of both with my own panels right? I think this is a project specific requirement I just want to add my voice that it's not a project specific requirement, but a sound design change that resolves a design bug. That a CSS class applies both to LI and to below-SPAN element, is clearly not appropriate for almost all situations. The proposed change even keeps that, for backward-compatibility. Of course, one can subclass FeedbackPanel and sustitute the HTML code. We do it in all projects. But this is a workaround for a bug in Wicket's HTML/CSS/interface design, and not a to-be-continued asset. Just my 0.03€ (adjusted for inflation), Joachim - 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
Re: Custom CSS for Feedback message is broken in 1.5
Hi,
Here is an example of the produced markup for an single INFO message:
Saved model [TestInputObject
stringProperty = 'test', integerProperty = 100, doubleProperty = 20.5,
booleanProperty = false, integerInRangeProperty = 50, urlProperty =
http://wicket.apache.org, phoneNumberUS = (123) 456-1234,
numberRadioChoice = 1, numbersCheckgroup [], numberRadioGroup= null,
selected sites {], lines [line one, line two, line three]]
Why do we need the new getters when you can just use normal CSS selectors:
div.feedbackPanel {}
div.feedbackPanel span {}
ul.feedbackPanel {}
li.feedbackPanelINFO {}
span.feedbackPanelINFO {}
What is the big CSS/HTML design problem that I miss ?
On Thu, Oct 25, 2012 at 2:07 AM, Joachim Schrod wrote:
> Paul Bors wrote:
>> Yes, but how would that affect other projects that do expect the CSS to be
>> applied to the LI or SPAN?
>> Come to think about it, I could very simple replace the content of both with
>> my own panels right?
>>
>> I think this is a project specific requirement
>
> I just want to add my voice that it's not a project specific
> requirement, but a sound design change that resolves a design bug.
>
> That a CSS class applies both to LI and to below-SPAN element, is
> clearly not appropriate for almost all situations. The proposed
> change even keeps that, for backward-compatibility.
>
> Of course, one can subclass FeedbackPanel and sustitute the HTML
> code. We do it in all projects. But this is a workaround for a bug
> in Wicket's HTML/CSS/interface design, and not a to-be-continued asset.
>
> Just my 0.03€ (adjusted for inflation),
> Joachim
>
>
> -
> 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
Re: Custom CSS for Feedback message is broken in 1.5
Paul Bors wrote: > Yes, but how would that affect other projects that do expect the CSS to be > applied to the LI or SPAN? > Come to think about it, I could very simple replace the content of both with > my own panels right? > > I think this is a project specific requirement I just want to add my voice that it's not a project specific requirement, but a sound design change that resolves a design bug. That a CSS class applies both to LI and to below-SPAN element, is clearly not appropriate for almost all situations. The proposed change even keeps that, for backward-compatibility. Of course, one can subclass FeedbackPanel and sustitute the HTML code. We do it in all projects. But this is a workaround for a bug in Wicket's HTML/CSS/interface design, and not a to-be-continued asset. Just my 0.03€ (adjusted for inflation), Joachim - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Custom CSS for Feedback message is broken in 1.5
Paul, the problem is that the css class name, returned by getCSSClass will
applies to both li and span.
Consider the style you want to apply (the css class name) is not your own
but coming from an external library ui, like jquery-ui or bootstrap. You
need to apply the css class only to the span *or* to the li. The class
names are added by the FeedbackPanel itelf, in any case, you cannot control
this just by providing you own html markup. I am pretty sure the html you
provided is not an exception and that you will get the class name twice...
WICKET-4831 is backward compatible. However, we can debate if getCSSClass
should be deprecated or not.
For me, it would be a bad practice to let it protected and should therefore
be marked as private; but it is my non binding opinion.
> If that's the case, then I should start flooding the wicket Jira queue
with all the specific needs for my own projects.
I understand perfectly. Thus, there is a workarround I provided ealier in
this thread; but - IMHO, again - I think it could be considered as an issue
as it prevent a (logical?) customization...
Sebastien.
On Wed, Oct 24, 2012 at 4:48 PM, Paul Bors wrote:
> Yes, but how would that affect other projects that do expect the CSS to be
> applied to the LI or SPAN?
> Come to think about it, I could very simple replace the content of both
> with
> my own panels right?
>
> I think this is a project specific requirement and as such should be
> handled
> by extending from Wicket's code and adjusting the behavior as per the
> specific project requirements thus I don't see a real need for WICKET-4831
> "Split custom CSS for Feedback message (list and label)".
>
> If that's the case, then I should start flooding the wicket Jira queue with
> all the specific needs for my own projects.
>
> I only gave an example of how one can have full control with little code :)
>
> ~ Thank you,
> Paul Bors
>
> -Original Message-
> From: Sven Meier [mailto:s...@meiers.net]
> Sent: Wednesday, October 24, 2012 3:04 AM
> To: users@wicket.apache.org
> Subject: Re: Custom CSS for Feedback message is broken in 1.5
>
> The point is that he does *not* want getCSSClass() to be applied to the
> .
>
> Sven
>
> On 10/24/2012 12:24 AM, Paul Bors wrote:
> > There is nothing stopping you from extending from the FeedBackPanel
> > and override the HTML the Wicket component is using.
> >
> > This is how we did it.
> >
> > The HTML:
> > http://wicket.apache.org";>
> >
> >
> >
> > [Feedback message(s)]
> >
> >
> >
> >
> >
> > And the Java:
> > import org.apache.wicket.feedback.IFeedbackMessageFilter;
> > import org.apache.wicket.markup.html.panel.FeedbackPanel;
> >
> > public class MyFeedbackPanel extends FeedbackPanel {
> > private static final long serialVersionUID = 1L;
> >
> > public MyFeedbackPanel (String id) {
> > this(id, null);
> > }
> >
> > public MyFeedbackPanel (String id, IFeedbackMessageFilter filter) {
> > super(id, filter);
> > setOutputMarkupId(true);
> > }
> > }
> >
> > Our application wide CSS:
> >
> > /* FEEDBACK MESSAGES */
> >
> > .feedbackMessages {
> > padding-left: 0;
> > padding-top: 0;
> > text-align: left;
> > margin-left: 0;
> > margin-top: 0;
> > padding-bottom: 1em;
> > }
> >
> > .feedbackMessages div {
> > padding: 0.5em;
> > font-size: xx-small;
> > border: none;
> > }
> >
> > .feedbackMessages div.feedbackPanelERROR {
> > background-color: lightsalmon;
> > border: 1px solid darkred;
> > }
> >
> > .feedbackMessages div.feedbackPanelWARNING {
> > background-color: #FFB90F;
> > border: 1px solid darkgoldenrod;
> > }
> >
> > .feedbackMessages div.feedbackPanelINFO {
> > background-color: lightgreen;
> > border: 1px solid darkgreen;
> > }
> >
> > This code was written for Wicket 1.3.x and migrated to 1.5.x w/o any
> > changes (we're not yet up to 6.x).
> >
> > ~ Thank you,
> >Paul Bors
> >
> > -Original Message-
> > From: Alec Swan [mailto:alecs...@gmail.com]
> > Sent: Tuesday, October 23, 2012 6:08 PM
> > To: users@wicket.apache.org
> > Subject: Re: Custom CSS for Feedback message is broken in 1.5
> >
> > Sebastien, List, ListItem and Label make sense to me and match the
> > terms used in Fee
RE: Custom CSS for Feedback message is broken in 1.5
Yes, but how would that affect other projects that do expect the CSS to be
applied to the LI or SPAN?
Come to think about it, I could very simple replace the content of both with
my own panels right?
I think this is a project specific requirement and as such should be handled
by extending from Wicket's code and adjusting the behavior as per the
specific project requirements thus I don't see a real need for WICKET-4831
"Split custom CSS for Feedback message (list and label)".
If that's the case, then I should start flooding the wicket Jira queue with
all the specific needs for my own projects.
I only gave an example of how one can have full control with little code :)
~ Thank you,
Paul Bors
-Original Message-
From: Sven Meier [mailto:s...@meiers.net]
Sent: Wednesday, October 24, 2012 3:04 AM
To: users@wicket.apache.org
Subject: Re: Custom CSS for Feedback message is broken in 1.5
The point is that he does *not* want getCSSClass() to be applied to the
.
Sven
On 10/24/2012 12:24 AM, Paul Bors wrote:
> There is nothing stopping you from extending from the FeedBackPanel
> and override the HTML the Wicket component is using.
>
> This is how we did it.
>
> The HTML:
> http://wicket.apache.org";>
>
>
>
> [Feedback message(s)]
>
>
>
>
>
> And the Java:
> import org.apache.wicket.feedback.IFeedbackMessageFilter;
> import org.apache.wicket.markup.html.panel.FeedbackPanel;
>
> public class MyFeedbackPanel extends FeedbackPanel {
> private static final long serialVersionUID = 1L;
>
> public MyFeedbackPanel (String id) {
> this(id, null);
> }
>
> public MyFeedbackPanel (String id, IFeedbackMessageFilter filter) {
> super(id, filter);
> setOutputMarkupId(true);
> }
> }
>
> Our application wide CSS:
>
> /* FEEDBACK MESSAGES */
>
> .feedbackMessages {
> padding-left: 0;
> padding-top: 0;
> text-align: left;
> margin-left: 0;
> margin-top: 0;
> padding-bottom: 1em;
> }
>
> .feedbackMessages div {
> padding: 0.5em;
> font-size: xx-small;
> border: none;
> }
>
> .feedbackMessages div.feedbackPanelERROR {
> background-color: lightsalmon;
> border: 1px solid darkred;
> }
>
> .feedbackMessages div.feedbackPanelWARNING {
> background-color: #FFB90F;
> border: 1px solid darkgoldenrod;
> }
>
> .feedbackMessages div.feedbackPanelINFO {
> background-color: lightgreen;
> border: 1px solid darkgreen;
> }
>
> This code was written for Wicket 1.3.x and migrated to 1.5.x w/o any
> changes (we're not yet up to 6.x).
>
> ~ Thank you,
>Paul Bors
>
> -Original Message-
> From: Alec Swan [mailto:alecs...@gmail.com]
> Sent: Tuesday, October 23, 2012 6:08 PM
> To: users@wicket.apache.org
> Subject: Re: Custom CSS for Feedback message is broken in 1.5
>
> Sebastien, List, ListItem and Label make sense to me and match the
> terms used in FeedbackPanel class. However, I try not to get too hung
> up on naming for the sake of making progress :)
>
> On Tue, Oct 23, 2012 at 3:39 PM, Sebastien wrote:
>> Alec, you are right, I did thought about that.
>>
>> My reflection was that getListCSS applies to list *element* (li) and
>> it is quite easy to understand that getLabelCSS (which applies to the
>> label) stands for the message itself (which is a span element).
>>
>> But in another hand we can imagine that these naming are related to
>> wicket
>> *component* instead; so, it is true that it would technically best to
>> have getListItemCSS (applies to ListItem) and getLabelCSS (applies to
> Label).
>> But what if the user overrides #newMessageDisplayComponent and return
>> something other than a Label? A Panel for instance? Maybe getLabelCSS
>> appears to not be logical anymore in this context: we have a
>> getListItemCSS which still applies to a ListItem and a getLabelCSS
>> which applies to... a Panel.
>>
>> In another hand (again), we can also imagine that the HTML markup is
>> getting "overridden" (while extending FeedbackPanel), li and span
>> elements may have been replaced by other elements (2 divs for
>> instance)... So getListCSS may also not be logical in this context,
>> and would have better been getContainerCSS or something like that...
>>
>> Not easy to find right naming; its a kind of Ouroboros* ** discussion
>> in this case...
>> But at the end, will the user better understand getListCSS or
>> getListItemCSS? Also, is getLab
Re: Custom CSS for Feedback message is broken in 1.5
The point is that he does *not* want getCSSClass() to be applied to the
.
Sven
On 10/24/2012 12:24 AM, Paul Bors wrote:
There is nothing stopping you from extending from the FeedBackPanel and
override the HTML the Wicket component is using.
This is how we did it.
The HTML:
http://wicket.apache.org";>
[Feedback message(s)]
And the Java:
import org.apache.wicket.feedback.IFeedbackMessageFilter;
import org.apache.wicket.markup.html.panel.FeedbackPanel;
public class MyFeedbackPanel extends FeedbackPanel {
private static final long serialVersionUID = 1L;
public MyFeedbackPanel (String id) {
this(id, null);
}
public MyFeedbackPanel (String id, IFeedbackMessageFilter filter) {
super(id, filter);
setOutputMarkupId(true);
}
}
Our application wide CSS:
/* FEEDBACK MESSAGES */
.feedbackMessages {
padding-left: 0;
padding-top: 0;
text-align: left;
margin-left: 0;
margin-top: 0;
padding-bottom: 1em;
}
.feedbackMessages div {
padding: 0.5em;
font-size: xx-small;
border: none;
}
.feedbackMessages div.feedbackPanelERROR {
background-color: lightsalmon;
border: 1px solid darkred;
}
.feedbackMessages div.feedbackPanelWARNING {
background-color: #FFB90F;
border: 1px solid darkgoldenrod;
}
.feedbackMessages div.feedbackPanelINFO {
background-color: lightgreen;
border: 1px solid darkgreen;
}
This code was written for Wicket 1.3.x and migrated to 1.5.x w/o any changes
(we're not yet up to 6.x).
~ Thank you,
Paul Bors
-Original Message-
From: Alec Swan [mailto:alecs...@gmail.com]
Sent: Tuesday, October 23, 2012 6:08 PM
To: users@wicket.apache.org
Subject: Re: Custom CSS for Feedback message is broken in 1.5
Sebastien, List, ListItem and Label make sense to me and match the terms
used in FeedbackPanel class. However, I try not to get too hung up on naming
for the sake of making progress :)
On Tue, Oct 23, 2012 at 3:39 PM, Sebastien wrote:
Alec, you are right, I did thought about that.
My reflection was that getListCSS applies to list *element* (li) and
it is quite easy to understand that getLabelCSS (which applies to the
label) stands for the message itself (which is a span element).
But in another hand we can imagine that these naming are related to
wicket
*component* instead; so, it is true that it would technically best to
have getListItemCSS (applies to ListItem) and getLabelCSS (applies to
Label).
But what if the user overrides #newMessageDisplayComponent and return
something other than a Label? A Panel for instance? Maybe getLabelCSS
appears to not be logical anymore in this context: we have a
getListItemCSS which still applies to a ListItem and a getLabelCSS
which applies to... a Panel.
In another hand (again), we can also imagine that the HTML markup is
getting "overridden" (while extending FeedbackPanel), li and span
elements may have been replaced by other elements (2 divs for
instance)... So getListCSS may also not be logical in this context,
and would have better been getContainerCSS or something like that...
Not easy to find right naming; its a kind of Ouroboros* ** discussion
in this case...
But at the end, will the user better understand getListCSS or
getListItemCSS? Also, is getLabelCSS the best? What about getMessageCSS?
That's all open questions... I wish you a good night with that! ;)
Sebastien
* http://en.wikipedia.org/wiki/Ouroboros
** I am pretty sure this term has previously been used in this mailing
list but I don't remember who... So there is a credit for someone
somewhere :)
On Tue, Oct 23, 2012 at 9:15 PM, Alec Swan wrote:
Technically it should be getListItemCSS, not getListCSS. Or maybe
have all three getListCSS, getListItemCSS and getLabelCSS
On Mon, Oct 22, 2012 at 12:46 PM, Sebastien wrote:
Done, https://issues.apache.org/jira/browse/WICKET-4831
Please let me know if your encounter any issue (wrong base code for
instance) or if you have any questions...
Thanks,
Sebastien.
On Mon, Oct 22, 2012 at 8:06 PM, Sven Meier wrote:
Please open a Jira issue and provide a patch as you suggested.
Thanks
Sven
On 10/21/2012 01:06 AM, Sebastien wrote:
Sven,
If you agree to have two methods: getListCSSClass and
getLabelCSSClass (which apply respectively on li and span), and
mark getCSSClass as deprecated (until marked as private), then
the path is ready for branch wicket-1.5.x. I am waiting for your
go-ahead to send the patch
somewhere
or
submit the pull request on github.
If you do not agree, please tell me what I can do.
Thanks & best regards,
Sebastien.
--**--**-
To unsubscribe, e-mail: users-unsubscribe@wicket.**apache.org<
users-unsubscr...@wicket.apache.org>
For additional com
RE: Custom CSS for Feedback message is broken in 1.5
There is nothing stopping you from extending from the FeedBackPanel and
override the HTML the Wicket component is using.
This is how we did it.
The HTML:
http://wicket.apache.org";>
[Feedback message(s)]
And the Java:
import org.apache.wicket.feedback.IFeedbackMessageFilter;
import org.apache.wicket.markup.html.panel.FeedbackPanel;
public class MyFeedbackPanel extends FeedbackPanel {
private static final long serialVersionUID = 1L;
public MyFeedbackPanel (String id) {
this(id, null);
}
public MyFeedbackPanel (String id, IFeedbackMessageFilter filter) {
super(id, filter);
setOutputMarkupId(true);
}
}
Our application wide CSS:
/* FEEDBACK MESSAGES */
.feedbackMessages {
padding-left: 0;
padding-top: 0;
text-align: left;
margin-left: 0;
margin-top: 0;
padding-bottom: 1em;
}
.feedbackMessages div {
padding: 0.5em;
font-size: xx-small;
border: none;
}
.feedbackMessages div.feedbackPanelERROR {
background-color: lightsalmon;
border: 1px solid darkred;
}
.feedbackMessages div.feedbackPanelWARNING {
background-color: #FFB90F;
border: 1px solid darkgoldenrod;
}
.feedbackMessages div.feedbackPanelINFO {
background-color: lightgreen;
border: 1px solid darkgreen;
}
This code was written for Wicket 1.3.x and migrated to 1.5.x w/o any changes
(we're not yet up to 6.x).
~ Thank you,
Paul Bors
-Original Message-
From: Alec Swan [mailto:alecs...@gmail.com]
Sent: Tuesday, October 23, 2012 6:08 PM
To: users@wicket.apache.org
Subject: Re: Custom CSS for Feedback message is broken in 1.5
Sebastien, List, ListItem and Label make sense to me and match the terms
used in FeedbackPanel class. However, I try not to get too hung up on naming
for the sake of making progress :)
On Tue, Oct 23, 2012 at 3:39 PM, Sebastien wrote:
> Alec, you are right, I did thought about that.
>
> My reflection was that getListCSS applies to list *element* (li) and
> it is quite easy to understand that getLabelCSS (which applies to the
> label) stands for the message itself (which is a span element).
>
> But in another hand we can imagine that these naming are related to
> wicket
> *component* instead; so, it is true that it would technically best to
> have getListItemCSS (applies to ListItem) and getLabelCSS (applies to
Label).
> But what if the user overrides #newMessageDisplayComponent and return
> something other than a Label? A Panel for instance? Maybe getLabelCSS
> appears to not be logical anymore in this context: we have a
> getListItemCSS which still applies to a ListItem and a getLabelCSS
> which applies to... a Panel.
>
> In another hand (again), we can also imagine that the HTML markup is
> getting "overridden" (while extending FeedbackPanel), li and span
> elements may have been replaced by other elements (2 divs for
> instance)... So getListCSS may also not be logical in this context,
> and would have better been getContainerCSS or something like that...
>
> Not easy to find right naming; its a kind of Ouroboros* ** discussion
> in this case...
> But at the end, will the user better understand getListCSS or
> getListItemCSS? Also, is getLabelCSS the best? What about getMessageCSS?
>
> That's all open questions... I wish you a good night with that! ;)
> Sebastien
>
> * http://en.wikipedia.org/wiki/Ouroboros
> ** I am pretty sure this term has previously been used in this mailing
> list but I don't remember who... So there is a credit for someone
> somewhere :)
>
>
> On Tue, Oct 23, 2012 at 9:15 PM, Alec Swan wrote:
>
>> Technically it should be getListItemCSS, not getListCSS. Or maybe
>> have all three getListCSS, getListItemCSS and getLabelCSS
>>
>> On Mon, Oct 22, 2012 at 12:46 PM, Sebastien wrote:
>> > Done, https://issues.apache.org/jira/browse/WICKET-4831
>> > Please let me know if your encounter any issue (wrong base code for
>> > instance) or if you have any questions...
>> >
>> > Thanks,
>> > Sebastien.
>> >
>> > On Mon, Oct 22, 2012 at 8:06 PM, Sven Meier wrote:
>> >
>> >> Please open a Jira issue and provide a patch as you suggested.
>> >>
>> >> Thanks
>> >> Sven
>> >>
>> >>
>> >>
>> >> On 10/21/2012 01:06 AM, Sebastien wrote:
>> >>
>> >>> Sven,
>> >>>
>> >>> If you agree to have two methods: getListCSSClass and
>> >>> getLabelCSSClass (which apply respectively on li and span), and
>> >>> mark getCSSClass as deprecated (until marked as private), then
>> >>&
Re: Custom CSS for Feedback message is broken in 1.5
Sebastien, List, ListItem and Label make sense to me and match the terms used in FeedbackPanel class. However, I try not to get too hung up on naming for the sake of making progress :) On Tue, Oct 23, 2012 at 3:39 PM, Sebastien wrote: > Alec, you are right, I did thought about that. > > My reflection was that getListCSS applies to list *element* (li) and it is > quite easy to understand that getLabelCSS (which applies to the label) > stands for the message itself (which is a span element). > > But in another hand we can imagine that these naming are related to wicket > *component* instead; so, it is true that it would technically best to have > getListItemCSS (applies to ListItem) and getLabelCSS (applies to Label). > But what if the user overrides #newMessageDisplayComponent and return > something other than a Label? A Panel for instance? Maybe getLabelCSS > appears to not be logical anymore in this context: we have a getListItemCSS > which still applies to a ListItem and a getLabelCSS which applies to... a > Panel. > > In another hand (again), we can also imagine that the HTML markup is > getting "overridden" (while extending FeedbackPanel), li and span elements > may have been replaced by other elements (2 divs for instance)... So > getListCSS may also not be logical in this context, and would have better > been getContainerCSS or something like that... > > Not easy to find right naming; its a kind of Ouroboros* ** discussion in > this case... > But at the end, will the user better understand getListCSS or > getListItemCSS? Also, is getLabelCSS the best? What about getMessageCSS? > > That's all open questions... I wish you a good night with that! ;) > Sebastien > > * http://en.wikipedia.org/wiki/Ouroboros > ** I am pretty sure this term has previously been used in this mailing list > but I don't remember who... So there is a credit for someone somewhere :) > > > On Tue, Oct 23, 2012 at 9:15 PM, Alec Swan wrote: > >> Technically it should be getListItemCSS, not getListCSS. Or maybe have >> all three getListCSS, getListItemCSS and getLabelCSS >> >> On Mon, Oct 22, 2012 at 12:46 PM, Sebastien wrote: >> > Done, https://issues.apache.org/jira/browse/WICKET-4831 >> > Please let me know if your encounter any issue (wrong base code for >> > instance) or if you have any questions... >> > >> > Thanks, >> > Sebastien. >> > >> > On Mon, Oct 22, 2012 at 8:06 PM, Sven Meier wrote: >> > >> >> Please open a Jira issue and provide a patch as you suggested. >> >> >> >> Thanks >> >> Sven >> >> >> >> >> >> >> >> On 10/21/2012 01:06 AM, Sebastien wrote: >> >> >> >>> Sven, >> >>> >> >>> If you agree to have two methods: getListCSSClass and getLabelCSSClass >> >>> (which apply respectively on li and span), and mark getCSSClass as >> >>> deprecated (until marked as private), then the path is ready for branch >> >>> wicket-1.5.x. I am waiting for your go-ahead to send the patch >> somewhere >> >>> or >> >>> submit the pull request on github. >> >>> >> >>> If you do not agree, please tell me what I can do. >> >>> >> >>> Thanks & best regards, >> >>> Sebastien. >> >>> >> >>> >> >> >> >> >> --**--**- >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.**apache.org< >> 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
Re: Custom CSS for Feedback message is broken in 1.5
Alec, you are right, I did thought about that. My reflection was that getListCSS applies to list *element* (li) and it is quite easy to understand that getLabelCSS (which applies to the label) stands for the message itself (which is a span element). But in another hand we can imagine that these naming are related to wicket *component* instead; so, it is true that it would technically best to have getListItemCSS (applies to ListItem) and getLabelCSS (applies to Label). But what if the user overrides #newMessageDisplayComponent and return something other than a Label? A Panel for instance? Maybe getLabelCSS appears to not be logical anymore in this context: we have a getListItemCSS which still applies to a ListItem and a getLabelCSS which applies to... a Panel. In another hand (again), we can also imagine that the HTML markup is getting "overridden" (while extending FeedbackPanel), li and span elements may have been replaced by other elements (2 divs for instance)... So getListCSS may also not be logical in this context, and would have better been getContainerCSS or something like that... Not easy to find right naming; its a kind of Ouroboros* ** discussion in this case... But at the end, will the user better understand getListCSS or getListItemCSS? Also, is getLabelCSS the best? What about getMessageCSS? That's all open questions... I wish you a good night with that! ;) Sebastien * http://en.wikipedia.org/wiki/Ouroboros ** I am pretty sure this term has previously been used in this mailing list but I don't remember who... So there is a credit for someone somewhere :) On Tue, Oct 23, 2012 at 9:15 PM, Alec Swan wrote: > Technically it should be getListItemCSS, not getListCSS. Or maybe have > all three getListCSS, getListItemCSS and getLabelCSS > > On Mon, Oct 22, 2012 at 12:46 PM, Sebastien wrote: > > Done, https://issues.apache.org/jira/browse/WICKET-4831 > > Please let me know if your encounter any issue (wrong base code for > > instance) or if you have any questions... > > > > Thanks, > > Sebastien. > > > > On Mon, Oct 22, 2012 at 8:06 PM, Sven Meier wrote: > > > >> Please open a Jira issue and provide a patch as you suggested. > >> > >> Thanks > >> Sven > >> > >> > >> > >> On 10/21/2012 01:06 AM, Sebastien wrote: > >> > >>> Sven, > >>> > >>> If you agree to have two methods: getListCSSClass and getLabelCSSClass > >>> (which apply respectively on li and span), and mark getCSSClass as > >>> deprecated (until marked as private), then the path is ready for branch > >>> wicket-1.5.x. I am waiting for your go-ahead to send the patch > somewhere > >>> or > >>> submit the pull request on github. > >>> > >>> If you do not agree, please tell me what I can do. > >>> > >>> Thanks & best regards, > >>> Sebastien. > >>> > >>> > >> > >> > --**--**- > >> To unsubscribe, e-mail: users-unsubscribe@wicket.**apache.org< > 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 > >
Re: Custom CSS for Feedback message is broken in 1.5
Technically it should be getListItemCSS, not getListCSS. Or maybe have all three getListCSS, getListItemCSS and getLabelCSS On Mon, Oct 22, 2012 at 12:46 PM, Sebastien wrote: > Done, https://issues.apache.org/jira/browse/WICKET-4831 > Please let me know if your encounter any issue (wrong base code for > instance) or if you have any questions... > > Thanks, > Sebastien. > > On Mon, Oct 22, 2012 at 8:06 PM, Sven Meier wrote: > >> Please open a Jira issue and provide a patch as you suggested. >> >> Thanks >> Sven >> >> >> >> On 10/21/2012 01:06 AM, Sebastien wrote: >> >>> Sven, >>> >>> If you agree to have two methods: getListCSSClass and getLabelCSSClass >>> (which apply respectively on li and span), and mark getCSSClass as >>> deprecated (until marked as private), then the path is ready for branch >>> wicket-1.5.x. I am waiting for your go-ahead to send the patch somewhere >>> or >>> submit the pull request on github. >>> >>> If you do not agree, please tell me what I can do. >>> >>> Thanks & best regards, >>> Sebastien. >>> >>> >> >> --**--**- >> To unsubscribe, e-mail: >> users-unsubscribe@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
Re: Custom CSS for Feedback message is broken in 1.5
Done, https://issues.apache.org/jira/browse/WICKET-4831 Please let me know if your encounter any issue (wrong base code for instance) or if you have any questions... Thanks, Sebastien. On Mon, Oct 22, 2012 at 8:06 PM, Sven Meier wrote: > Please open a Jira issue and provide a patch as you suggested. > > Thanks > Sven > > > > On 10/21/2012 01:06 AM, Sebastien wrote: > >> Sven, >> >> If you agree to have two methods: getListCSSClass and getLabelCSSClass >> (which apply respectively on li and span), and mark getCSSClass as >> deprecated (until marked as private), then the path is ready for branch >> wicket-1.5.x. I am waiting for your go-ahead to send the patch somewhere >> or >> submit the pull request on github. >> >> If you do not agree, please tell me what I can do. >> >> Thanks & best regards, >> Sebastien. >> >> > > --**--**- > To unsubscribe, e-mail: > users-unsubscribe@wicket.**apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
Re: Custom CSS for Feedback message is broken in 1.5
Please open a Jira issue and provide a patch as you suggested. Thanks Sven On 10/21/2012 01:06 AM, Sebastien wrote: Sven, If you agree to have two methods: getListCSSClass and getLabelCSSClass (which apply respectively on li and span), and mark getCSSClass as deprecated (until marked as private), then the path is ready for branch wicket-1.5.x. I am waiting for your go-ahead to send the patch somewhere or submit the pull request on github. If you do not agree, please tell me what I can do. Thanks & best regards, Sebastien. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Custom CSS for Feedback message is broken in 1.5
Sven, If you agree to have two methods: getListCSSClass and getLabelCSSClass (which apply respectively on li and span), and mark getCSSClass as deprecated (until marked as private), then the path is ready for branch wicket-1.5.x. I am waiting for your go-ahead to send the patch somewhere or submit the pull request on github. If you do not agree, please tell me what I can do. Thanks & best regards, Sebastien.
Re: Custom CSS for Feedback message is broken in 1.5
Because if you use Twitter bootstrap and add "alert alert-info" CSS classes, then it's not going to look nice if it's applied to and . On Sat, Oct 20, 2012 at 3:05 PM, Sven Meier wrote: > I was just going to ask you why you don't overwrite #getCSSClass(). > > What harm does it if the CSS class is on the too? > > Sven > > > On 10/20/2012 11:01 PM, Alec Swan wrote: >> >> Note that I need to set CSS styles on the label () and not the >> list item () and hence cannot override getCSSClass() because it is >> applied to both. >> >> On Sat, Oct 20, 2012 at 2:58 PM, Alec Swan wrote: >>> >>> Hello, >>> >>> This Wiki page explains how to add custom CSS styles to Feedback >>> messages in 1.4+: >>> https://cwiki.apache.org/WICKET/css-enabled-feedback-panel.html >>> >>> Basically, it suggests that you override >>> FeedbackPanel#newMessageDisplayComponent(..) method and add the custom >>> CSS class to the component before returning it. >>> >>> However, this approach does not work in 1.5 because >>> FeedbackPanel.MessageListView#populateItem calls >>> FeedbackPanel#newMessageDisplayComponent(..) and then immediately adds >>> an AttributeModifier that replaces CSS class that was set inside >>> newMessageDisplayComponent(). >>> >>> Is this a bug or Wiki is wrong? >>> Is there any workaround without creating a custom FeedbackPanel? >>> >>> Thanks, >>> >>> Alec >> >> - >> 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
Re: Custom CSS for Feedback message is broken in 1.5
Hi,
I also suffer from this feature (having the same CSS class applied onto
both li and span) since a long time.
@Sven, this could be important to remove one or the other class attribute
in case the class return by getCSSClass() is not from your own CSS (you
want to apply jquery-ui style for instance)
The update to be done on FeedbackPanel is really straightforward and could
easily be backward compatible. However, I never found the 20 necessary
minutes to make a pull request...
Anyway, the following "hack" could be done on a extended FeedbackPanel to
remove the class on the span, you can adapt it to remove class on li tags
instead:
@Override
protected void onBeforeRender()
{
super.onBeforeRender();
// removes the 'errorLevel' class on span wicket:id="message".
ListView messages = (ListView)
this.get("feedbackul:messages");
Iterator iterator = messages.iterator();
while (iterator.hasNext())
{
Component component = iterator.next().get("message");
//iterator.next() returns the ListItem
if (component != null)
{
component.add(AttributeModifier.remove("class"));
}
}
}
Best regards,
Sebastien.
On Sat, Oct 20, 2012 at 11:05 PM, Sven Meier wrote:
> I was just going to ask you why you don't overwrite #getCSSClass().
>
> What harm does it if the CSS class is on the too?
>
> Sven
>
>
> On 10/20/2012 11:01 PM, Alec Swan wrote:
>
>> Note that I need to set CSS styles on the label () and not the
>> list item () and hence cannot override getCSSClass() because it is
>> applied to both.
>>
>> On Sat, Oct 20, 2012 at 2:58 PM, Alec Swan wrote:
>>
>>> Hello,
>>>
>>> This Wiki page explains how to add custom CSS styles to Feedback
>>> messages in 1.4+:
>>> https://cwiki.apache.org/**WICKET/css-enabled-feedback-**panel.html
>>>
>>> Basically, it suggests that you override
>>> FeedbackPanel#**newMessageDisplayComponent(..) method and add the custom
>>> CSS class to the component before returning it.
>>>
>>> However, this approach does not work in 1.5 because
>>> FeedbackPanel.MessageListView#**populateItem calls
>>> FeedbackPanel#**newMessageDisplayComponent(..) and then immediately adds
>>> an AttributeModifier that replaces CSS class that was set inside
>>> newMessageDisplayComponent().
>>>
>>> Is this a bug or Wiki is wrong?
>>> Is there any workaround without creating a custom FeedbackPanel?
>>>
>>> Thanks,
>>>
>>> Alec
>>>
>> --**--**-
>> To unsubscribe, e-mail:
>> users-unsubscribe@wicket.**apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>
>
> --**--**-
> To unsubscribe, e-mail:
> users-unsubscribe@wicket.**apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
Re: Custom CSS for Feedback message is broken in 1.5
I was just going to ask you why you don't overwrite #getCSSClass(). What harm does it if the CSS class is on the too? Sven On 10/20/2012 11:01 PM, Alec Swan wrote: Note that I need to set CSS styles on the label () and not the list item () and hence cannot override getCSSClass() because it is applied to both. On Sat, Oct 20, 2012 at 2:58 PM, Alec Swan wrote: Hello, This Wiki page explains how to add custom CSS styles to Feedback messages in 1.4+: https://cwiki.apache.org/WICKET/css-enabled-feedback-panel.html Basically, it suggests that you override FeedbackPanel#newMessageDisplayComponent(..) method and add the custom CSS class to the component before returning it. However, this approach does not work in 1.5 because FeedbackPanel.MessageListView#populateItem calls FeedbackPanel#newMessageDisplayComponent(..) and then immediately adds an AttributeModifier that replaces CSS class that was set inside newMessageDisplayComponent(). Is this a bug or Wiki is wrong? Is there any workaround without creating a custom FeedbackPanel? Thanks, Alec - 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
Re: Custom CSS for Feedback message is broken in 1.5
Note that I need to set CSS styles on the label () and not the list item () and hence cannot override getCSSClass() because it is applied to both. On Sat, Oct 20, 2012 at 2:58 PM, Alec Swan wrote: > Hello, > > This Wiki page explains how to add custom CSS styles to Feedback > messages in 1.4+: > https://cwiki.apache.org/WICKET/css-enabled-feedback-panel.html > > Basically, it suggests that you override > FeedbackPanel#newMessageDisplayComponent(..) method and add the custom > CSS class to the component before returning it. > > However, this approach does not work in 1.5 because > FeedbackPanel.MessageListView#populateItem calls > FeedbackPanel#newMessageDisplayComponent(..) and then immediately adds > an AttributeModifier that replaces CSS class that was set inside > newMessageDisplayComponent(). > > Is this a bug or Wiki is wrong? > Is there any workaround without creating a custom FeedbackPanel? > > Thanks, > > Alec - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Custom CSS for Feedback message is broken in 1.5
Hello, This Wiki page explains how to add custom CSS styles to Feedback messages in 1.4+: https://cwiki.apache.org/WICKET/css-enabled-feedback-panel.html Basically, it suggests that you override FeedbackPanel#newMessageDisplayComponent(..) method and add the custom CSS class to the component before returning it. However, this approach does not work in 1.5 because FeedbackPanel.MessageListView#populateItem calls FeedbackPanel#newMessageDisplayComponent(..) and then immediately adds an AttributeModifier that replaces CSS class that was set inside newMessageDisplayComponent(). Is this a bug or Wiki is wrong? Is there any workaround without creating a custom FeedbackPanel? Thanks, Alec - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
