Re: Custom CSS for Feedback message is broken in 1.5

[Martin Grigorov]

Hi Alec,

Please use the mailing lists. Don't write private messages.

On Wed, Nov 7, 2012 at 8:02 PM, Alec Swan alecs...@gmail.com 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 svenme...@apache.org
Date:   Fri Nov 2 21:31:46 2012 +0100

WICKET-4831 removed class attribute from markup

commit afec3a61ccd63e833586be33867eb873a721a941
Author: Martin Tzvetanov Grigorov mgrigo...@apache.org
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 mgrigo...@apache.org
 wrote:
  The ticket says that the improvement is in 1.5.9, no ?
 
 
  On Wed, Nov 7, 2012 at 1:45 AM, Alec Swan alecs...@gmail.com wrote:
 
  Martin, could you please merge your changes to 1.5.9 branch?
 
  Thanks,
 
  Alec
 
 
  -- Forwarded message --
  From: Alec Swan alecs...@gmail.com
  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 seb...@gmail.com 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
   mgrigo...@apache.orgwrote:
  
   Done!
  
   Please confirm that this is enough for now.
  
   On Fri, Nov 2, 2012 at 7:01 PM, Sebastien seb...@gmail.com 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 seb...@gmail.com
 wrote:
 Hi Alec,

 If Sven or Martin agree with this solution for 1.5.9  6.3.0, I
 can
attach
 the patch(es) to the opened ticket if needed. (but to replace a
 word
   by
 another, I am not sure my support will help that much! :) )

 I also think that we can keep this AttributeAppender even with
 the
changes
 to be done for wicket7 (with the Martin's suggestion for
 instance). At
 least I do not see yet any potential issue / unexpected behavior
 that
   can
 happens, and we keep the advantage it provides...

 Best regards,
 Sebastien.

 On Fri, Nov 2, 2012 at 4:21 PM, Alec Swan alecs...@gmail.com
 wrote:

 Sebastien, thanks for reviewing and approving the proposal. So,
 what
 do we need to do to make it in 1.5.9? Or did you already check
 it
 in
 there?

 Thanks,

 Alec

 On Thu, Nov 1, 2012 at 6:04 PM, Sebastien seb...@gmail.com
 wrote:
  Hi Alec,
 
  Thanks for having taking time to write the code snippet
 bellow,
  I
better
  understand your idea!..
  I did not realized you didn't want to use getCssClass, but I
  think
   it
is
  good solution anyway! It is easy for the user to replace
  message.isInfo() ? .my-ui-info : .my-ui-error
  by its custom method: getMessageCssClass(message.getLevel())
 or
something
  equivalent as we spoke before, so that's fine for me. Well
  done!
 
  Thanks again  best regards,
  Sebastien.
 
   
  
  
  
   --
   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
  
  
 
 
 
 
  --
  Martin Grigorov
  jWeekend
  Training, Consulting, Development
  http://jWeekend.com
 




-- 
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com http://jweekend.com/

Re: Custom CSS for Feedback message is broken in 1.5

[Alec Swan]

Is anybody merging this in 1.5.9?

On Fri, Nov 2, 2012 at 11:37 PM, miteshaegis mitesh.ae...@gmail.com wrote:
 Hi,

 You can use set of div 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

[miteshaegis]

Hi,

You can use set of div 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

[Alec Swan]

Sebastien, thanks for reviewing and approving the proposal. So, what
do we need to do to make it in 1.5.9? Or did you already check it in
there?

Thanks,

Alec

On Thu, Nov 1, 2012 at 6:04 PM, Sebastien seb...@gmail.com wrote:
 Hi Alec,

 Thanks for having taking time to write the code snippet bellow, I better
 understand your idea!..
 I did not realized you didn't want to use getCssClass, but I think it is
 good solution anyway! It is easy for the user to replace
 message.isInfo() ? .my-ui-info : .my-ui-error
 by its custom method: getMessageCssClass(message.getLevel()) or something
 equivalent as we spoke before, so that's fine for me. Well done!

 Thanks again  best regards,
 Sebastien.


 On Thu, Nov 1, 2012 at 11:57 PM, Alec Swan alecs...@gmail.com wrote:

 @Sebastien The scenario you described it exactly the scenario I used
 to start this thread. Please read my original post.

 So, the solution is to change Wicket code
 FeedbackPanel.MessageListView#populateItem to use  AttributeAppender
 instead of AttributeModifier as I suggested in my previous message. In
 addition, your code should override newMessageDisplayComponent(..) as
 follows:

 protected Component newMessageDisplayComponent(String id,
 FeedbackMessage message) {
   Component label = super.newMessageDisplayComponent(id, message);
   label.add(new AttributeAppender(class, new
 ModelString(message.isInfo() ? .my-ui-info : .my-ui-error), 
 ));
   return label;
 }

 This will set the style you want on span and will leave li unmodified.

 Why doesn't it work for you?

 Thanks,

 Alec

 On Thu, Nov 1, 2012 at 9:55 AM, Sebastien seb...@gmail.com wrote:
  Hi,
 
  @Alec, the use case is the following:
  Consider you are not the owner of the css-class(es). The css provider
 (a
  ui-framework, a designer, ...) will provide one style by message level
  (let's say .my-ui-warn, .my-ui-error, .my-ui-info, etc). So you will
  override #getCssClass in order to return the corresponding css-class
  depending of the level type (supplied as method's argument). But... the
  provided class/style is designed to be applied *only* to one element. So,
  if the css-class is applied onto both LI and SPAN, there will be a style
  overlap which will result to a bad display... As the
  message-level-css-class is *always* appended to both elements, there is
 yet
  no other choice (I think) to have our own FeedbackPanel or extending the
  existing one with the hack I provided earlier...
 
  @Sven: Thanks for your suggestion! It would result to a different
 component
  but it is certainly more relevant...
 
  Best regards,
  Sebastien.
 
 
  On Thu, Nov 1, 2012 at 4:17 PM, Sven Meier s...@meiers.net wrote:
 
  If you want to group messages you can easily use multiple feedback
 panels,
  each filtering by severity.
 
  Sven
 
  Sebastien seb...@gmail.com schrieb:
 
  Hi,
  
  @Alec, unfortunately I think your workaround does not handle the case
 we
  do
  *not* want the message-level-css-class on the SPAN, and that we still
 want
  it on the LI...
  
  @Sven, well if the refactoring is planned for Wicket 7 (a question will
  remain about doing something, backward compatible, for current
 versions),
  then it changes things...
  Then, I would maybe have a request about this refactored
 FeedbackPanel: I
  would like to be able to have/display messages grouped by levels (so
 each
  level is enclosed in its own container). That would simply mean that
 the
  UL
  will becomes a repeater. For instance, if this 'grouping option' is not
  activated, the repeater will iterate only once, with all feedback
 message
  of any level type. If it is activated, the repeater will iterate as
 many
  times as there is distinct message level types. And, last but not
 least,
  we
  should be able to apply the message-level-css-class to this repeater
 (and
  be able to *not* apply it to LI nor SPAN... so the loop is looped*).
  
  If you, dev-team, think this request is not relevant for wicket-core,
  please keep in mind this need while refactoring so you may provide the
  necessary/accessible things for the user wishing to *override*
  FeedbackPanel to achieve this goal...
  
  Thanks in advance  best regards,
  Sebastien
  
  (*) hazardous translation from French...
  
  
  On Wed, Oct 31, 2012 at 11:37 PM, Alec Swan alecs...@gmail.com
 wrote:
  
   So, the patch can be applied to 1.5.8 and will replace
   label.add(levelModifier);
   with
   label.add(new AttributeAppender(class, replacementModel))
  
   You may want to add AttributeAppender to li as well.
  
   Alec
  
   On Wed, Oct 31, 2012 at 4:33 PM, Alec Swan alecs...@gmail.com
 wrote:
I suggest that instead of overriding CSS class on the span you
APPEND it to existing CSS classes. This will allow the user to
 specify
their own span CSS class in newMessageDisplayComponent(..) AND
 will
support backward compatibility.
   
Sounds like a win-win to me. Thoughts?
   
Thanks,
   
Alec
   
On Wed, Oct 31, 2012 

Re: Custom CSS for Feedback message is broken in 1.5

[Sebastien]

Hi Alec,

If Sven or Martin agree with this solution for 1.5.9  6.3.0, I can attach
the patch(es) to the opened ticket if needed. (but to replace a word by
another, I am not sure my support will help that much! :) )

I also think that we can keep this AttributeAppender even with the changes
to be done for wicket7 (with the Martin's suggestion for instance). At
least I do not see yet any potential issue / unexpected behavior that can
happens, and we keep the advantage it provides...

Best regards,
Sebastien.

On Fri, Nov 2, 2012 at 4:21 PM, Alec Swan alecs...@gmail.com wrote:

 Sebastien, thanks for reviewing and approving the proposal. So, what
 do we need to do to make it in 1.5.9? Or did you already check it in
 there?

 Thanks,

 Alec

 On Thu, Nov 1, 2012 at 6:04 PM, Sebastien seb...@gmail.com wrote:
  Hi Alec,
 
  Thanks for having taking time to write the code snippet bellow, I better
  understand your idea!..
  I did not realized you didn't want to use getCssClass, but I think it is
  good solution anyway! It is easy for the user to replace
  message.isInfo() ? .my-ui-info : .my-ui-error
  by its custom method: getMessageCssClass(message.getLevel()) or something
  equivalent as we spoke before, so that's fine for me. Well done!
 
  Thanks again  best regards,
  Sebastien.
 
 
  On Thu, Nov 1, 2012 at 11:57 PM, Alec Swan alecs...@gmail.com wrote:
 
  @Sebastien The scenario you described it exactly the scenario I used
  to start this thread. Please read my original post.
 
  So, the solution is to change Wicket code
  FeedbackPanel.MessageListView#populateItem to use  AttributeAppender
  instead of AttributeModifier as I suggested in my previous message. In
  addition, your code should override newMessageDisplayComponent(..) as
  follows:
 
  protected Component newMessageDisplayComponent(String id,
  FeedbackMessage message) {
Component label = super.newMessageDisplayComponent(id, message);
label.add(new AttributeAppender(class, new
  ModelString(message.isInfo() ? .my-ui-info : .my-ui-error), 
  ));
return label;
  }
 
  This will set the style you want on span and will leave li
 unmodified.
 
  Why doesn't it work for you?
 
  Thanks,
 
  Alec
 
  On Thu, Nov 1, 2012 at 9:55 AM, Sebastien seb...@gmail.com wrote:
   Hi,
  
   @Alec, the use case is the following:
   Consider you are not the owner of the css-class(es). The css
 provider
  (a
   ui-framework, a designer, ...) will provide one style by message level
   (let's say .my-ui-warn, .my-ui-error, .my-ui-info, etc). So you will
   override #getCssClass in order to return the corresponding css-class
   depending of the level type (supplied as method's argument). But...
 the
   provided class/style is designed to be applied *only* to one element.
 So,
   if the css-class is applied onto both LI and SPAN, there will be a
 style
   overlap which will result to a bad display... As the
   message-level-css-class is *always* appended to both elements, there
 is
  yet
   no other choice (I think) to have our own FeedbackPanel or extending
 the
   existing one with the hack I provided earlier...
  
   @Sven: Thanks for your suggestion! It would result to a different
  component
   but it is certainly more relevant...
  
   Best regards,
   Sebastien.
  
  
   On Thu, Nov 1, 2012 at 4:17 PM, Sven Meier s...@meiers.net wrote:
  
   If you want to group messages you can easily use multiple feedback
  panels,
   each filtering by severity.
  
   Sven
  
   Sebastien seb...@gmail.com schrieb:
  
   Hi,
   
   @Alec, unfortunately I think your workaround does not handle the
 case
  we
   do
   *not* want the message-level-css-class on the SPAN, and that we
 still
  want
   it on the LI...
   
   @Sven, well if the refactoring is planned for Wicket 7 (a question
 will
   remain about doing something, backward compatible, for current
  versions),
   then it changes things...
   Then, I would maybe have a request about this refactored
  FeedbackPanel: I
   would like to be able to have/display messages grouped by levels (so
  each
   level is enclosed in its own container). That would simply mean that
  the
   UL
   will becomes a repeater. For instance, if this 'grouping option' is
 not
   activated, the repeater will iterate only once, with all feedback
  message
   of any level type. If it is activated, the repeater will iterate as
  many
   times as there is distinct message level types. And, last but not
  least,
   we
   should be able to apply the message-level-css-class to this repeater
  (and
   be able to *not* apply it to LI nor SPAN... so the loop is looped*).
   
   If you, dev-team, think this request is not relevant for
 wicket-core,
   please keep in mind this need while refactoring so you may provide
 the
   necessary/accessible things for the user wishing to *override*
   FeedbackPanel to achieve this goal...
   
   Thanks in advance  best regards,
   Sebastien
   
   (*) hazardous translation from French...
   
   
   On Wed, 

Re: Custom CSS for Feedback message is broken in 1.5

[Martin Grigorov]

I'll take care.

On Fri, Nov 2, 2012 at 5:59 PM, Sebastien seb...@gmail.com wrote:
 Hi Alec,

 If Sven or Martin agree with this solution for 1.5.9  6.3.0, I can attach
 the patch(es) to the opened ticket if needed. (but to replace a word by
 another, I am not sure my support will help that much! :) )

 I also think that we can keep this AttributeAppender even with the changes
 to be done for wicket7 (with the Martin's suggestion for instance). At
 least I do not see yet any potential issue / unexpected behavior that can
 happens, and we keep the advantage it provides...

 Best regards,
 Sebastien.

 On Fri, Nov 2, 2012 at 4:21 PM, Alec Swan alecs...@gmail.com wrote:

 Sebastien, thanks for reviewing and approving the proposal. So, what
 do we need to do to make it in 1.5.9? Or did you already check it in
 there?

 Thanks,

 Alec

 On Thu, Nov 1, 2012 at 6:04 PM, Sebastien seb...@gmail.com wrote:
  Hi Alec,
 
  Thanks for having taking time to write the code snippet bellow, I better
  understand your idea!..
  I did not realized you didn't want to use getCssClass, but I think it is
  good solution anyway! It is easy for the user to replace
  message.isInfo() ? .my-ui-info : .my-ui-error
  by its custom method: getMessageCssClass(message.getLevel()) or something
  equivalent as we spoke before, so that's fine for me. Well done!
 
  Thanks again  best regards,
  Sebastien.
 
 
  On Thu, Nov 1, 2012 at 11:57 PM, Alec Swan alecs...@gmail.com wrote:
 
  @Sebastien The scenario you described it exactly the scenario I used
  to start this thread. Please read my original post.
 
  So, the solution is to change Wicket code
  FeedbackPanel.MessageListView#populateItem to use  AttributeAppender
  instead of AttributeModifier as I suggested in my previous message. In
  addition, your code should override newMessageDisplayComponent(..) as
  follows:
 
  protected Component newMessageDisplayComponent(String id,
  FeedbackMessage message) {
Component label = super.newMessageDisplayComponent(id, message);
label.add(new AttributeAppender(class, new
  ModelString(message.isInfo() ? .my-ui-info : .my-ui-error), 
  ));
return label;
  }
 
  This will set the style you want on span and will leave li
 unmodified.
 
  Why doesn't it work for you?
 
  Thanks,
 
  Alec
 
  On Thu, Nov 1, 2012 at 9:55 AM, Sebastien seb...@gmail.com wrote:
   Hi,
  
   @Alec, the use case is the following:
   Consider you are not the owner of the css-class(es). The css
 provider
  (a
   ui-framework, a designer, ...) will provide one style by message level
   (let's say .my-ui-warn, .my-ui-error, .my-ui-info, etc). So you will
   override #getCssClass in order to return the corresponding css-class
   depending of the level type (supplied as method's argument). But...
 the
   provided class/style is designed to be applied *only* to one element.
 So,
   if the css-class is applied onto both LI and SPAN, there will be a
 style
   overlap which will result to a bad display... As the
   message-level-css-class is *always* appended to both elements, there
 is
  yet
   no other choice (I think) to have our own FeedbackPanel or extending
 the
   existing one with the hack I provided earlier...
  
   @Sven: Thanks for your suggestion! It would result to a different
  component
   but it is certainly more relevant...
  
   Best regards,
   Sebastien.
  
  
   On Thu, Nov 1, 2012 at 4:17 PM, Sven Meier s...@meiers.net wrote:
  
   If you want to group messages you can easily use multiple feedback
  panels,
   each filtering by severity.
  
   Sven
  
   Sebastien seb...@gmail.com schrieb:
  
   Hi,
   
   @Alec, unfortunately I think your workaround does not handle the
 case
  we
   do
   *not* want the message-level-css-class on the SPAN, and that we
 still
  want
   it on the LI...
   
   @Sven, well if the refactoring is planned for Wicket 7 (a question
 will
   remain about doing something, backward compatible, for current
  versions),
   then it changes things...
   Then, I would maybe have a request about this refactored
  FeedbackPanel: I
   would like to be able to have/display messages grouped by levels (so
  each
   level is enclosed in its own container). That would simply mean that
  the
   UL
   will becomes a repeater. For instance, if this 'grouping option' is
 not
   activated, the repeater will iterate only once, with all feedback
  message
   of any level type. If it is activated, the repeater will iterate as
  many
   times as there is distinct message level types. And, last but not
  least,
   we
   should be able to apply the message-level-css-class to this repeater
  (and
   be able to *not* apply it to LI nor SPAN... so the loop is looped*).
   
   If you, dev-team, think this request is not relevant for
 wicket-core,
   please keep in mind this need while refactoring so you may provide
 the
   necessary/accessible things for the user wishing to *override*
   FeedbackPanel to achieve this goal...
   
   Thanks in advance  

Re: Custom CSS for Feedback message is broken in 1.5

[Sebastien]

Great! Thanks Martin!

On Fri, Nov 2, 2012 at 5:01 PM, Martin Grigorov mgrigo...@apache.orgwrote:

 I'll take care.

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

Re: Custom CSS for Feedback message is broken in 1.5

[Martin Grigorov]

Done!

Please confirm that this is enough for now.

On Fri, Nov 2, 2012 at 7:01 PM, Sebastien seb...@gmail.com wrote:
 Great! Thanks Martin!

 On Fri, Nov 2, 2012 at 5:01 PM, Martin Grigorov mgrigo...@apache.orgwrote:

 I'll take care.

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




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

[Sebastien]

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 mgrigo...@apache.orgwrote:

 Done!

 Please confirm that this is enough for now.

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



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

[Sven Meier]

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 seb...@gmail.com 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 mgrigo...@apache.orgwrote:


Done!

Please confirm that this is enough for now.

On Fri, Nov 2, 2012 at 7:01 PM, Sebastien seb...@gmail.com 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 seb...@gmail.com wrote:

Hi Alec,

If Sven or Martin agree with this solution for 1.5.9  6.3.0, I can

attach

the patch(es) to the opened ticket if needed. (but to replace a word

by

another, I am not sure my support will help that much! :) )

I also think that we can keep this AttributeAppender even with the

changes

to be done for wicket7 (with the Martin's suggestion for instance). At
least I do not see yet any potential issue / unexpected behavior that

can

happens, and we keep the advantage it provides...

Best regards,
Sebastien.

On Fri, Nov 2, 2012 at 4:21 PM, Alec Swan alecs...@gmail.com wrote:


Sebastien, thanks for reviewing and approving the proposal. So, what
do we need to do to make it in 1.5.9? Or did you already check it in
there?

Thanks,

Alec

On Thu, Nov 1, 2012 at 6:04 PM, Sebastien seb...@gmail.com wrote:

Hi Alec,

Thanks for having taking time to write the code snippet bellow, I

better

understand your idea!..
I did not realized you didn't want to use getCssClass, but I think

it

is

good solution anyway! It is easy for the user to replace
message.isInfo() ? .my-ui-info : .my-ui-error
by its custom method: getMessageCssClass(message.getLevel()) or

something

equivalent as we spoke before, so that's fine for me. Well done!

Thanks again  best regards,
Sebastien.




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

[Sebastien]

Hi,

@Alec, unfortunately I think your workaround does not handle the case we do
*not* want the message-level-css-class on the SPAN, and that we still want
it on the LI...

@Sven, well if the refactoring is planned for Wicket 7 (a question will
remain about doing something, backward compatible, for current versions),
then it changes things...
Then, I would maybe have a request about this refactored FeedbackPanel: I
would like to be able to have/display messages grouped by levels (so each
level is enclosed in its own container). That would simply mean that the UL
will becomes a repeater. For instance, if this 'grouping option' is not
activated, the repeater will iterate only once, with all feedback message
of any level type. If it is activated, the repeater will iterate as many
times as there is distinct message level types. And, last but not least, we
should be able to apply the message-level-css-class to this repeater (and
be able to *not* apply it to LI nor SPAN... so the loop is looped*).

If you, dev-team, think this request is not relevant for wicket-core,
please keep in mind this need while refactoring so you may provide the
necessary/accessible things for the user wishing to *override*
FeedbackPanel to achieve this goal...

Thanks in advance  best regards,
Sebastien

(*) hazardous translation from French...


On Wed, Oct 31, 2012 at 11:37 PM, Alec Swan alecs...@gmail.com wrote:

 So, the patch can be applied to 1.5.8 and will replace
 label.add(levelModifier);
 with
 label.add(new AttributeAppender(class, replacementModel))

 You may want to add AttributeAppender to li as well.

 Alec

 On Wed, Oct 31, 2012 at 4:33 PM, Alec Swan alecs...@gmail.com wrote:
  I suggest that instead of overriding CSS class on the span you
  APPEND it to existing CSS classes. This will allow the user to specify
  their own span CSS class in newMessageDisplayComponent(..) AND will
  support backward compatibility.
 
  Sounds like a win-win to me. Thoughts?
 
  Thanks,
 
  Alec
 
  On Wed, Oct 31, 2012 at 1:17 AM, Sven Meier s...@meiers.net wrote:
  Hi,
 
  the CSS class could be changed in Wicket 7 only. Until you've migrated
 you
  can easily just use your own feedback component.
 
  Best regards
  Sven
 
 
  On 10/30/2012 11:24 PM, Sebastien wrote:
 
  Hi,
 
  I also agree with Martin's points. Having no css-class on the span is
 the
  best solution from my point of view too.
  A little concern however. I think this kind of change is not exactly
  backward compatible. Sure, it is, for the java side, but I figure
 that
  *many* users have wrote their own CSS for feedback panels and this will
  probably results to bad display with this change. So, I am wondering if
  this change will be considered as an API break? If yes, will you
 apply
  it
  also to 1.5.x (the original demand)? And, if the new version numbering
  system in place applies to 1.5.x, does that means that it should be
 1.6.0?
  You see what I mean... it could lead to some misunderstanding!..
 
  Also I like Sven's suggestion, but I am afraid that it will overlap
 with
  #newMessageDisplayComponent(). As ListItem IS-A WebMarkupContainer, we
  could do any customization from here. But, in this case (there is a new
  #newMessageItem() method), the span element is not needed anymore and
  therefore #newMessageDisplayComponent() neither. So, about the API
 break,
  we are in situation :)
 
  Thanks  best regards,
  Sebastien.
 
 
  On Mon, Oct 29, 2012 at 6:18 PM, Joachim Schrod jsch...@acm.org
 wrote:
 
  Hi,
 
  This would change be very well received, from my side. :-) :-)
 
  Cheers,
   Joachim
 
 
  Martin Grigorov wrote:
 
  Hi,
 
  [X] Other suggestion: (please specify)
 
  Here is what I think it should be:
  - div element should have class feedbackPanel (this is already
 the
 
  case)
 
  - li element(s) should have class that specifies the feedback
  message level (currently by default Wicket sets feedbackPanelLEVEL,
  but this is configurable with
 
 
 
 org.apache.wicket.markup.html.panel.FeedbackPanel#getCSSClass(FeedbackMessage))
 
  - the span should not have class at all (currently it has the same
  class as the li element)
  - the styling should be done with CSS selectors (e.g.
  div.feedbackPanel; div.feedbackPanel li.alert-warn; div.feedbackPanel
  li.alert-warn span; ...)
  - if custom markup is needed then a custom FeedbackPanel is needed
  (one that extends from the default FeedbackPanel or a completely new
  one, it depends on the use case)
 
 
  On Sun, Oct 28, 2012 at 6:03 PM, Sebastien seb...@gmail.com wrote:
 
  Hi,
 
  To sum-up this thread: we have a (not huge, but still) design issue
  that
  annoys several users. A patch* has been provided but some questions
  remains...
  Given this, I would suggest a kind-of vote about the several points
  discussed earlier, in order to enlighten the dev-team about the
 
  preferred
 
  choice of their (beloved) users.**
 
  Here are some possible options:
  [ ] Please apply the patch 

Re: Custom CSS for Feedback message is broken in 1.5

[Alec Swan]

@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 seb...@gmail.com 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 alecs...@gmail.com wrote:

 So, the patch can be applied to 1.5.8 and will replace
 label.add(levelModifier);
 with
 label.add(new AttributeAppender(class, replacementModel))

 You may want to add AttributeAppender to li as well.

 Alec

 On Wed, Oct 31, 2012 at 4:33 PM, Alec Swan alecs...@gmail.com wrote:
  I suggest that instead of overriding CSS class on the span you
  APPEND it to existing CSS classes. This will allow the user to specify
  their own span CSS class in newMessageDisplayComponent(..) AND will
  support backward compatibility.
 
  Sounds like a win-win to me. Thoughts?
 
  Thanks,
 
  Alec
 
  On Wed, Oct 31, 2012 at 1:17 AM, Sven Meier s...@meiers.net wrote:
  Hi,
 
  the CSS class could be changed in Wicket 7 only. Until you've migrated
 you
  can easily just use your own feedback component.
 
  Best regards
  Sven
 
 
  On 10/30/2012 11:24 PM, Sebastien wrote:
 
  Hi,
 
  I also agree with Martin's points. Having no css-class on the span is
 the
  best solution from my point of view too.
  A little concern however. I think this kind of change is not exactly
  backward compatible. Sure, it is, for the java side, but I figure
 that
  *many* users have wrote their own CSS for feedback panels and this will
  probably results to bad display with this change. So, I am wondering if
  this change will be considered as an API break? If yes, will you
 apply
  it
  also to 1.5.x (the original demand)? And, if the new version numbering
  system in place applies to 1.5.x, does that means that it should be
 1.6.0?
  You see what I mean... it could lead to some misunderstanding!..
 
  Also I like Sven's suggestion, but I am afraid that it will overlap
 with
  #newMessageDisplayComponent(). As ListItem IS-A WebMarkupContainer, we
  could do any customization from here. But, in this case (there is a new
  #newMessageItem() method), the span element is not needed anymore and
  therefore #newMessageDisplayComponent() neither. So, about the API
 break,
  we are in situation :)
 
  Thanks  best regards,
  Sebastien.
 
 
  On Mon, Oct 29, 2012 at 6:18 PM, Joachim Schrod jsch...@acm.org
 wrote:
 
  Hi,
 
  This would change be very well received, from my side. :-) :-)
 
  Cheers,
   Joachim
 
 
  Martin Grigorov wrote:
 
  Hi,
 
  [X] Other suggestion: (please specify)
 
  Here is what I think it should be:
  - div element should have class feedbackPanel (this is already
 the
 
  case)
 
  - li element(s) should have class that specifies the feedback
  message level (currently by default Wicket sets feedbackPanelLEVEL,
  but this is configurable with
 
 
 
 org.apache.wicket.markup.html.panel.FeedbackPanel#getCSSClass(FeedbackMessage))
 
  - the span should not have class at all (currently it has the same
  class as the li element)
  - the styling should be done with CSS selectors (e.g.
  div.feedbackPanel; div.feedbackPanel li.alert-warn; div.feedbackPanel
  li.alert-warn span; ...)
  - if custom markup is needed then a custom FeedbackPanel is needed
  (one that extends from the default FeedbackPanel or a completely new
  one, it depends on the use case)

Re: Custom CSS for Feedback message is broken in 1.5

[Sven Meier]

If you want to group messages you can easily use multiple feedback panels, each 
filtering by severity.

Sven

Sebastien seb...@gmail.com schrieb:

Hi,

@Alec, unfortunately I think your workaround does not handle the case we do
*not* want the message-level-css-class on the SPAN, and that we still want
it on the LI...

@Sven, well if the refactoring is planned for Wicket 7 (a question will
remain about doing something, backward compatible, for current versions),
then it changes things...
Then, I would maybe have a request about this refactored FeedbackPanel: I
would like to be able to have/display messages grouped by levels (so each
level is enclosed in its own container). That would simply mean that the UL
will becomes a repeater. For instance, if this 'grouping option' is not
activated, the repeater will iterate only once, with all feedback message
of any level type. If it is activated, the repeater will iterate as many
times as there is distinct message level types. And, last but not least, we
should be able to apply the message-level-css-class to this repeater (and
be able to *not* apply it to LI nor SPAN... so the loop is looped*).

If you, dev-team, think this request is not relevant for wicket-core,
please keep in mind this need while refactoring so you may provide the
necessary/accessible things for the user wishing to *override*
FeedbackPanel to achieve this goal...

Thanks in advance  best regards,
Sebastien

(*) hazardous translation from French...


On Wed, Oct 31, 2012 at 11:37 PM, Alec Swan alecs...@gmail.com wrote:

 So, the patch can be applied to 1.5.8 and will replace
 label.add(levelModifier);
 with
 label.add(new AttributeAppender(class, replacementModel))

 You may want to add AttributeAppender to li as well.

 Alec

 On Wed, Oct 31, 2012 at 4:33 PM, Alec Swan alecs...@gmail.com wrote:
  I suggest that instead of overriding CSS class on the span you
  APPEND it to existing CSS classes. This will allow the user to specify
  their own span CSS class in newMessageDisplayComponent(..) AND will
  support backward compatibility.
 
  Sounds like a win-win to me. Thoughts?
 
  Thanks,
 
  Alec
 
  On Wed, Oct 31, 2012 at 1:17 AM, Sven Meier s...@meiers.net wrote:
  Hi,
 
  the CSS class could be changed in Wicket 7 only. Until you've migrated
 you
  can easily just use your own feedback component.
 
  Best regards
  Sven
 
 
  On 10/30/2012 11:24 PM, Sebastien wrote:
 
  Hi,
 
  I also agree with Martin's points. Having no css-class on the span is
 the
  best solution from my point of view too.
  A little concern however. I think this kind of change is not exactly
  backward compatible. Sure, it is, for the java side, but I figure
 that
  *many* users have wrote their own CSS for feedback panels and this will
  probably results to bad display with this change. So, I am wondering if
  this change will be considered as an API break? If yes, will you
 apply
  it
  also to 1.5.x (the original demand)? And, if the new version numbering
  system in place applies to 1.5.x, does that means that it should be
 1.6.0?
  You see what I mean... it could lead to some misunderstanding!..
 
  Also I like Sven's suggestion, but I am afraid that it will overlap
 with
  #newMessageDisplayComponent(). As ListItem IS-A WebMarkupContainer, we
  could do any customization from here. But, in this case (there is a new
  #newMessageItem() method), the span element is not needed anymore and
  therefore #newMessageDisplayComponent() neither. So, about the API
 break,
  we are in situation :)
 
  Thanks  best regards,
  Sebastien.
 
 
  On Mon, Oct 29, 2012 at 6:18 PM, Joachim Schrod jsch...@acm.org
 wrote:
 
  Hi,
 
  This would change be very well received, from my side. :-) :-)
 
  Cheers,
   Joachim
 
 
  Martin Grigorov wrote:
 
  Hi,
 
  [X] Other suggestion: (please specify)
 
  Here is what I think it should be:
  - div element should have class feedbackPanel (this is already
 the
 
  case)
 
  - li element(s) should have class that specifies the feedback
  message level (currently by default Wicket sets feedbackPanelLEVEL,
  but this is configurable with
 
 
 
 org.apache.wicket.markup.html.panel.FeedbackPanel#getCSSClass(FeedbackMessage))
 
  - the span should not have class at all (currently it has the same
  class as the li element)
  - the styling should be done with CSS selectors (e.g.
  div.feedbackPanel; div.feedbackPanel li.alert-warn; div.feedbackPanel
  li.alert-warn span; ...)
  - if custom markup is needed then a custom FeedbackPanel is needed
  (one that extends from the default FeedbackPanel or a completely new
  one, it depends on the use case)
 
 
  On Sun, Oct 28, 2012 at 6:03 PM, Sebastien seb...@gmail.com wrote:
 
  Hi,
 
  To sum-up this thread: we have a (not huge, but still) design issue
  that
  annoys several users. A patch* has been provided but some questions
  remains...
  Given this, I would suggest a kind-of vote about the several points
  discussed earlier, in order to 

Re: Custom CSS for Feedback message is broken in 1.5

[Sebastien]

Hi,

@Alec, the use case is the following:
Consider you are not the owner of the css-class(es). The css provider (a
ui-framework, a designer, ...) will provide one style by message level
(let's say .my-ui-warn, .my-ui-error, .my-ui-info, etc). So you will
override #getCssClass in order to return the corresponding css-class
depending of the level type (supplied as method's argument). But... the
provided class/style is designed to be applied *only* to one element. So,
if the css-class is applied onto both LI and SPAN, there will be a style
overlap which will result to a bad display... As the
message-level-css-class is *always* appended to both elements, there is yet
no other choice (I think) to have our own FeedbackPanel or extending the
existing one with the hack I provided earlier...

@Sven: Thanks for your suggestion! It would result to a different component
but it is certainly more relevant...

Best regards,
Sebastien.


On Thu, Nov 1, 2012 at 4:17 PM, Sven Meier s...@meiers.net wrote:

 If you want to group messages you can easily use multiple feedback panels,
 each filtering by severity.

 Sven

 Sebastien seb...@gmail.com schrieb:

 Hi,
 
 @Alec, unfortunately I think your workaround does not handle the case we
 do
 *not* want the message-level-css-class on the SPAN, and that we still want
 it on the LI...
 
 @Sven, well if the refactoring is planned for Wicket 7 (a question will
 remain about doing something, backward compatible, for current versions),
 then it changes things...
 Then, I would maybe have a request about this refactored FeedbackPanel: I
 would like to be able to have/display messages grouped by levels (so each
 level is enclosed in its own container). That would simply mean that the
 UL
 will becomes a repeater. For instance, if this 'grouping option' is not
 activated, the repeater will iterate only once, with all feedback message
 of any level type. If it is activated, the repeater will iterate as many
 times as there is distinct message level types. And, last but not least,
 we
 should be able to apply the message-level-css-class to this repeater (and
 be able to *not* apply it to LI nor SPAN... so the loop is looped*).
 
 If you, dev-team, think this request is not relevant for wicket-core,
 please keep in mind this need while refactoring so you may provide the
 necessary/accessible things for the user wishing to *override*
 FeedbackPanel to achieve this goal...
 
 Thanks in advance  best regards,
 Sebastien
 
 (*) hazardous translation from French...
 
 
 On Wed, Oct 31, 2012 at 11:37 PM, Alec Swan alecs...@gmail.com wrote:
 
  So, the patch can be applied to 1.5.8 and will replace
  label.add(levelModifier);
  with
  label.add(new AttributeAppender(class, replacementModel))
 
  You may want to add AttributeAppender to li as well.
 
  Alec
 
  On Wed, Oct 31, 2012 at 4:33 PM, Alec Swan alecs...@gmail.com wrote:
   I suggest that instead of overriding CSS class on the span you
   APPEND it to existing CSS classes. This will allow the user to specify
   their own span CSS class in newMessageDisplayComponent(..) AND will
   support backward compatibility.
  
   Sounds like a win-win to me. Thoughts?
  
   Thanks,
  
   Alec
  
   On Wed, Oct 31, 2012 at 1:17 AM, Sven Meier s...@meiers.net wrote:
   Hi,
  
   the CSS class could be changed in Wicket 7 only. Until you've
 migrated
  you
   can easily just use your own feedback component.
  
   Best regards
   Sven
  
  
   On 10/30/2012 11:24 PM, Sebastien wrote:
  
   Hi,
  
   I also agree with Martin's points. Having no css-class on the span
 is
  the
   best solution from my point of view too.
   A little concern however. I think this kind of change is not exactly
   backward compatible. Sure, it is, for the java side, but I figure
  that
   *many* users have wrote their own CSS for feedback panels and this
 will
   probably results to bad display with this change. So, I am
 wondering if
   this change will be considered as an API break? If yes, will you
  apply
   it
   also to 1.5.x (the original demand)? And, if the new version
 numbering
   system in place applies to 1.5.x, does that means that it should be
  1.6.0?
   You see what I mean... it could lead to some misunderstanding!..
  
   Also I like Sven's suggestion, but I am afraid that it will overlap
  with
   #newMessageDisplayComponent(). As ListItem IS-A WebMarkupContainer,
 we
   could do any customization from here. But, in this case (there is a
 new
   #newMessageItem() method), the span element is not needed anymore
 and
   therefore #newMessageDisplayComponent() neither. So, about the API
  break,
   we are in situation :)
  
   Thanks  best regards,
   Sebastien.
  
  
   On Mon, Oct 29, 2012 at 6:18 PM, Joachim Schrod jsch...@acm.org
  wrote:
  
   Hi,
  
   This would change be very well received, from my side. :-) :-)
  
   Cheers,
Joachim
  
  
   Martin Grigorov wrote:
  
   Hi,
  
   [X] Other suggestion: (please specify)
  
   Here is what I 

Re: Custom CSS for Feedback message is broken in 1.5

[Alec Swan]

@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
ModelString(message.isInfo() ? .my-ui-info : .my-ui-error), 
));
  return label;
}

This will set the style you want on span and will leave li unmodified.

Why doesn't it work for you?

Thanks,

Alec

On Thu, Nov 1, 2012 at 9:55 AM, Sebastien seb...@gmail.com wrote:
 Hi,

 @Alec, the use case is the following:
 Consider you are not the owner of the css-class(es). The css provider (a
 ui-framework, a designer, ...) will provide one style by message level
 (let's say .my-ui-warn, .my-ui-error, .my-ui-info, etc). So you will
 override #getCssClass in order to return the corresponding css-class
 depending of the level type (supplied as method's argument). But... the
 provided class/style is designed to be applied *only* to one element. So,
 if the css-class is applied onto both LI and SPAN, there will be a style
 overlap which will result to a bad display... As the
 message-level-css-class is *always* appended to both elements, there is yet
 no other choice (I think) to have our own FeedbackPanel or extending the
 existing one with the hack I provided earlier...

 @Sven: Thanks for your suggestion! It would result to a different component
 but it is certainly more relevant...

 Best regards,
 Sebastien.


 On Thu, Nov 1, 2012 at 4:17 PM, Sven Meier s...@meiers.net wrote:

 If you want to group messages you can easily use multiple feedback panels,
 each filtering by severity.

 Sven

 Sebastien seb...@gmail.com schrieb:

 Hi,
 
 @Alec, unfortunately I think your workaround does not handle the case we
 do
 *not* want the message-level-css-class on the SPAN, and that we still want
 it on the LI...
 
 @Sven, well if the refactoring is planned for Wicket 7 (a question will
 remain about doing something, backward compatible, for current versions),
 then it changes things...
 Then, I would maybe have a request about this refactored FeedbackPanel: I
 would like to be able to have/display messages grouped by levels (so each
 level is enclosed in its own container). That would simply mean that the
 UL
 will becomes a repeater. For instance, if this 'grouping option' is not
 activated, the repeater will iterate only once, with all feedback message
 of any level type. If it is activated, the repeater will iterate as many
 times as there is distinct message level types. And, last but not least,
 we
 should be able to apply the message-level-css-class to this repeater (and
 be able to *not* apply it to LI nor SPAN... so the loop is looped*).
 
 If you, dev-team, think this request is not relevant for wicket-core,
 please keep in mind this need while refactoring so you may provide the
 necessary/accessible things for the user wishing to *override*
 FeedbackPanel to achieve this goal...
 
 Thanks in advance  best regards,
 Sebastien
 
 (*) hazardous translation from French...
 
 
 On Wed, Oct 31, 2012 at 11:37 PM, Alec Swan alecs...@gmail.com wrote:
 
  So, the patch can be applied to 1.5.8 and will replace
  label.add(levelModifier);
  with
  label.add(new AttributeAppender(class, replacementModel))
 
  You may want to add AttributeAppender to li as well.
 
  Alec
 
  On Wed, Oct 31, 2012 at 4:33 PM, Alec Swan alecs...@gmail.com wrote:
   I suggest that instead of overriding CSS class on the span you
   APPEND it to existing CSS classes. This will allow the user to specify
   their own span CSS class in newMessageDisplayComponent(..) AND will
   support backward compatibility.
  
   Sounds like a win-win to me. Thoughts?
  
   Thanks,
  
   Alec
  
   On Wed, Oct 31, 2012 at 1:17 AM, Sven Meier s...@meiers.net wrote:
   Hi,
  
   the CSS class could be changed in Wicket 7 only. Until you've
 migrated
  you
   can easily just use your own feedback component.
  
   Best regards
   Sven
  
  
   On 10/30/2012 11:24 PM, Sebastien wrote:
  
   Hi,
  
   I also agree with Martin's points. Having no css-class on the span
 is
  the
   best solution from my point of view too.
   A little concern however. I think this kind of change is not exactly
   backward compatible. Sure, it is, for the java side, but I figure
  that
   *many* users have wrote their own CSS for feedback panels and this
 will
   probably results to bad display with this change. So, I am
 wondering if
   this change will be considered as an API break? If yes, will you
  apply
   it
   also to 1.5.x (the original demand)? And, if the new version
 numbering
   system in place applies to 1.5.x, 

Re: Custom CSS for Feedback message is broken in 1.5

[Sebastien]

Hi Alec,

Thanks for having taking time to write the code snippet bellow, I better
understand your idea!..
I did not realized you didn't want to use getCssClass, but I think it is
good solution anyway! It is easy for the user to replace
message.isInfo() ? .my-ui-info : .my-ui-error
by its custom method: getMessageCssClass(message.getLevel()) or something
equivalent as we spoke before, so that's fine for me. Well done!

Thanks again  best regards,
Sebastien.


On Thu, Nov 1, 2012 at 11:57 PM, Alec Swan alecs...@gmail.com wrote:

 @Sebastien The scenario you described it exactly the scenario I used
 to start this thread. Please read my original post.

 So, the solution is to change Wicket code
 FeedbackPanel.MessageListView#populateItem to use  AttributeAppender
 instead of AttributeModifier as I suggested in my previous message. In
 addition, your code should override newMessageDisplayComponent(..) as
 follows:

 protected Component newMessageDisplayComponent(String id,
 FeedbackMessage message) {
   Component label = super.newMessageDisplayComponent(id, message);
   label.add(new AttributeAppender(class, new
 ModelString(message.isInfo() ? .my-ui-info : .my-ui-error), 
 ));
   return label;
 }

 This will set the style you want on span and will leave li unmodified.

 Why doesn't it work for you?

 Thanks,

 Alec

 On Thu, Nov 1, 2012 at 9:55 AM, Sebastien seb...@gmail.com wrote:
  Hi,
 
  @Alec, the use case is the following:
  Consider you are not the owner of the css-class(es). The css provider
 (a
  ui-framework, a designer, ...) will provide one style by message level
  (let's say .my-ui-warn, .my-ui-error, .my-ui-info, etc). So you will
  override #getCssClass in order to return the corresponding css-class
  depending of the level type (supplied as method's argument). But... the
  provided class/style is designed to be applied *only* to one element. So,
  if the css-class is applied onto both LI and SPAN, there will be a style
  overlap which will result to a bad display... As the
  message-level-css-class is *always* appended to both elements, there is
 yet
  no other choice (I think) to have our own FeedbackPanel or extending the
  existing one with the hack I provided earlier...
 
  @Sven: Thanks for your suggestion! It would result to a different
 component
  but it is certainly more relevant...
 
  Best regards,
  Sebastien.
 
 
  On Thu, Nov 1, 2012 at 4:17 PM, Sven Meier s...@meiers.net wrote:
 
  If you want to group messages you can easily use multiple feedback
 panels,
  each filtering by severity.
 
  Sven
 
  Sebastien seb...@gmail.com schrieb:
 
  Hi,
  
  @Alec, unfortunately I think your workaround does not handle the case
 we
  do
  *not* want the message-level-css-class on the SPAN, and that we still
 want
  it on the LI...
  
  @Sven, well if the refactoring is planned for Wicket 7 (a question will
  remain about doing something, backward compatible, for current
 versions),
  then it changes things...
  Then, I would maybe have a request about this refactored
 FeedbackPanel: I
  would like to be able to have/display messages grouped by levels (so
 each
  level is enclosed in its own container). That would simply mean that
 the
  UL
  will becomes a repeater. For instance, if this 'grouping option' is not
  activated, the repeater will iterate only once, with all feedback
 message
  of any level type. If it is activated, the repeater will iterate as
 many
  times as there is distinct message level types. And, last but not
 least,
  we
  should be able to apply the message-level-css-class to this repeater
 (and
  be able to *not* apply it to LI nor SPAN... so the loop is looped*).
  
  If you, dev-team, think this request is not relevant for wicket-core,
  please keep in mind this need while refactoring so you may provide the
  necessary/accessible things for the user wishing to *override*
  FeedbackPanel to achieve this goal...
  
  Thanks in advance  best regards,
  Sebastien
  
  (*) hazardous translation from French...
  
  
  On Wed, Oct 31, 2012 at 11:37 PM, Alec Swan alecs...@gmail.com
 wrote:
  
   So, the patch can be applied to 1.5.8 and will replace
   label.add(levelModifier);
   with
   label.add(new AttributeAppender(class, replacementModel))
  
   You may want to add AttributeAppender to li as well.
  
   Alec
  
   On Wed, Oct 31, 2012 at 4:33 PM, Alec Swan alecs...@gmail.com
 wrote:
I suggest that instead of overriding CSS class on the span you
APPEND it to existing CSS classes. This will allow the user to
 specify
their own span CSS class in newMessageDisplayComponent(..) AND
 will
support backward compatibility.
   
Sounds like a win-win to me. Thoughts?
   
Thanks,
   
Alec
   
On Wed, Oct 31, 2012 at 1:17 AM, Sven Meier s...@meiers.net
 wrote:
Hi,
   
the CSS class could be changed in Wicket 7 only. Until you've
  migrated
   you
can easily just use your own feedback component.
   
Best regards
Sven
   
   

Re: Custom CSS for Feedback message is broken in 1.5

[Sven Meier]

Hi,

the CSS class could be changed in Wicket 7 only. Until you've migrated 
you can easily just use your own feedback component.


Best regards
Sven

On 10/30/2012 11:24 PM, Sebastien wrote:

Hi,

I also agree with Martin's points. Having no css-class on the span is the
best solution from my point of view too.
A little concern however. I think this kind of change is not exactly
backward compatible. Sure, it is, for the java side, but I figure that
*many* users have wrote their own CSS for feedback panels and this will
probably results to bad display with this change. So, I am wondering if
this change will be considered as an API break? If yes, will you apply it
also to 1.5.x (the original demand)? And, if the new version numbering
system in place applies to 1.5.x, does that means that it should be 1.6.0?
You see what I mean... it could lead to some misunderstanding!..

Also I like Sven's suggestion, but I am afraid that it will overlap with
#newMessageDisplayComponent(). As ListItem IS-A WebMarkupContainer, we
could do any customization from here. But, in this case (there is a new
#newMessageItem() method), the span element is not needed anymore and
therefore #newMessageDisplayComponent() neither. So, about the API break,
we are in situation :)

Thanks  best regards,
Sebastien.


On Mon, Oct 29, 2012 at 6:18 PM, Joachim Schrod jsch...@acm.org wrote:


Hi,

This would change be very well received, from my side. :-) :-)

Cheers,
 Joachim


Martin Grigorov wrote:

Hi,

[X] Other suggestion: (please specify)

Here is what I think it should be:
- div element should have class feedbackPanel (this is already the

case)

- li element(s) should have class that specifies the feedback
message level (currently by default Wicket sets feedbackPanelLEVEL,
but this is configurable with


org.apache.wicket.markup.html.panel.FeedbackPanel#getCSSClass(FeedbackMessage))

- the span should not have class at all (currently it has the same
class as the li element)
- the styling should be done with CSS selectors (e.g.
div.feedbackPanel; div.feedbackPanel li.alert-warn; div.feedbackPanel
li.alert-warn span; ...)
- if custom markup is needed then a custom FeedbackPanel is needed
(one that extends from the default FeedbackPanel or a completely new
one, it depends on the use case)


On Sun, Oct 28, 2012 at 6:03 PM, Sebastien seb...@gmail.com wrote:

Hi,

To sum-up this thread: we have a (not huge, but still) design issue that
annoys several users. A patch* has been provided but some questions
remains...
Given this, I would suggest a kind-of vote about the several points
discussed earlier, in order to enlighten the dev-team about the

preferred

choice of their (beloved) users.**

Here are some possible options:
[ ] Please apply the patch as-is. It currently provides 2 methods
(#getListCSSClass and #getLabelCSSClass), #getCSSClass is marked a
deprecated until marked as private (or removed)
[ ] Do not apply the patch as-is, #getCSSClass should be kept (not

marked

as deprecated)
[ ] Do not apply the patch as-is, I do not agree with the 2 method

names. I

would have preferred: (please specify)
[ ] This is not an issue; this does not need to be corrected
[ ] Other suggestion: (please specify)

Thanks in advance for your contribution,
Sebastien

(*) https://issues.apache.org/jira/browse/WICKET-4831
(**) Sure, dev-team opinion is also kindly asked! :)






 Joachim

--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Joachim Schrod, Roedermark, Germany
Email: jsch...@acm.org


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org





-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Custom CSS for Feedback message is broken in 1.5

[Alec Swan]

I suggest that instead of overriding CSS class on the span you
APPEND it to existing CSS classes. This will allow the user to specify
their own span CSS class in newMessageDisplayComponent(..) AND will
support backward compatibility.

Sounds like a win-win to me. Thoughts?

Thanks,

Alec

On Wed, Oct 31, 2012 at 1:17 AM, Sven Meier s...@meiers.net wrote:
 Hi,

 the CSS class could be changed in Wicket 7 only. Until you've migrated you
 can easily just use your own feedback component.

 Best regards
 Sven


 On 10/30/2012 11:24 PM, Sebastien wrote:

 Hi,

 I also agree with Martin's points. Having no css-class on the span is the
 best solution from my point of view too.
 A little concern however. I think this kind of change is not exactly
 backward compatible. Sure, it is, for the java side, but I figure that
 *many* users have wrote their own CSS for feedback panels and this will
 probably results to bad display with this change. So, I am wondering if
 this change will be considered as an API break? If yes, will you apply
 it
 also to 1.5.x (the original demand)? And, if the new version numbering
 system in place applies to 1.5.x, does that means that it should be 1.6.0?
 You see what I mean... it could lead to some misunderstanding!..

 Also I like Sven's suggestion, but I am afraid that it will overlap with
 #newMessageDisplayComponent(). As ListItem IS-A WebMarkupContainer, we
 could do any customization from here. But, in this case (there is a new
 #newMessageItem() method), the span element is not needed anymore and
 therefore #newMessageDisplayComponent() neither. So, about the API break,
 we are in situation :)

 Thanks  best regards,
 Sebastien.


 On Mon, Oct 29, 2012 at 6:18 PM, Joachim Schrod jsch...@acm.org wrote:

 Hi,

 This would change be very well received, from my side. :-) :-)

 Cheers,
  Joachim


 Martin Grigorov wrote:

 Hi,

 [X] Other suggestion: (please specify)

 Here is what I think it should be:
 - div element should have class feedbackPanel (this is already the

 case)

 - li element(s) should have class that specifies the feedback
 message level (currently by default Wicket sets feedbackPanelLEVEL,
 but this is configurable with


 org.apache.wicket.markup.html.panel.FeedbackPanel#getCSSClass(FeedbackMessage))

 - the span should not have class at all (currently it has the same
 class as the li element)
 - the styling should be done with CSS selectors (e.g.
 div.feedbackPanel; div.feedbackPanel li.alert-warn; div.feedbackPanel
 li.alert-warn span; ...)
 - if custom markup is needed then a custom FeedbackPanel is needed
 (one that extends from the default FeedbackPanel or a completely new
 one, it depends on the use case)


 On Sun, Oct 28, 2012 at 6:03 PM, Sebastien seb...@gmail.com wrote:

 Hi,

 To sum-up this thread: we have a (not huge, but still) design issue
 that
 annoys several users. A patch* has been provided but some questions
 remains...
 Given this, I would suggest a kind-of vote about the several points
 discussed earlier, in order to enlighten the dev-team about the

 preferred

 choice of their (beloved) users.**

 Here are some possible options:
 [ ] Please apply the patch as-is. It currently provides 2 methods
 (#getListCSSClass and #getLabelCSSClass), #getCSSClass is marked a
 deprecated until marked as private (or removed)
 [ ] Do not apply the patch as-is, #getCSSClass should be kept (not

 marked

 as deprecated)
 [ ] Do not apply the patch as-is, I do not agree with the 2 method

 names. I

 would have preferred: (please specify)
 [ ] This is not an issue; this does not need to be corrected
 [ ] Other suggestion: (please specify)

 Thanks in advance for your contribution,
 Sebastien

 (*) https://issues.apache.org/jira/browse/WICKET-4831
 (**) Sure, dev-team opinion is also kindly asked! :)





  Joachim

 --
 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
 Joachim Schrod, Roedermark, Germany
 Email: jsch...@acm.org


 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org




 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Custom CSS for Feedback message is broken in 1.5

[Alec Swan]

So, the patch can be applied to 1.5.8 and will replace
label.add(levelModifier);
with
label.add(new AttributeAppender(class, replacementModel))

You may want to add AttributeAppender to li as well.

Alec

On Wed, Oct 31, 2012 at 4:33 PM, Alec Swan alecs...@gmail.com wrote:
 I suggest that instead of overriding CSS class on the span you
 APPEND it to existing CSS classes. This will allow the user to specify
 their own span CSS class in newMessageDisplayComponent(..) AND will
 support backward compatibility.

 Sounds like a win-win to me. Thoughts?

 Thanks,

 Alec

 On Wed, Oct 31, 2012 at 1:17 AM, Sven Meier s...@meiers.net wrote:
 Hi,

 the CSS class could be changed in Wicket 7 only. Until you've migrated you
 can easily just use your own feedback component.

 Best regards
 Sven


 On 10/30/2012 11:24 PM, Sebastien wrote:

 Hi,

 I also agree with Martin's points. Having no css-class on the span is the
 best solution from my point of view too.
 A little concern however. I think this kind of change is not exactly
 backward compatible. Sure, it is, for the java side, but I figure that
 *many* users have wrote their own CSS for feedback panels and this will
 probably results to bad display with this change. So, I am wondering if
 this change will be considered as an API break? If yes, will you apply
 it
 also to 1.5.x (the original demand)? And, if the new version numbering
 system in place applies to 1.5.x, does that means that it should be 1.6.0?
 You see what I mean... it could lead to some misunderstanding!..

 Also I like Sven's suggestion, but I am afraid that it will overlap with
 #newMessageDisplayComponent(). As ListItem IS-A WebMarkupContainer, we
 could do any customization from here. But, in this case (there is a new
 #newMessageItem() method), the span element is not needed anymore and
 therefore #newMessageDisplayComponent() neither. So, about the API break,
 we are in situation :)

 Thanks  best regards,
 Sebastien.


 On Mon, Oct 29, 2012 at 6:18 PM, Joachim Schrod jsch...@acm.org wrote:

 Hi,

 This would change be very well received, from my side. :-) :-)

 Cheers,
  Joachim


 Martin Grigorov wrote:

 Hi,

 [X] Other suggestion: (please specify)

 Here is what I think it should be:
 - div element should have class feedbackPanel (this is already the

 case)

 - li element(s) should have class that specifies the feedback
 message level (currently by default Wicket sets feedbackPanelLEVEL,
 but this is configurable with


 org.apache.wicket.markup.html.panel.FeedbackPanel#getCSSClass(FeedbackMessage))

 - the span should not have class at all (currently it has the same
 class as the li element)
 - the styling should be done with CSS selectors (e.g.
 div.feedbackPanel; div.feedbackPanel li.alert-warn; div.feedbackPanel
 li.alert-warn span; ...)
 - if custom markup is needed then a custom FeedbackPanel is needed
 (one that extends from the default FeedbackPanel or a completely new
 one, it depends on the use case)


 On Sun, Oct 28, 2012 at 6:03 PM, Sebastien seb...@gmail.com wrote:

 Hi,

 To sum-up this thread: we have a (not huge, but still) design issue
 that
 annoys several users. A patch* has been provided but some questions
 remains...
 Given this, I would suggest a kind-of vote about the several points
 discussed earlier, in order to enlighten the dev-team about the

 preferred

 choice of their (beloved) users.**

 Here are some possible options:
 [ ] Please apply the patch as-is. It currently provides 2 methods
 (#getListCSSClass and #getLabelCSSClass), #getCSSClass is marked a
 deprecated until marked as private (or removed)
 [ ] Do not apply the patch as-is, #getCSSClass should be kept (not

 marked

 as deprecated)
 [ ] Do not apply the patch as-is, I do not agree with the 2 method

 names. I

 would have preferred: (please specify)
 [ ] This is not an issue; this does not need to be corrected
 [ ] Other suggestion: (please specify)

 Thanks in advance for your contribution,
 Sebastien

 (*) https://issues.apache.org/jira/browse/WICKET-4831
 (**) Sure, dev-team opinion is also kindly asked! :)





  Joachim

 --
 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
 Joachim Schrod, Roedermark, Germany
 Email: jsch...@acm.org


 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org




 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Custom CSS for Feedback message is broken in 1.5

[Sebastien]

Hi,

I also agree with Martin's points. Having no css-class on the span is the
best solution from my point of view too.
A little concern however. I think this kind of change is not exactly
backward compatible. Sure, it is, for the java side, but I figure that
*many* users have wrote their own CSS for feedback panels and this will
probably results to bad display with this change. So, I am wondering if
this change will be considered as an API break? If yes, will you apply it
also to 1.5.x (the original demand)? And, if the new version numbering
system in place applies to 1.5.x, does that means that it should be 1.6.0?
You see what I mean... it could lead to some misunderstanding!..

Also I like Sven's suggestion, but I am afraid that it will overlap with
#newMessageDisplayComponent(). As ListItem IS-A WebMarkupContainer, we
could do any customization from here. But, in this case (there is a new
#newMessageItem() method), the span element is not needed anymore and
therefore #newMessageDisplayComponent() neither. So, about the API break,
we are in situation :)

Thanks  best regards,
Sebastien.


On Mon, Oct 29, 2012 at 6:18 PM, Joachim Schrod jsch...@acm.org wrote:

 Hi,

 This would change be very well received, from my side. :-) :-)

 Cheers,
 Joachim


 Martin Grigorov wrote:
  Hi,
 
  [X] Other suggestion: (please specify)
 
  Here is what I think it should be:
  - div element should have class feedbackPanel (this is already the
 case)
  - li element(s) should have class that specifies the feedback
  message level (currently by default Wicket sets feedbackPanelLEVEL,
  but this is configurable with
 
 org.apache.wicket.markup.html.panel.FeedbackPanel#getCSSClass(FeedbackMessage))
  - the span should not have class at all (currently it has the same
  class as the li element)
  - the styling should be done with CSS selectors (e.g.
  div.feedbackPanel; div.feedbackPanel li.alert-warn; div.feedbackPanel
  li.alert-warn span; ...)
  - if custom markup is needed then a custom FeedbackPanel is needed
  (one that extends from the default FeedbackPanel or a completely new
  one, it depends on the use case)
 
 
  On Sun, Oct 28, 2012 at 6:03 PM, Sebastien seb...@gmail.com wrote:
  Hi,
 
  To sum-up this thread: we have a (not huge, but still) design issue that
  annoys several users. A patch* has been provided but some questions
  remains...
  Given this, I would suggest a kind-of vote about the several points
  discussed earlier, in order to enlighten the dev-team about the
 preferred
  choice of their (beloved) users.**
 
  Here are some possible options:
  [ ] Please apply the patch as-is. It currently provides 2 methods
  (#getListCSSClass and #getLabelCSSClass), #getCSSClass is marked a
  deprecated until marked as private (or removed)
  [ ] Do not apply the patch as-is, #getCSSClass should be kept (not
 marked
  as deprecated)
  [ ] Do not apply the patch as-is, I do not agree with the 2 method
 names. I
  would have preferred: (please specify)
  [ ] This is not an issue; this does not need to be corrected
  [ ] Other suggestion: (please specify)
 
  Thanks in advance for your contribution,
  Sebastien
 
  (*) https://issues.apache.org/jira/browse/WICKET-4831
  (**) Sure, dev-team opinion is also kindly asked! :)
 
 
 



 Joachim

 --
 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
 Joachim Schrod, Roedermark, Germany
 Email: jsch...@acm.org


 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org

Re: Custom CSS for Feedback message is broken in 1.5

[Martin Grigorov]

Hi,

[X] Other suggestion: (please specify)

Here is what I think it should be:
- div element should have class feedbackPanel (this is already the case)
- li element(s) should have class that specifies the feedback
message level (currently by default Wicket sets feedbackPanelLEVEL,
but this is configurable with
org.apache.wicket.markup.html.panel.FeedbackPanel#getCSSClass(FeedbackMessage))
- the span should not have class at all (currently it has the same
class as the li element)
- the styling should be done with CSS selectors (e.g.
div.feedbackPanel; div.feedbackPanel li.alert-warn; div.feedbackPanel
li.alert-warn span; ...)
- if custom markup is needed then a custom FeedbackPanel is needed
(one that extends from the default FeedbackPanel or a completely new
one, it depends on the use case)


On Sun, Oct 28, 2012 at 6:03 PM, Sebastien seb...@gmail.com wrote:
 Hi,

 To sum-up this thread: we have a (not huge, but still) design issue that
 annoys several users. A patch* has been provided but some questions
 remains...
 Given this, I would suggest a kind-of vote about the several points
 discussed earlier, in order to enlighten the dev-team about the preferred
 choice of their (beloved) users.**

 Here are some possible options:
 [ ] Please apply the patch as-is. It currently provides 2 methods
 (#getListCSSClass and #getLabelCSSClass), #getCSSClass is marked a
 deprecated until marked as private (or removed)
 [ ] Do not apply the patch as-is, #getCSSClass should be kept (not marked
 as deprecated)
 [ ] Do not apply the patch as-is, I do not agree with the 2 method names. I
 would have preferred: (please specify)
 [ ] This is not an issue; this does not need to be corrected
 [ ] Other suggestion: (please specify)

 Thanks in advance for your contribution,
 Sebastien

 (*) https://issues.apache.org/jira/browse/WICKET-4831
 (**) Sure, dev-team opinion is also kindly asked! :)



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

[Sven Meier]

[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:
- div element should have class feedbackPanel (this is already the case)
- li element(s) should have class that specifies the feedback
message level (currently by default Wicket sets feedbackPanelLEVEL,
but this is configurable with
org.apache.wicket.markup.html.panel.FeedbackPanel#getCSSClass(FeedbackMessage))
- the span should not have class at all (currently it has the same
class as the li element)
- the styling should be done with CSS selectors (e.g.
div.feedbackPanel; div.feedbackPanel li.alert-warn; div.feedbackPanel
li.alert-warn span; ...)
- if custom markup is needed then a custom FeedbackPanel is needed
(one that extends from the default FeedbackPanel or a completely new
one, it depends on the use case)


On Sun, Oct 28, 2012 at 6:03 PM, Sebastien seb...@gmail.com wrote:

Hi,

To sum-up this thread: we have a (not huge, but still) design issue that
annoys several users. A patch* has been provided but some questions
remains...
Given this, I would suggest a kind-of vote about the several points
discussed earlier, in order to enlighten the dev-team about the preferred
choice of their (beloved) users.**

Here are some possible options:
[ ] Please apply the patch as-is. It currently provides 2 methods
(#getListCSSClass and #getLabelCSSClass), #getCSSClass is marked a
deprecated until marked as private (or removed)
[ ] Do not apply the patch as-is, #getCSSClass should be kept (not marked
as deprecated)
[ ] Do not apply the patch as-is, I do not agree with the 2 method names. I
would have preferred: (please specify)
[ ] This is not an issue; this does not need to be corrected
[ ] Other suggestion: (please specify)

Thanks in advance for your contribution,
Sebastien

(*) https://issues.apache.org/jira/browse/WICKET-4831
(**) Sure, dev-team opinion is also kindly asked! :)






-
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

[Pointbreak]

[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

[Joachim Schrod]

Hi,

This would change be very well received, from my side. :-) :-)

Cheers,
Joachim


Martin Grigorov wrote:
 Hi,
 
 [X] Other suggestion: (please specify)
 
 Here is what I think it should be:
 - div element should have class feedbackPanel (this is already the case)
 - li element(s) should have class that specifies the feedback
 message level (currently by default Wicket sets feedbackPanelLEVEL,
 but this is configurable with
 org.apache.wicket.markup.html.panel.FeedbackPanel#getCSSClass(FeedbackMessage))
 - the span should not have class at all (currently it has the same
 class as the li element)
 - the styling should be done with CSS selectors (e.g.
 div.feedbackPanel; div.feedbackPanel li.alert-warn; div.feedbackPanel
 li.alert-warn span; ...)
 - if custom markup is needed then a custom FeedbackPanel is needed
 (one that extends from the default FeedbackPanel or a completely new
 one, it depends on the use case)
 
 
 On Sun, Oct 28, 2012 at 6:03 PM, Sebastien seb...@gmail.com wrote:
 Hi,

 To sum-up this thread: we have a (not huge, but still) design issue that
 annoys several users. A patch* has been provided but some questions
 remains...
 Given this, I would suggest a kind-of vote about the several points
 discussed earlier, in order to enlighten the dev-team about the preferred
 choice of their (beloved) users.**

 Here are some possible options:
 [ ] Please apply the patch as-is. It currently provides 2 methods
 (#getListCSSClass and #getLabelCSSClass), #getCSSClass is marked a
 deprecated until marked as private (or removed)
 [ ] Do not apply the patch as-is, #getCSSClass should be kept (not marked
 as deprecated)
 [ ] Do not apply the patch as-is, I do not agree with the 2 method names. I
 would have preferred: (please specify)
 [ ] This is not an issue; this does not need to be corrected
 [ ] Other suggestion: (please specify)

 Thanks in advance for your contribution,
 Sebastien

 (*) https://issues.apache.org/jira/browse/WICKET-4831
 (**) Sure, dev-team opinion is also kindly asked! :)
 
 
 



Joachim

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Joachim Schrod, Roedermark, Germany
Email: jsch...@acm.org


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Custom CSS for Feedback message is broken in 1.5

[Sebastien]

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

[Joachim Schrod]

Martin Grigorov wrote:
 Hi,
 
 Here is an example of the produced markup for an single INFO message:
 
 div id=feedbackPanel
   span
   ul class=feedbackPanel
 li class=feedbackPanelINFO
   span class=feedbackPanelINFOSaved 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]]/span
 /li
   /ul
 /span
 /div
 
 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

[Martin Grigorov]

Hi,

Here is an example of the produced markup for an single INFO message:

div id=feedbackPanel
span
  ul class=feedbackPanel
li class=feedbackPanelINFO
  span class=feedbackPanelINFOSaved 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]]/span
/li
  /ul
/span
/div

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 jsch...@acm.org 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

[Sven Meier]

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

[Sven Meier]

The point is that he does *not* want getCSSClass() to be applied to the 
li.


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:
html xmlns:wicket=http://wicket.apache.org;
 wicket:panel
 div wicket:id=feedbackul class=feedbackMessages
 div wicket:id=messages
 span wicket:id=message[Feedback message(s)]/span
 /div
 /div
 /wicket:panel
/html

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 seb...@gmail.com 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 alecs...@gmail.com 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 seb...@gmail.com 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 s...@meiers.net 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.

RE: Custom CSS for Feedback message is broken in 1.5

[Paul Bors]

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

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:
 html xmlns:wicket=http://wicket.apache.org;
  wicket:panel
  div wicket:id=feedbackul class=feedbackMessages
  div wicket:id=messages
  span wicket:id=message[Feedback message(s)]/span
  /div
  /div
  /wicket:panel
 /html

 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 seb...@gmail.com 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 alecs...@gmail.com wrote:

 Technically it should be 

Re: Custom CSS for Feedback message is broken in 1.5

[Sebastien]

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 p...@bors.ws 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
 li.

 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:
  html xmlns:wicket=http://wicket.apache.org;
   wicket:panel
   div wicket:id=feedbackul class=feedbackMessages
   div wicket:id=messages
   span wicket:id=message[Feedback message(s)]/span
   /div
   /div
   /wicket:panel
  /html
 
  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 seb...@gmail.com 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
  

Re: Custom CSS for Feedback message is broken in 1.5

[Joachim Schrod]

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

[Alec Swan]

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 seb...@gmail.com 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 s...@meiers.net 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.orgusers-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

[Sebastien]

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 alecs...@gmail.com 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 seb...@gmail.com 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 s...@meiers.net 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

[Alec Swan]

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 seb...@gmail.com 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 alecs...@gmail.com 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 seb...@gmail.com 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 s...@meiers.net 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

[Paul Bors]

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:
html xmlns:wicket=http://wicket.apache.org;
wicket:panel
div wicket:id=feedbackul class=feedbackMessages
div wicket:id=messages
span wicket:id=message[Feedback message(s)]/span
/div
/div
/wicket:panel
/html

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 seb...@gmail.com 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 alecs...@gmail.com 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 seb...@gmail.com 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 s...@meiers.net 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: 

Re: Custom CSS for Feedback message is broken in 1.5

[Sven Meier]

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

[Sebastien]

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 s...@meiers.net 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.orgusers-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 Swan]

Note that I need to set CSS styles on the label (span) and not the
list item (li) and hence cannot override getCSSClass() because it is
applied to both.

On Sat, Oct 20, 2012 at 2:58 PM, Alec Swan alecs...@gmail.com 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

Re: Custom CSS for Feedback message is broken in 1.5

[Sven Meier]

I was just going to ask you why you don't overwrite #getCSSClass().

What harm does it if the CSS class is on the li too?

Sven

On 10/20/2012 11:01 PM, Alec Swan wrote:

Note that I need to set CSS styles on the label (span) and not the
list item (li) and hence cannot override getCSSClass() because it is
applied to both.

On Sat, Oct 20, 2012 at 2:58 PM, Alec Swan alecs...@gmail.com 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

[Sebastien]

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);
IteratorComponent 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 s...@meiers.net 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 li too?

 Sven


 On 10/20/2012 11:01 PM, Alec Swan wrote:

 Note that I need to set CSS styles on the label (span) and not the
 list item (li) and hence cannot override getCSSClass() because it is
 applied to both.

 On Sat, Oct 20, 2012 at 2:58 PM, Alec Swan alecs...@gmail.com 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.htmlhttps://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.orgusers-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org



 --**--**-
 To unsubscribe, e-mail: 
 users-unsubscribe@wicket.**apache.orgusers-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

[Sebastien]

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.