how to restrict the feedback message to display only one time for FormComponentPanel

[extraquoo]

our app has a phone number field like ###-###- x## on the page

 

We define a phone number class as FormComponentPanel in our app  like below 
public class PhoneFormComponent extends FormComponentPanel
{

private static final long serialVersionUID = 1L;

private TextField areaField;
private TextField threeField;
private TextField fourField;
private TextField extField;
private String area;
private String three;
private String four;
private String ext;

public PhoneFormComponent(String id, IModel phone) {
super(id, phone);
init();

}

private void init() {
if (getModelObject() != null) {
if 
(StringUtils.isNotBlank(getModelObject().getNumber())) {
String phoneNumber = 
getModelObject().getNumber();
area = phoneNumber.substring(0, 3);
three = phoneNumber.substring(4, 7);
four = phoneNumber.substring(8, 12);
}
ext = getModelObject().getExtension();
}
add(areaField = new TextField("area",
new PropertyModel(this, "area")));
areaField.add(new PatternValidator("\\d{3}")).setLabel(
new StringResourceModel("Phone", areaField, 
null));
add(threeField = new TextField("three",
new PropertyModel(this, "three")));
threeField.add(new PatternValidator("\\d{3}")).setLabel(
new StringResourceModel("Phone", threeField, 
null));
add(fourField = new TextField("four",
new PropertyModel(this, "four")));
fourField.add(new PatternValidator("\\d{4}")).setLabel(
new StringResourceModel("Phone", fourField, 
null));
add(extField = new TextField("ext", new 
PropertyModel(
this, "ext")));
extField.add(new PatternValidator("\\d{0,6}")).setLabel(
new StringResourceModel("Extension", extField, 
null));
areaField.add(new INullAcceptingValidator() {

/** Default serial id */
private static final long serialVersionUID = 1L;

@Override
public void validate(IValidatable validatable) {
if 
(StringUtils.isNotBlank(areaField.getConvertedInput()) != StringUtils

.isNotBlank(threeField.getConvertedInput())
&& 
StringUtils.isNotBlank(threeField

.getConvertedInput()) != StringUtils

.isNotBlank(fourField.getConvertedInput())) {
PhoneFormComponent.this.error(new 
ValidationError()

.addMessageKey("Incomplete"));
}
}

});
}

@Override
protected void convertInput() {
// note that earlier versions did override updateModel, which 
looked
// somewhat better, but wasn't useful for when you want to do
// validations with either normal validators or form validators
PhoneNumberType phoneNumber = new PhoneNumberType();
if (StringUtils.isNotBlank(areaField.getConvertedInput())
&& 
StringUtils.isNotBlank(threeField.getConvertedInput())
&& 
StringUtils.isNotBlank(fourField.getConvertedInput())) {
StringBuffer phoneString = new StringBuffer();
phoneString.append(areaField.getConvertedInput());
phoneString.append("-");
phoneString.append(threeField.getConvertedInput());
phoneString.append("-");
phoneString.append(fourField.getConvertedInput());
phoneNumber.setNumber(phoneString.toString());
phoneNumber.setExtension(extField.getConvertedInput());
setConvertedInput(phoneNumber);
} else if (StringUtils.isNotBlank(areaField.getConvertedInput())
|| 
StringUtils.isNotBlank(threeField.getConvertedInput())
|| 
StringUtils.isNotBlank(fourField.getConvertedInput())) {
  

Re: Set focus on feedback message?

[Martin Grigorov]

Add a Behavior to the feedback panel that contributes JS in its
renderHead() that focuses whatever you need in the feedback panel.

Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov

On Tue, Mar 14, 2017 at 10:41 PM, Entropy  wrote:

> Is there a way I can implement a common routine or class that would set
> focus
> to the feedback panel anytime a feedback panel is updated with an error?  I
> am hoping I don't have to ask our devs to include the behavior manually all
> over the place.  We have a common page that all of our pages inherit from
> and I was hoping I could add it there.
>
> --
> View this message in context: http://apache-wicket.1842946.
> n4.nabble.com/Set-focus-on-feedback-message-tp4677319.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
>
>

Set focus on feedback message?

[Entropy]

Is there a way I can implement a common routine or class that would set focus
to the feedback panel anytime a feedback panel is updated with an error?  I
am hoping I don't have to ask our devs to include the behavior manually all
over the place.  We have a common page that all of our pages inherit from
and I was hoping I could add it there.

--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Set-focus-on-feedback-message-tp4677319.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: AjaxSubmitLink + setResponsePage = feedback message problem on new page

[Sebastien]

> but I am not getting feedback message when there is some error.

In case of a redirection, you need to notify the message to the session,
not to the page/component.
ie: Session.get().warn(message);





On Thu, May 19, 2016 at 11:04 AM, Martin Grigorov 
wrote:

> Hi,
>
> If you use AjaxLink then you don't submit any data. You may try
> AjaxSubmitLink instead.
>
> Please give more information about "but setResponsePage is not working".
>
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
>
> On Thu, May 19, 2016 at 10:11 AM, Sarang  wrote:
>
> > Hello Josh,
> >
> > I am stuck in similar situation only. When I hit on the link, I want to
> > show
> > feedback message if there are some mandatory fields unfilled otherwise I
> > want to redirect using setResponsePage. If i use AjaxLink then I get
> > feedback message properly but setResponsePage is not working. When I use
> > SubmitLink, setResponsePage works fine but I am not getting feedback
> > message
> > when there is some error.
> >
> > Can you please suggest how can I solve this ?
> >
> > Thanks,
> > Sarang
> >
> > --
> > View this message in context:
> >
> http://apache-wicket.1842946.n4.nabble.com/AjaxSubmitLink-setResponsePage-feedback-message-problem-on-new-page-tp1843719p4674751.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: AjaxSubmitLink + setResponsePage = feedback message problem on new page

[Martin Grigorov]

Hi,

If you use AjaxLink then you don't submit any data. You may try
AjaxSubmitLink instead.

Please give more information about "but setResponsePage is not working".

Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov

On Thu, May 19, 2016 at 10:11 AM, Sarang  wrote:

> Hello Josh,
>
> I am stuck in similar situation only. When I hit on the link, I want to
> show
> feedback message if there are some mandatory fields unfilled otherwise I
> want to redirect using setResponsePage. If i use AjaxLink then I get
> feedback message properly but setResponsePage is not working. When I use
> SubmitLink, setResponsePage works fine but I am not getting feedback
> message
> when there is some error.
>
> Can you please suggest how can I solve this ?
>
> Thanks,
> Sarang
>
> --
> View this message in context:
> http://apache-wicket.1842946.n4.nabble.com/AjaxSubmitLink-setResponsePage-feedback-message-problem-on-new-page-tp1843719p4674751.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: AjaxSubmitLink + setResponsePage = feedback message problem on new page

[Sarang]

Hello Josh,

I am stuck in similar situation only. When I hit on the link, I want to show
feedback message if there are some mandatory fields unfilled otherwise I
want to redirect using setResponsePage. If i use AjaxLink then I get
feedback message properly but setResponsePage is not working. When I use
SubmitLink, setResponsePage works fine but I am not getting feedback message
when there is some error.

Can you please suggest how can I solve this ?

Thanks,
Sarang

--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/AjaxSubmitLink-setResponsePage-feedback-message-problem-on-new-page-tp1843719p4674751.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: Link in Feedback Message

[Martin Grigorov]

Hi,

See
https://github.com/l0rdn1kk0n/wicket-bootstrap/blob/master/bootstrap-core/src/main/java/de/agilecoders/wicket/core/markup/html/bootstrap/common/NotificationPanel.java#L108
It is a custom FeedbackPanel that uses a Panel instead of a Label for the
feedback messages.
This way you can put anything inside it.

Martin Grigorov
Wicket Training and Consulting


On Fri, May 2, 2014 at 9:01 PM, Entropy  wrote:

> I am currently putting a link into one of our feedback messages so give the
> user a quick way to navigate in response to a particular condition.  I am
> doing it by just writing the tags into the message like so:String url =
> this.urlFor(SearchResultPage.class, new PageParameters().set("newSearch",
> "True")).toString();error("The selected records have been successfully
> updated.   Search case for updated records <" + url + ">  .");this
> works...about 90% of the way.  But I recently discovered that I need to do
> a
> little work before that link navigates away.  I need to get the onclick
> event.  How can I get an event on the server that the link has been clicked
> and react to it?I am considering a workaround wherein I could provide an
> extra parameter that the target page detects, and causes it to run my code
> there.  But that's not ideal.  I'd rather keep this page's code in this
> page.  Is there a way to do this?
>
> --
> View this message in context:
> http://apache-wicket.1842946.n4.nabble.com/Link-in-Feedback-Message-tp4665648.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: Link in Feedback Message

[Martin Makundi]

You can look at how a link/button renders its url and render that to the
message.

**
Martin


2014-05-02 22:01 GMT+03:00 Entropy :

> I am currently putting a link into one of our feedback messages so give the
> user a quick way to navigate in response to a particular condition.  I am
> doing it by just writing the tags into the message like so:String url =
> this.urlFor(SearchResultPage.class, new PageParameters().set("newSearch",
> "True")).toString();error("The selected records have been successfully
> updated.   Search case for updated records <" + url + ">  .");this
> works...about 90% of the way.  But I recently discovered that I need to do
> a
> little work before that link navigates away.  I need to get the onclick
> event.  How can I get an event on the server that the link has been clicked
> and react to it?I am considering a workaround wherein I could provide an
> extra parameter that the target page detects, and causes it to run my code
> there.  But that's not ideal.  I'd rather keep this page's code in this
> page.  Is there a way to do this?
>
> --
> View this message in context:
> http://apache-wicket.1842946.n4.nabble.com/Link-in-Feedback-Message-tp4665648.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
>
>

Link in Feedback Message

[Entropy]

I am currently putting a link into one of our feedback messages so give the
user a quick way to navigate in response to a particular condition.  I am
doing it by just writing the tags into the message like so:String url =
this.urlFor(SearchResultPage.class, new PageParameters().set("newSearch",
"True")).toString();error("The selected records have been successfully
updated.   Search case for updated records <" + url + ">  .");this
works...about 90% of the way.  But I recently discovered that I need to do a
little work before that link navigates away.  I need to get the onclick
event.  How can I get an event on the server that the link has been clicked
and react to it?I am considering a workaround wherein I could provide an
extra parameter that the target page detects, and causes it to run my code
there.  But that's not ideal.  I'd rather keep this page's code in this
page.  Is there a way to do this?

--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Link-in-Feedback-Message-tp4665648.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: Filtered feedback message cleanup

[meduolis]

Thanks Francois, it works.

I am changing locale in BasePage, so I had to add postprocessLocaleChange()
and override it on it's subclasses to get it working.
So it would be great if we could clear messages using something like
FeedbackCollector.clearAll() without any knowledge about what components
contains what messages.

Thanks again



--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Filtered-feedback-message-cleanup-tp4662503p4662527.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: Filtered feedback message cleanup

[Francois Meillet]

Form form = new Form("form");
form.setOutputMarkupId(true);
add(form);

RequiredTextField username = new
RequiredTextField("username", new Model());
form.add(username);

final PasswordTextField password = new 
PasswordTextField("password", new
Model());
password.add(new ValidationMessageBehavior());
form.add(password);

Link localeLinkDE = new Link("localeLinkDE") {
@Override
public void onClick() {
Locale localeDE = new Locale("de", "DE");
setLocale(localeDE);
password.getFeedbackMessages().clear();
}
};
add(localeLinkDE);



-
François Meillet
Formation Wicket - Développement Wicket
--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Filtered-feedback-message-cleanup-tp4662503p4662523.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: Filtered feedback message cleanup

[meduolis]

attaching quickstart:  feedbackI18n.zip
<http://apache-wicket.1842946.n4.nabble.com/file/n4662505/feedbackI18n.zip>  



--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Filtered-feedback-message-cleanup-tp4662503p4662505.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

Filtered feedback message cleanup

[meduolis]

Hello,

I am not sure if it's a Wicket bug, or a lack of my wicket knowledge , but I
really need an assistance here.

I have a simple form with two different input fields: RequiredTextField and
PasswordTextField. Also there is a feedback panel, but it filters out
PasswordTextField feedback message and displays it inline to its' field.
When submiting the form, we got one message in feedback panel and one
message after password field.
<http://apache-wicket.1842946.n4.nabble.com/file/n4662503/formSubmited.gif> 
Later we trigger model update by setting new locale.
<http://apache-wicket.1842946.n4.nabble.com/file/n4662503/localeChanged.gif> 
Feedback message for username got cleared, but filtered feedback message -
not.

Is there any manual way to clear filtered messages? Or it should be done  by
Wicket itself?



--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Filtered-feedback-message-cleanup-tp4662503.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

Filtered feedback message cleanup

[meduolis]

Hello,

I am not sure if it's a Wicket bug, or a lack of my wicket knowledge , but I
really need an assistance here.

I have a simple form with two different input fields: RequiredTextField and
PasswordTextField. Also there is a feedback panel, but it filters out
PasswordTextField feedback message and displays it inline to its' field.
When submiting the form, we got one message in feedback panel and one
message after password field.
<http://apache-wicket.1842946.n4.nabble.com/file/n4662502/formSubmited.gif> 
Later we trigger model update by setting new locale.

Feedback message for username got cleared, but filtered feedback message -
not.

Is there any manual way to clear filtered messages? Or it should be done  by
Wicket itself?



--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Filtered-feedback-message-cleanup-tp4662502.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: Feedback message is not available for behaviors added to nested form components

[James Selvakumar]

Thanks Jesse & Sven for your explanations.
It worked like a charm after I set ListView#setReuseItems(true)
Thank you very much.


On Wed, Jul 3, 2013 at 3:12 PM, Jesse Long  wrote:

> Hi James,
>
> This is a shortened list of events happening, including only the ones
> affecting you. They are in the order in which they occur.
>
>  * IFormSubmitListener#**onFormSubmitted()
>  * ListView#onBeforeRender()
>  * Page#onRender()
>
> ListView#onBeforeRender() calls ListView#onPopulate(). If you are not
> using ListView#setReuseItems(true), then ListView#onPopulate() removes all
> children of ListView and re-creates them.
>
> So, the children of ListView that are present during Page#onRender() are
> not the same children that were present during 
> IFormSubmitListener#**onFormSubmitted(),
> and hence not the same children that had the feedback messages.
>
> Cheers,
> Jesse
>
>
> On 03/07/2013 02:35, James Selvakumar wrote:
>
>> No.
>>
>>
>> On Tue, Jul 2, 2013 at 7:04 PM, Sven Meier  wrote:
>>
>>  Are you using listView.setReuseItems(true) ?
>>>
>>> Sven
>>>
>>>
>>> On 07/02/2013 11:13 AM, James Selvakumar wrote:
>>>
>>>  Hi all,

 I've the following component heirarchy:

 form:textField
 form:listView:panel-1:panel1DropDownChoice

 form:submitButton

 I've marked the all the form components as required.

 I also have a behavior that is added to all the form components (via
 IVisitor) which will make the respective feedback messages appear under
 the
 form components.

 It works perfectly for the form component "texField" which is directly
 attached to the form.

 However it doesn't work for for "panel1DropDownChoice".

 I've added some debug messages in the "validate()" method of
 "panel1DropDownChoice" and found that feedback messages are indeed
 generated.

 However from the debug messages in my behavior, I found that feedback
 messages were some how lost.

 This is the behavior I'm using. (Thanks London Wicket users)

 *public class ValidationMsgBehavior extends Behavior

 {
   private static Logger logger =
 LoggerFactory.getLogger(ValidationMsgBehavior.class);


   @Override
   public void afterRender(Component c)
   {
   logger.debug("Preparing to add validation msg for the
 component
 {}", c);
   FormComponent fc = (FormComponent) c;
   if (!fc.isValid()) {
   String error;
   if (fc.hasFeedbackMessage()) {
   logger.debug("Form component {} has feedback
 messages",
 fc);
   error =
 fc.getFeedbackMessages().first(FeedbackMessage.ERROR).

 getMessage().toString();
   } else {
   error = "Your input is invalid.";
   }
   fc.getResponse().write(
   "" + error + "");
   }else{
   logger.debug("Form component {} is valid", fc);
   }
   }
 }*

 Any clues? I've been trying to crack this for a whole day.


  --**
>>> --**-
>>> To unsubscribe, e-mail: 
>>> users-unsubscribe@wicket.**apa**che.org
>>> 
>>> >
>>>
>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>
>>>
>>>
>>
>


-- 
Thanks & regards
James Selvakumar
mCruncher

Re: Feedback message is not available for behaviors added to nested form components

[James Selvakumar]

Hi Sven,

I'm sorry I'm not adding components but I update the model so that the
ListView generates the components dynamically.


On Thu, Jul 4, 2013 at 3:16 PM, Sven Meier  wrote:

> Hi,
>
> ListView will create components for you based on the contents of the
> model. Why are you adding components?
>
> Sven
>
>
> On 07/04/2013 02:41 AM, James Selvakumar wrote:
>
>> Hi Jesse,
>>
>> I was not aware of this before. Thanks for the insight
>> But I do add/remove components to the ListView dynamically.
>> Will ListView#setReuseItems(true) affect that?
>>
>>
>> On Wed, Jul 3, 2013 at 3:12 PM, Jesse Long  wrote:
>>
>>  Hi James,
>>>
>>> This is a shortened list of events happening, including only the ones
>>> affecting you. They are in the order in which they occur.
>>>
>>>   * IFormSubmitListener#onFormSubmitted()
>>>
>>>   * ListView#onBeforeRender()
>>>   * Page#onRender()
>>>
>>> ListView#onBeforeRender() calls ListView#onPopulate(). If you are not
>>> using ListView#setReuseItems(true), then ListView#onPopulate() removes
>>> all
>>> children of ListView and re-creates them.
>>>
>>> So, the children of ListView that are present during Page#onRender() are
>>> not the same children that were present during IFormSubmitListener#
>>> onFormSubmitted(),
>>>
>>> and hence not the same children that had the feedback messages.
>>>
>>> Cheers,
>>> Jesse
>>>
>>>
>>> On 03/07/2013 02:35, James Selvakumar wrote:
>>>
>>>  No.


 On Tue, Jul 2, 2013 at 7:04 PM, Sven Meier  wrote:

   Are you using listView.setReuseItems(true) ?

> Sven
>
>
> On 07/02/2013 11:13 AM, James Selvakumar wrote:
>
>   Hi all,
>
>> I've the following component heirarchy:
>>
>> form:textField
>> form:listView:panel-1:**panel1DropDownChoice
>>
>>
>> form:submitButton
>>
>> I've marked the all the form components as required.
>>
>> I also have a behavior that is added to all the form components (via
>> IVisitor) which will make the respective feedback messages appear
>> under
>> the
>> form components.
>>
>> It works perfectly for the form component "texField" which is directly
>> attached to the form.
>>
>> However it doesn't work for for "panel1DropDownChoice".
>>
>> I've added some debug messages in the "validate()" method of
>> "panel1DropDownChoice" and found that feedback messages are indeed
>> generated.
>>
>> However from the debug messages in my behavior, I found that feedback
>> messages were some how lost.
>>
>> This is the behavior I'm using. (Thanks London Wicket users)
>>
>> *public class ValidationMsgBehavior extends Behavior
>>
>> {
>>private static Logger logger =
>> LoggerFactory.getLogger(**ValidationMsgBehavior.class);
>>
>>
>>
>>@Override
>>public void afterRender(Component c)
>>{
>>logger.debug("Preparing to add validation msg for the
>> component
>> {}", c);
>>FormComponent fc = (FormComponent) c;
>>if (!fc.isValid()) {
>>String error;
>>if (fc.hasFeedbackMessage()) {
>>logger.debug("Form component {} has feedback
>> messages",
>> fc);
>>error =
>> fc.getFeedbackMessages().**first(FeedbackMessage.ERROR).**
>>
>>
>> getMessage().toString();
>>} else {
>>error = "Your input is invalid.";
>>}
>>fc.getResponse().write(
>>"" + error +
>> "");
>>}else{
>>logger.debug("Form component {} is valid", fc);
>>}
>>}
>> }*
>>
>> Any clues? I've been trying to crack this for a whole day.
>>
>>
>>   --**--**
>> --**
>>
> --**-
> To unsubscribe, e-mail: users-unsubscribe@wicket.apa**che.org<
> http://apache.org**>
> http://wicket.apache.org><
> users-unsubscribe@**wicket.apache.org
> >
>
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
>
>
>>
>
> --**--**-
> To unsubscribe, e-mail: 
> users-unsubscribe@wicket.**apache.org
>
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>


-- 
Thanks & regards
James Selvakumar
mCruncher

Re: Feedback message is not available for behaviors added to nested form components

[Sven Meier]

Hi,

ListView will create components for you based on the contents of the 
model. Why are you adding components?


Sven

On 07/04/2013 02:41 AM, James Selvakumar wrote:

Hi Jesse,

I was not aware of this before. Thanks for the insight
But I do add/remove components to the ListView dynamically.
Will ListView#setReuseItems(true) affect that?


On Wed, Jul 3, 2013 at 3:12 PM, Jesse Long  wrote:


Hi James,

This is a shortened list of events happening, including only the ones
affecting you. They are in the order in which they occur.

  * IFormSubmitListener#**onFormSubmitted()
  * ListView#onBeforeRender()
  * Page#onRender()

ListView#onBeforeRender() calls ListView#onPopulate(). If you are not
using ListView#setReuseItems(true), then ListView#onPopulate() removes all
children of ListView and re-creates them.

So, the children of ListView that are present during Page#onRender() are
not the same children that were present during 
IFormSubmitListener#**onFormSubmitted(),
and hence not the same children that had the feedback messages.

Cheers,
Jesse


On 03/07/2013 02:35, James Selvakumar wrote:


No.


On Tue, Jul 2, 2013 at 7:04 PM, Sven Meier  wrote:

  Are you using listView.setReuseItems(true) ?

Sven


On 07/02/2013 11:13 AM, James Selvakumar wrote:

  Hi all,

I've the following component heirarchy:

form:textField
form:listView:panel-1:panel1DropDownChoice

form:submitButton

I've marked the all the form components as required.

I also have a behavior that is added to all the form components (via
IVisitor) which will make the respective feedback messages appear under
the
form components.

It works perfectly for the form component "texField" which is directly
attached to the form.

However it doesn't work for for "panel1DropDownChoice".

I've added some debug messages in the "validate()" method of
"panel1DropDownChoice" and found that feedback messages are indeed
generated.

However from the debug messages in my behavior, I found that feedback
messages were some how lost.

This is the behavior I'm using. (Thanks London Wicket users)

*public class ValidationMsgBehavior extends Behavior

{
   private static Logger logger =
LoggerFactory.getLogger(ValidationMsgBehavior.class);


   @Override
   public void afterRender(Component c)
   {
   logger.debug("Preparing to add validation msg for the
component
{}", c);
   FormComponent fc = (FormComponent) c;
   if (!fc.isValid()) {
   String error;
   if (fc.hasFeedbackMessage()) {
   logger.debug("Form component {} has feedback
messages",
fc);
   error =
fc.getFeedbackMessages().first(FeedbackMessage.ERROR).

getMessage().toString();
   } else {
   error = "Your input is invalid.";
   }
   fc.getResponse().write(
   "" + error + "");
   }else{
   logger.debug("Form component {} is valid", fc);
   }
   }
}*

Any clues? I've been trying to crack this for a whole day.


  --**

--**-
To unsubscribe, e-mail: 
users-unsubscribe@wicket.**apa**che.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: Feedback message is not available for behaviors added to nested form components

[James Selvakumar]

Hi Jesse,

I was not aware of this before. Thanks for the insight
But I do add/remove components to the ListView dynamically.
Will ListView#setReuseItems(true) affect that?


On Wed, Jul 3, 2013 at 3:12 PM, Jesse Long  wrote:

> Hi James,
>
> This is a shortened list of events happening, including only the ones
> affecting you. They are in the order in which they occur.
>
>  * IFormSubmitListener#**onFormSubmitted()
>  * ListView#onBeforeRender()
>  * Page#onRender()
>
> ListView#onBeforeRender() calls ListView#onPopulate(). If you are not
> using ListView#setReuseItems(true), then ListView#onPopulate() removes all
> children of ListView and re-creates them.
>
> So, the children of ListView that are present during Page#onRender() are
> not the same children that were present during 
> IFormSubmitListener#**onFormSubmitted(),
> and hence not the same children that had the feedback messages.
>
> Cheers,
> Jesse
>
>
> On 03/07/2013 02:35, James Selvakumar wrote:
>
>> No.
>>
>>
>> On Tue, Jul 2, 2013 at 7:04 PM, Sven Meier  wrote:
>>
>>  Are you using listView.setReuseItems(true) ?
>>>
>>> Sven
>>>
>>>
>>> On 07/02/2013 11:13 AM, James Selvakumar wrote:
>>>
>>>  Hi all,

 I've the following component heirarchy:

 form:textField
 form:listView:panel-1:panel1DropDownChoice

 form:submitButton

 I've marked the all the form components as required.

 I also have a behavior that is added to all the form components (via
 IVisitor) which will make the respective feedback messages appear under
 the
 form components.

 It works perfectly for the form component "texField" which is directly
 attached to the form.

 However it doesn't work for for "panel1DropDownChoice".

 I've added some debug messages in the "validate()" method of
 "panel1DropDownChoice" and found that feedback messages are indeed
 generated.

 However from the debug messages in my behavior, I found that feedback
 messages were some how lost.

 This is the behavior I'm using. (Thanks London Wicket users)

 *public class ValidationMsgBehavior extends Behavior

 {
   private static Logger logger =
 LoggerFactory.getLogger(ValidationMsgBehavior.class);


   @Override
   public void afterRender(Component c)
   {
   logger.debug("Preparing to add validation msg for the
 component
 {}", c);
   FormComponent fc = (FormComponent) c;
   if (!fc.isValid()) {
   String error;
   if (fc.hasFeedbackMessage()) {
   logger.debug("Form component {} has feedback
 messages",
 fc);
   error =
 fc.getFeedbackMessages().first(FeedbackMessage.ERROR).

 getMessage().toString();
   } else {
   error = "Your input is invalid.";
   }
   fc.getResponse().write(
   "" + error + "");
   }else{
   logger.debug("Form component {} is valid", fc);
   }
   }
 }*

 Any clues? I've been trying to crack this for a whole day.


  --**
>>> --**-
>>> To unsubscribe, e-mail: 
>>> users-unsubscribe@wicket.**apa**che.org
>>> 
>>> >
>>>
>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>
>>>
>>>
>>
>


-- 
Thanks & regards
James Selvakumar
mCruncher

Re: Feedback message is not available for behaviors added to nested form components

[Jesse Long]

Hi James,

This is a shortened list of events happening, including only the ones 
affecting you. They are in the order in which they occur.


 * IFormSubmitListener#onFormSubmitted()
 * ListView#onBeforeRender()
 * Page#onRender()

ListView#onBeforeRender() calls ListView#onPopulate(). If you are not 
using ListView#setReuseItems(true), then ListView#onPopulate() removes 
all children of ListView and re-creates them.


So, the children of ListView that are present during Page#onRender() are 
not the same children that were present during 
IFormSubmitListener#onFormSubmitted(), and hence not the same children 
that had the feedback messages.


Cheers,
Jesse

On 03/07/2013 02:35, James Selvakumar wrote:

No.


On Tue, Jul 2, 2013 at 7:04 PM, Sven Meier  wrote:


Are you using listView.setReuseItems(true) ?

Sven


On 07/02/2013 11:13 AM, James Selvakumar wrote:


Hi all,

I've the following component heirarchy:

form:textField
form:listView:panel-1:**panel1DropDownChoice
form:submitButton

I've marked the all the form components as required.

I also have a behavior that is added to all the form components (via
IVisitor) which will make the respective feedback messages appear under
the
form components.

It works perfectly for the form component "texField" which is directly
attached to the form.

However it doesn't work for for "panel1DropDownChoice".

I've added some debug messages in the "validate()" method of
"panel1DropDownChoice" and found that feedback messages are indeed
generated.

However from the debug messages in my behavior, I found that feedback
messages were some how lost.

This is the behavior I'm using. (Thanks London Wicket users)

*public class ValidationMsgBehavior extends Behavior

{
  private static Logger logger =
LoggerFactory.getLogger(**ValidationMsgBehavior.class);

  @Override
  public void afterRender(Component c)
  {
  logger.debug("Preparing to add validation msg for the component
{}", c);
  FormComponent fc = (FormComponent) c;
  if (!fc.isValid()) {
  String error;
  if (fc.hasFeedbackMessage()) {
  logger.debug("Form component {} has feedback messages",
fc);
  error =
fc.getFeedbackMessages().**first(FeedbackMessage.ERROR).**
getMessage().toString();
  } else {
  error = "Your input is invalid.";
  }
  fc.getResponse().write(
  "" + error + "");
  }else{
  logger.debug("Form component {} is valid", fc);
  }
  }
}*

Any clues? I've been trying to crack this for a whole day.



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

Re: Feedback message is not available for behaviors added to nested form components

[James Selvakumar]

No.


On Tue, Jul 2, 2013 at 7:04 PM, Sven Meier  wrote:

> Are you using listView.setReuseItems(true) ?
>
> Sven
>
>
> On 07/02/2013 11:13 AM, James Selvakumar wrote:
>
>> Hi all,
>>
>> I've the following component heirarchy:
>>
>> form:textField
>> form:listView:panel-1:**panel1DropDownChoice
>> form:submitButton
>>
>> I've marked the all the form components as required.
>>
>> I also have a behavior that is added to all the form components (via
>> IVisitor) which will make the respective feedback messages appear under
>> the
>> form components.
>>
>> It works perfectly for the form component "texField" which is directly
>> attached to the form.
>>
>> However it doesn't work for for "panel1DropDownChoice".
>>
>> I've added some debug messages in the "validate()" method of
>> "panel1DropDownChoice" and found that feedback messages are indeed
>> generated.
>>
>> However from the debug messages in my behavior, I found that feedback
>> messages were some how lost.
>>
>> This is the behavior I'm using. (Thanks London Wicket users)
>>
>> *public class ValidationMsgBehavior extends Behavior
>>
>> {
>>  private static Logger logger =
>> LoggerFactory.getLogger(**ValidationMsgBehavior.class);
>>
>>  @Override
>>  public void afterRender(Component c)
>>  {
>>  logger.debug("Preparing to add validation msg for the component
>> {}", c);
>>  FormComponent fc = (FormComponent) c;
>>  if (!fc.isValid()) {
>>  String error;
>>  if (fc.hasFeedbackMessage()) {
>>  logger.debug("Form component {} has feedback messages",
>> fc);
>>  error =
>> fc.getFeedbackMessages().**first(FeedbackMessage.ERROR).**
>> getMessage().toString();
>>  } else {
>>  error = "Your input is invalid.";
>>  }
>>  fc.getResponse().write(
>>  "" + error + "");
>>  }else{
>>  logger.debug("Form component {} is valid", fc);
>>  }
>>  }
>> }*
>>
>> Any clues? I've been trying to crack this for a whole day.
>>
>>
>
> --**--**-
> To unsubscribe, e-mail: 
> users-unsubscribe@wicket.**apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>


-- 
Thanks & regards
James Selvakumar
mCruncher

Re: Feedback message is not available for behaviors added to nested form components

[Sven Meier]

Are you using listView.setReuseItems(true) ?

Sven

On 07/02/2013 11:13 AM, James Selvakumar wrote:

Hi all,

I've the following component heirarchy:

form:textField
form:listView:panel-1:panel1DropDownChoice
form:submitButton

I've marked the all the form components as required.

I also have a behavior that is added to all the form components (via
IVisitor) which will make the respective feedback messages appear under the
form components.

It works perfectly for the form component "texField" which is directly
attached to the form.

However it doesn't work for for "panel1DropDownChoice".

I've added some debug messages in the "validate()" method of
"panel1DropDownChoice" and found that feedback messages are indeed
generated.

However from the debug messages in my behavior, I found that feedback
messages were some how lost.

This is the behavior I'm using. (Thanks London Wicket users)

*public class ValidationMsgBehavior extends Behavior
{
 private static Logger logger =
LoggerFactory.getLogger(ValidationMsgBehavior.class);

 @Override
 public void afterRender(Component c)
 {
 logger.debug("Preparing to add validation msg for the component
{}", c);
 FormComponent fc = (FormComponent) c;
 if (!fc.isValid()) {
 String error;
 if (fc.hasFeedbackMessage()) {
 logger.debug("Form component {} has feedback messages", fc);
 error =
fc.getFeedbackMessages().first(FeedbackMessage.ERROR).getMessage().toString();
 } else {
 error = "Your input is invalid.";
 }
 fc.getResponse().write(
 "" + error + "");
 }else{
 logger.debug("Form component {} is valid", fc);
 }
 }
}*

Any clues? I've been trying to crack this for a whole day.




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

Feedback message is not available for behaviors added to nested form components

[James Selvakumar]

Hi all,

I've the following component heirarchy:

form:textField
form:listView:panel-1:panel1DropDownChoice
form:submitButton

I've marked the all the form components as required.

I also have a behavior that is added to all the form components (via
IVisitor) which will make the respective feedback messages appear under the
form components.

It works perfectly for the form component "texField" which is directly
attached to the form.

However it doesn't work for for "panel1DropDownChoice".

I've added some debug messages in the "validate()" method of
"panel1DropDownChoice" and found that feedback messages are indeed
generated.

However from the debug messages in my behavior, I found that feedback
messages were some how lost.

This is the behavior I'm using. (Thanks London Wicket users)

*public class ValidationMsgBehavior extends Behavior
{
private static Logger logger =
LoggerFactory.getLogger(ValidationMsgBehavior.class);

@Override
public void afterRender(Component c)
{
logger.debug("Preparing to add validation msg for the component
{}", c);
FormComponent fc = (FormComponent) c;
if (!fc.isValid()) {
String error;
if (fc.hasFeedbackMessage()) {
logger.debug("Form component {} has feedback messages", fc);
error =
fc.getFeedbackMessages().first(FeedbackMessage.ERROR).getMessage().toString();
} else {
error = "Your input is invalid.";
}
fc.getResponse().write(
"" + error + "");
}else{
logger.debug("Form component {} is valid", fc);
}
}
}*

Any clues? I've been trying to crack this for a whole day.

-- 
Thanks & regards
James Selvakumar

Re: AjaxSubmitLink + setResponsePage = feedback message problem on new page

[sadiq81]

Thx for this post, it also helped me :)



--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/AjaxSubmitLink-setResponsePage-feedback-message-problem-on-new-page-tp1843719p4654214.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

[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  wrote:

> I verified that the change is in master branch, but not in
> wicket-1.5.x branch. What is wicket-1.5.x branch used for?
>


martin@martin-laptop:~/git/apache/wicket-1.5.x(wicket-1.5.x=)$ git log
--grep=WICKET-4831
commit d7e019152df0756d307d8136dd94fcdb819823a6
Author: svenmeier 
Date:   Fri Nov 2 21:31:46 2012 +0100

WICKET-4831 removed class attribute from markup

commit afec3a61ccd63e833586be33867eb873a721a941
Author: Martin Tzvetanov Grigorov 
Date:   Fri Nov 2 19:01:09 2012 +0200

WICKET-4831 Append the feedback message CSS class instead of overriding
it



>
> On Tue, Nov 6, 2012 at 11:44 PM, Martin Grigorov 
> wrote:
> > The ticket says that the improvement is in 1.5.9, no ?
> >
> >
> > On Wed, Nov 7, 2012 at 1:45 AM, Alec Swan  wrote:
> >>
> >> Martin, could you please merge your changes to 1.5.9 branch?
> >>
> >> Thanks,
> >>
> >> Alec
> >>
> >>
> >> -- Forwarded message --
> >> From: Alec Swan 
> >> Date: Fri, Nov 2, 2012 at 1:48 PM
> >> Subject: Re: Custom CSS for Feedback message is broken in 1.5
> >> To: users@wicket.apache.org
> >>
> >>
> >> I don't see 1.5.9 branch either and I don't see the changes in 1.5.x
> >> branch. Martin, where did you check your changes in?
> >>
> >> Thanks,
> >>
> >> Alec
> >>
> >> On Fri, Nov 2, 2012 at 12:56 PM, Sebastien  wrote:
> >> > Hi Martin,
> >> >
> >> > Tested & approved! Works like a charm...
> >> >
> >> > I tested upon master branch (6.3.0-SNAPSHOT), because I do not see
> were
> >> > wicket-1.5.9 branch is... But I guess it behaves exactly the same.
> >> > Just a little note; on the version I pulled I still have
> >> > class="errorlevel"
> >> > in the associated markup (Sven's added a comment in the ticket about
> >> > this,
> >> > I don't know if you had it)...
> >> >
> >> > Thanks again & best regards,
> >> > Sebastien.
> >> >
> >> > On Fri, Nov 2, 2012 at 6:08 PM, Martin Grigorov
> >> > wrote:
> >> >
> >> >> Done!
> >> >>
> >> >> Please confirm that this is enough for now.
> >> >>
> >> >> On Fri, Nov 2, 2012 at 7:01 PM, Sebastien  wrote:
> >> >> > Great! Thanks Martin!
> >> >> >
> >> >> > On Fri, Nov 2, 2012 at 5:01 PM, Martin Grigorov <
> mgrigo...@apache.org
> >> >> >wrote:
> >> >> >
> >> >> >> I'll take care.
> >> >> >>
> >> >> >> On Fri, Nov 2, 2012 at 5:59 PM, Sebastien 
> wrote:
> >> >> >> > Hi Alec,
> >> >> >> >
> >> >> >> > If Sven or Martin agree with this solution for 1.5.9 & 6.3.0, I
> >> >> >> > can
> >> >> >> attach
> >> >> >> > the patch(es) to the opened ticket if needed. (but to replace a
> >> >> >> > word
> >> >> by
> >> >> >> > another, I am not sure my support will help that much! :) )
> >> >> >> >
> >> >> >> > I also think that we can keep this AttributeAppender even with
> the
> >> >> >> changes
> >> >> >> > to be done for wicket7 (with the Martin's suggestion for
> >> >> >> > instance). At
> >> >> >> > least I do not see yet any potential issue / unexpected behavior
> >> >> >> > that
> >> >> can
> >> >> >> > happens, and we keep the advantage it provides...
> >> >> >> >
> >> >> >> > Best regards,
> >> >> >> > Sebastien.
> >> >> >> >
> >> >> >> > On Fri, Nov 2, 2012 at 4:21 PM, Alec Swan 
> >> >> >> > wrote:
> >> >> >> >
> >> >> >> >> Sebastien, thanks for reviewing and approving the proposal. So,
> >> >> >> >> what
> >> >> >> >> do we need to do to make it in 1.5.9? Or did you already check
> it
> >> >> >> >> in
> >> >> >> >>

Re: Custom CSS for Feedback message is broken in 1.5

[Alec Swan]

Is anybody merging this in 1.5.9?

On Fri, Nov 2, 2012 at 11:37 PM, miteshaegis  wrote:
> Hi,
>
> You can use set of  class and set css on div class easily.
>
> Thanks!
>
>
>
> -
> JBoss Developers  || JBPM Workflow
> --
> View this message in context: 
> http://apache-wicket.1842946.n4.nabble.com/Custom-CSS-for-Feedback-message-is-broken-in-1-5-tp4653166p4653593.html
> Sent from the Users forum mailing list archive at Nabble.com.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>

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

Re: Custom CSS for Feedback message is broken in 1.5

[miteshaegis]

Hi,

You can use set of  class and set css on div class easily.

Thanks!



-
JBoss Developers  || JBPM Workflow 
--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Custom-CSS-for-Feedback-message-is-broken-in-1-5-tp4653166p4653593.html
Sent from the Users forum mailing list archive at Nabble.com.

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

Re: Custom CSS for Feedback message is broken in 1.5

[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  wrote:

Hi Martin,

Tested & approved! Works like a charm...

I tested upon master branch (6.3.0-SNAPSHOT), because I do not see were
wicket-1.5.9 branch is... But I guess it behaves exactly the same.
Just a little note; on the version I pulled I still have class="errorlevel"
in the associated markup (Sven's added a comment in the ticket about this,
I don't know if you had it)...

Thanks again & best regards,
Sebastien.

On Fri, Nov 2, 2012 at 6:08 PM, Martin Grigorov wrote:


Done!

Please confirm that this is enough for now.

On Fri, Nov 2, 2012 at 7:01 PM, Sebastien  wrote:

Great! Thanks Martin!

On Fri, Nov 2, 2012 at 5:01 PM, Martin Grigorov 
I'll take care.

On Fri, Nov 2, 2012 at 5:59 PM, Sebastien  wrote:

Hi Alec,

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

attach

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

by

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

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

changes

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

can

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

Best regards,
Sebastien.

On Fri, Nov 2, 2012 at 4:21 PM, Alec Swan  wrote:


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

Thanks,

Alec

On Thu, Nov 1, 2012 at 6:04 PM, Sebastien  wrote:

Hi Alec,

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

better

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

it

is

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

something

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

Thanks again & best regards,
Sebastien.




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

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



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




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

Re: Custom CSS for Feedback message is broken in 1.5

[Alec Swan]

I don't see 1.5.9 branch either and I don't see the changes in 1.5.x
branch. Martin, where did you check your changes in?

Thanks,

Alec

On Fri, Nov 2, 2012 at 12:56 PM, Sebastien  wrote:
> Hi Martin,
>
> Tested & approved! Works like a charm...
>
> I tested upon master branch (6.3.0-SNAPSHOT), because I do not see were
> wicket-1.5.9 branch is... But I guess it behaves exactly the same.
> Just a little note; on the version I pulled I still have class="errorlevel"
> in the associated markup (Sven's added a comment in the ticket about this,
> I don't know if you had it)...
>
> Thanks again & best regards,
> Sebastien.
>
> On Fri, Nov 2, 2012 at 6:08 PM, Martin Grigorov wrote:
>
>> Done!
>>
>> Please confirm that this is enough for now.
>>
>> On Fri, Nov 2, 2012 at 7:01 PM, Sebastien  wrote:
>> > Great! Thanks Martin!
>> >
>> > On Fri, Nov 2, 2012 at 5:01 PM, Martin Grigorov > >wrote:
>> >
>> >> I'll take care.
>> >>
>> >> On Fri, Nov 2, 2012 at 5:59 PM, Sebastien  wrote:
>> >> > Hi Alec,
>> >> >
>> >> > If Sven or Martin agree with this solution for 1.5.9 & 6.3.0, I can
>> >> attach
>> >> > the patch(es) to the opened ticket if needed. (but to replace a word
>> by
>> >> > another, I am not sure my support will help that much! :) )
>> >> >
>> >> > I also think that we can keep this AttributeAppender even with the
>> >> changes
>> >> > to be done for wicket7 (with the Martin's suggestion for instance). At
>> >> > least I do not see yet any potential issue / unexpected behavior that
>> can
>> >> > happens, and we keep the advantage it provides...
>> >> >
>> >> > Best regards,
>> >> > Sebastien.
>> >> >
>> >> > On Fri, Nov 2, 2012 at 4:21 PM, Alec Swan  wrote:
>> >> >
>> >> >> Sebastien, thanks for reviewing and approving the proposal. So, what
>> >> >> do we need to do to make it in 1.5.9? Or did you already check it in
>> >> >> there?
>> >> >>
>> >> >> Thanks,
>> >> >>
>> >> >> Alec
>> >> >>
>> >> >> On Thu, Nov 1, 2012 at 6:04 PM, Sebastien  wrote:
>> >> >> > Hi Alec,
>> >> >> >
>> >> >> > Thanks for having taking time to write the code snippet bellow, I
>> >> better
>> >> >> > understand your idea!..
>> >> >> > I did not realized you didn't want to use getCssClass, but I think
>> it
>> >> is
>> >> >> > good solution anyway! It is easy for the user to replace
>> >> >> > message.isInfo() ? ".my-ui-info" : ".my-ui-error"
>> >> >> > by its custom method: getMessageCssClass(message.getLevel()) or
>> >> something
>> >> >> > equivalent as we spoke before, so that's fine for me. Well done!
>> >> >> >
>> >> >> > Thanks again & best regards,
>> >> >> > Sebastien.
>> >> >> >
>> >>
>>
>>
>>
>> --
>> Martin Grigorov
>> jWeekend
>> Training, Consulting, Development
>> http://jWeekend.com
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>

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

Re: Custom CSS for Feedback message is broken in 1.5

[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 wrote:

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

Re: Custom CSS for Feedback message is broken in 1.5

[Martin Grigorov]

Done!

Please confirm that this is enough for now.

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



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

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

Re: Custom CSS for Feedback message is broken in 1.5

[Sebastien]

Great! Thanks Martin!

On Fri, Nov 2, 2012 at 5:01 PM, Martin Grigorov wrote:

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

Re: Custom CSS for Feedback message is broken in 1.5

[Martin Grigorov]

I'll take care.

On Fri, Nov 2, 2012 at 5:59 PM, Sebastien  wrote:
> Hi Alec,
>
> If Sven or Martin agree with this solution for 1.5.9 & 6.3.0, I can attach
> the patch(es) to the opened ticket if needed. (but to replace a word by
> another, I am not sure my support will help that much! :) )
>
> I also think that we can keep this AttributeAppender even with the changes
> to be done for wicket7 (with the Martin's suggestion for instance). At
> least I do not see yet any potential issue / unexpected behavior that can
> happens, and we keep the advantage it provides...
>
> Best regards,
> Sebastien.
>
> On Fri, Nov 2, 2012 at 4:21 PM, Alec Swan  wrote:
>
>> Sebastien, thanks for reviewing and approving the proposal. So, what
>> do we need to do to make it in 1.5.9? Or did you already check it in
>> there?
>>
>> Thanks,
>>
>> Alec
>>
>> On Thu, Nov 1, 2012 at 6:04 PM, Sebastien  wrote:
>> > Hi Alec,
>> >
>> > Thanks for having taking time to write the code snippet bellow, I better
>> > understand your idea!..
>> > I did not realized you didn't want to use getCssClass, but I think it is
>> > good solution anyway! It is easy for the user to replace
>> > message.isInfo() ? ".my-ui-info" : ".my-ui-error"
>> > by its custom method: getMessageCssClass(message.getLevel()) or something
>> > equivalent as we spoke before, so that's fine for me. Well done!
>> >
>> > Thanks again & best regards,
>> > Sebastien.
>> >
>> >
>> > On Thu, Nov 1, 2012 at 11:57 PM, Alec Swan  wrote:
>> >
>> >> @Sebastien The scenario you described it exactly the scenario I used
>> >> to start this thread. Please read my original post.
>> >>
>> >> So, the solution is to change Wicket code
>> >> FeedbackPanel.MessageListView#populateItem to use  AttributeAppender
>> >> instead of AttributeModifier as I suggested in my previous message. In
>> >> addition, your code should override newMessageDisplayComponent(..) as
>> >> follows:
>> >>
>> >> protected Component newMessageDisplayComponent(String id,
>> >> FeedbackMessage message) {
>> >>   Component label = super.newMessageDisplayComponent(id, message);
>> >>   label.add(new AttributeAppender("class", new
>> >> Model(message.isInfo() ? ".my-ui-info" : ".my-ui-error"), "
>> >> "));
>> >>   return label;
>> >> }
>> >>
>> >> This will set the style you want on  and will leave 
>> unmodified.
>> >>
>> >> Why doesn't it work for you?
>> >>
>> >> Thanks,
>> >>
>> >> Alec
>> >>
>> >> On Thu, Nov 1, 2012 at 9:55 AM, Sebastien  wrote:
>> >> > Hi,
>> >> >
>> >> > @Alec, the use case is the following:
>> >> > Consider you are not the "owner" of the css-class(es). The css
>> provider
>> >> (a
>> >> > ui-framework, a designer, ...) will provide one style by message level
>> >> > (let's say .my-ui-warn, .my-ui-error, .my-ui-info, etc). So you will
>> >> > override #getCssClass in order to return the corresponding css-class
>> >> > depending of the level type (supplied as method's argument). But...
>> the
>> >> > provided class/style is designed to be applied *only* to one element.
>> So,
>> >> > if the css-class is applied onto both LI and SPAN, there will be a
>> style
>> >> > overlap which will result to a bad display... As the
>> >> > message-level-css-class is *always* appended to both elements, there
>> is
>> >> yet
>> >> > no other choice (I think) to have our own FeedbackPanel or extending
>> the
>> >> > existing one with the "hack" I provided earlier...
>> >> >
>> >> > @Sven: Thanks for your suggestion! It would result to a different
>> >> component
>> >> > but it is certainly more relevant...
>> >> >
>> >> > Best regards,
>> >> > Sebastien.
>> >> >
>> >> >
>> >> > On Thu, Nov 1, 2012 at 4:17 PM, Sven Meier  wrote:
>> >> >
>> >> >> If you want to group messages you can easily use multiple feedback
>> >> panels,
>> >> >> each filtering by seve

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

> Sebastien, thanks for reviewing and approving the proposal. So, what
> do we need to do to make it in 1.5.9? Or did you already check it in
> there?
>
> Thanks,
>
> Alec
>
> On Thu, Nov 1, 2012 at 6:04 PM, Sebastien  wrote:
> > Hi Alec,
> >
> > Thanks for having taking time to write the code snippet bellow, I better
> > understand your idea!..
> > I did not realized you didn't want to use getCssClass, but I think it is
> > good solution anyway! It is easy for the user to replace
> > message.isInfo() ? ".my-ui-info" : ".my-ui-error"
> > by its custom method: getMessageCssClass(message.getLevel()) or something
> > equivalent as we spoke before, so that's fine for me. Well done!
> >
> > Thanks again & best regards,
> > Sebastien.
> >
> >
> > On Thu, Nov 1, 2012 at 11:57 PM, Alec Swan  wrote:
> >
> >> @Sebastien The scenario you described it exactly the scenario I used
> >> to start this thread. Please read my original post.
> >>
> >> So, the solution is to change Wicket code
> >> FeedbackPanel.MessageListView#populateItem to use  AttributeAppender
> >> instead of AttributeModifier as I suggested in my previous message. In
> >> addition, your code should override newMessageDisplayComponent(..) as
> >> follows:
> >>
> >> protected Component newMessageDisplayComponent(String id,
> >> FeedbackMessage message) {
> >>   Component label = super.newMessageDisplayComponent(id, message);
> >>   label.add(new AttributeAppender("class", new
> >> Model(message.isInfo() ? ".my-ui-info" : ".my-ui-error"), "
> >> "));
> >>   return label;
> >> }
> >>
> >> This will set the style you want on  and will leave 
> unmodified.
> >>
> >> Why doesn't it work for you?
> >>
> >> Thanks,
> >>
> >> Alec
> >>
> >> On Thu, Nov 1, 2012 at 9:55 AM, Sebastien  wrote:
> >> > Hi,
> >> >
> >> > @Alec, the use case is the following:
> >> > Consider you are not the "owner" of the css-class(es). The css
> provider
> >> (a
> >> > ui-framework, a designer, ...) will provide one style by message level
> >> > (let's say .my-ui-warn, .my-ui-error, .my-ui-info, etc). So you will
> >> > override #getCssClass in order to return the corresponding css-class
> >> > depending of the level type (supplied as method's argument). But...
> the
> >> > provided class/style is designed to be applied *only* to one element.
> So,
> >> > if the css-class is applied onto both LI and SPAN, there will be a
> style
> >> > overlap which will result to a bad display... As the
> >> > message-level-css-class is *always* appended to both elements, there
> is
> >> yet
> >> > no other choice (I think) to have our own FeedbackPanel or extending
> the
> >> > existing one with the "hack" I provided earlier...
> >> >
> >> > @Sven: Thanks for your suggestion! It would result to a different
> >> component
> >> > but it is certainly more relevant...
> >> >
> >> > Best regards,
> >> > Sebastien.
> >> >
> >> >
> >> > On Thu, Nov 1, 2012 at 4:17 PM, Sven Meier  wrote:
> >> >
> >> >> If you want to group messages you can easily use multiple feedback
> >> panels,
> >> >> each filtering by severity.
> >> >>
> >> >> Sven
> >> >>
> >> >> Sebastien  schrieb:
> >> >>
> >> >> >Hi,
> >> >> >
> >> >> >@Alec, unfortunately I think your workaround does not handle the
> case
> >> we
> >> >> do
> >> >> >*not* want the message-level-css-class on the SPAN, and that we
> still
> >> want
> >> >> >it on t

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

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

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

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

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

Why doesn't it work for you?

Thanks,

Alec

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

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

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

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

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

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

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

> So, the patch can be applied to 1.5.8 and will replace
> label.add(levelModifier);
> with
> label.add(new AttributeAppender("class", replacementModel))
>
> You may want to add AttributeAppender to  as well.
>
> Alec
>
> On Wed, Oct 31, 2012 at 4:33 PM, Alec Swan  wrote:
> > I suggest that instead of overriding CSS class on the  you
> > APPEND it to existing CSS classes. This will allow the user to specify
> > their own  CSS class in newMessageDisplayComponent(..) AND will
> > support backward compatibility.
> >
> > Sounds like a win-win to me. Thoughts?
> >
> > Thanks,
> >
> > Alec
> >
> > On Wed, Oct 31, 2012 at 1:17 AM, Sven Meier  wrote:
> >> Hi,
> >>
> >> the CSS class could be changed in Wicket 7 only. Until you've migrated
> you
> >> can easily just use your own feedback component.
> >>
> >> Best regards
> >> Sven
> >>
> >>
> >> On 10/30/2012 11:24 PM, Sebastien wrote:
> >>>
> >>> Hi,
> >>>
> >>> I also agree with Martin's points. Having no css-class on the span is
> the
> >>> best solution from my point of view too.
> >>> A little concern however. I think this kind of change is not exactly
> >>> "backward compatible". Sure, it is, for the java side, but I figure
> that
> >>> *many* users have wrote their own CSS for feedback panels and this will
> >>> probably results to bad display with this change. So, I am wondering if
> >>> this change will be considered as an "API break"? If yes, will you
> apply
> >>> it
> >>> also to 1.5.x (the original demand)? And, if the new version numbering
> >>> system in place applies to 1.5.x, does that means that it should be
> 1.6.0?
> >>> You see what I mean... it could lead to some misunderstanding!..
> >>>
> >>> Also I like Sven's suggestion, but I am afraid that it will overlap
> with
> >>> #newMessageDisplayComponent(). As ListItem IS-A WebMarkupContainer, we
> >>> could do any customization from here. But, in this case (there is a new
> >>> #newMessageItem() method), the span element is not needed anymore and
> >>> therefore #newMessageDisplayComponent() neither. So, about the API
> break,
> >>> we are in situation :)
> >>>
> >>> Thanks & best regards,
> >>> Sebastien.
> >>>
> >>>
> >>> On Mon, Oct 29, 2012 at 6:18 PM, Joachim Schrod 
> wrote:
> >>>
> >>>> Hi,
> >>>>
> >>>> This would change be very well received, from my side. :-) :-)
> >>>>
> >>>> Cheers,
> >>>>  Joachim
> >>>>
> >>>>
> >>>> Martin Grigorov wrote:
> >>>>>
> >>>>> Hi,
> >>>>>
> >>>>> [X] Other suggestion: (please specify)
> >>>>>
> >>>>> Here is what I think it should be:
> >>>>> -  element should have class "feedbackPanel" (this is already
> the
> >>>>
> >>>> case)
> >>>>>
> >>>>&g

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  as well.

Alec

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

Re: Custom CSS for Feedback message is broken in 1.5

[Alec Swan]

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

Sounds like a win-win to me. Thoughts?

Thanks,

Alec

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

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

Re: Custom CSS for Feedback message is broken in 1.5

[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  wrote:


Hi,

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

Cheers,
 Joachim


Martin Grigorov wrote:

Hi,

[X] Other suggestion: (please specify)

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

case)

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


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

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


On Sun, Oct 28, 2012 at 6:03 PM, Sebastien  wrote:

Hi,

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

preferred

choice of their (beloved) users.**

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

marked

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

names. I

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

Thanks in advance for your contribution,
Sebastien

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






 Joachim

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


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





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

Re: Custom CSS for Feedback message is broken in 1.5

[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  wrote:

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

Re: Custom CSS for Feedback message is broken in 1.5

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



Joachim

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


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

Re: Custom CSS for Feedback message is broken in 1.5

[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

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


On Sun, Oct 28, 2012 at 6:03 PM, Sebastien  wrote:

Hi,

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

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

Thanks in advance for your contribution,
Sebastien

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






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

Re: Custom CSS for Feedback message is broken in 1.5

[Martin Grigorov]

Hi,

[X] Other suggestion: (please specify)

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


On Sun, Oct 28, 2012 at 6:03 PM, Sebastien  wrote:
> Hi,
>
> To sum-up this thread: we have a (not huge, but still) design issue that
> annoys several users. A patch* has been provided but some questions
> remains...
> Given this, I would suggest a kind-of vote about the several points
> discussed earlier, in order to enlighten the dev-team about the preferred
> choice of their (beloved) users.**
>
> Here are some possible options:
> [ ] Please apply the patch as-is. It currently provides 2 methods
> (#getListCSSClass and #getLabelCSSClass), #getCSSClass is marked a
> deprecated until marked as private (or removed)
> [ ] Do not apply the patch as-is, #getCSSClass should be kept (not marked
> as deprecated)
> [ ] Do not apply the patch as-is, I do not agree with the 2 method names. I
> would have preferred: (please specify)
> [ ] This is not an issue; this does not need to be "corrected"
> [ ] Other suggestion: (please specify)
>
> Thanks in advance for your contribution,
> Sebastien
>
> (*) https://issues.apache.org/jira/browse/WICKET-4831
> (**) Sure, dev-team opinion is also kindly asked! :)



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

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

Re: Custom CSS for Feedback message is broken in 1.5

[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:
> 
> 
>   
>   
> 
>   Saved model [TestInputObject
> stringProperty = 'test', integerProperty = 100, doubleProperty = 20.5,
> booleanProperty = false, integerInRangeProperty = 50, urlProperty =
> http://wicket.apache.org, phoneNumberUS = (123) 456-1234,
> numberRadioChoice = 1, numbersCheckgroup [], numberRadioGroup= null,
> selected sites {], lines [line one, line two, line three]]
> 
>   
> 
> 
> 
> Why do we need the new getters when you can just use normal CSS selectors:
> 
> div.feedbackPanel {}
> div.feedbackPanel span {}
> ul.feedbackPanel {}
> li.feedbackPanelINFO {}
> span.feedbackPanelINFO {}
> 
> What is the big CSS/HTML design problem that I miss ?

That feedbackPanelINFO is set both on li and on span.

In my current project, CSS styling is not done by us, but by a
designer and is shared over several projects, most of them who
don't use Wicket. The CSS styling is just for feedbackPanelINFO,
not for li.feedbackPanelINFO.

AFAIU, similar problems appear in portlet situations, or in other
situations where you don't control CSS fully. As Alec mentions,
Twitter bootstrap is an other example.

Btw, I never wrote that this is a "big" design problem. I just say
that IMHO it's an existing one that goes beyond a single project.
The standard way we cope in our projects is a more-or-less empty
FeedbackPanel subclass with replaced HTML. Not pretty, as we ignore
module boundaries for wicket identifiers; but the alternative --
copying the complete code of FeedbackPanel to a project specific
class -- wouldn't be good either.

Joachim

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


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

Re: Custom CSS for Feedback message is broken in 1.5

[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

[Martin Grigorov]

Hi,

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



  

  Saved model [TestInputObject
stringProperty = 'test', integerProperty = 100, doubleProperty = 20.5,
booleanProperty = false, integerInRangeProperty = 50, urlProperty =
http://wicket.apache.org, phoneNumberUS = (123) 456-1234,
numberRadioChoice = 1, numbersCheckgroup [], numberRadioGroup= null,
selected sites {], lines [line one, line two, line three]]

  



Why do we need the new getters when you can just use normal CSS selectors:

div.feedbackPanel {}
div.feedbackPanel span {}
ul.feedbackPanel {}
li.feedbackPanelINFO {}
span.feedbackPanelINFO {}

What is the big CSS/HTML design problem that I miss ?

On Thu, Oct 25, 2012 at 2:07 AM, Joachim Schrod  wrote:
> Paul Bors wrote:
>> Yes, but how would that affect other projects that do expect the CSS to be
>> applied to the LI or SPAN?
>> Come to think about it, I could very simple replace the content of both with
>> my own panels right?
>>
>> I think this is a project specific requirement
>
> I just want to add my voice that it's not a project specific
> requirement, but a sound design change that resolves a design bug.
>
> That a CSS class applies both to LI and to below-SPAN element, is
> clearly not appropriate for almost all situations. The proposed
> change even keeps that, for backward-compatibility.
>
> Of course, one can subclass FeedbackPanel and sustitute the HTML
> code. We do it in all projects. But this is a workaround for a bug
> in Wicket's HTML/CSS/interface design, and not a to-be-continued asset.
>
> Just my 0.03€ (adjusted for inflation),
> Joachim
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>



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

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

Re: Custom CSS for Feedback message is broken in 1.5

[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

[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  wrote:

> Yes, but how would that affect other projects that do expect the CSS to be
> applied to the LI or SPAN?
> Come to think about it, I could very simple replace the content of both
> with
> my own panels right?
>
> I think this is a project specific requirement and as such should be
> handled
> by extending from Wicket's code and adjusting the behavior as per the
> specific project requirements thus I don't see a real need for WICKET-4831
> "Split custom CSS for Feedback message (list and label)".
>
> If that's the case, then I should start flooding the wicket Jira queue with
> all the specific needs for my own projects.
>
> I only gave an example of how one can have full control with little code :)
>
>  ~ Thank you,
> Paul Bors
>
> -Original Message-
> From: Sven Meier [mailto:s...@meiers.net]
> Sent: Wednesday, October 24, 2012 3:04 AM
> To: users@wicket.apache.org
> Subject: Re: Custom CSS for Feedback message is broken in 1.5
>
> The point is that he does *not* want getCSSClass() to be applied to the
> .
>
> Sven
>
> On 10/24/2012 12:24 AM, Paul Bors wrote:
> > There is nothing stopping you from extending from the FeedBackPanel
> > and override the HTML the Wicket component is using.
> >
> > This is how we did it.
> >
> > The HTML:
> > http://wicket.apache.org";>
> >  
> >  
> >  
> >  [Feedback message(s)]
> >  
> >  
> >  
> > 
> >
> > And the Java:
> > import org.apache.wicket.feedback.IFeedbackMessageFilter;
> > import org.apache.wicket.markup.html.panel.FeedbackPanel;
> >
> > public class MyFeedbackPanel extends FeedbackPanel {
> >  private static final long serialVersionUID = 1L;
> >
> >  public MyFeedbackPanel (String id) {
> >  this(id, null);
> >  }
> >
> >  public MyFeedbackPanel (String id, IFeedbackMessageFilter filter) {
> >  super(id, filter);
> >  setOutputMarkupId(true);
> >  }
> > }
> >
> > Our application wide CSS:
> >
> > /* FEEDBACK MESSAGES */
> >
> > .feedbackMessages {
> >  padding-left: 0;
> >  padding-top: 0;
> >  text-align: left;
> >  margin-left: 0;
> >  margin-top: 0;
> >  padding-bottom: 1em;
> > }
> >
> > .feedbackMessages div {
> >  padding: 0.5em;
> >  font-size: xx-small;
> >  border: none;
> > }
> >
> > .feedbackMessages div.feedbackPanelERROR {
> >  background-color: lightsalmon;
> >  border: 1px solid darkred;
> > }
> >
> > .feedbackMessages div.feedbackPanelWARNING {
> >  background-color: #FFB90F;
> >  border: 1px solid darkgoldenrod;
> > }
> >
> > .feedbackMessages div.feedbackPanelINFO {
> >  background-color: lightgreen;
> >  border: 1px solid darkgreen;
> > }
> >
> > This code was written for Wicket 1.3.x and migrated to 1.5.x w/o any
> > changes (we're not yet up to 6.x).
> >
> > ~ Thank you,
> >Paul Bors
> >
> > -Original Message-
> > From: Alec Swan [mailto:alecs...@gmail.com]
> > Sent: Tuesday, October 23, 2012 6:08 PM
> > To: users@wicket.apache.org
> > Subject: Re: Custom CSS for Feedback message is broken in 1.5
> >
> > Sebastien, List, ListItem and Label make sense to me and match the
> > terms used in Fee

RE: Custom CSS for Feedback message is broken in 1.5

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

Sven

On 10/24/2012 12:24 AM, Paul Bors wrote:
> There is nothing stopping you from extending from the FeedBackPanel 
> and override the HTML the Wicket component is using.
>
> This is how we did it.
>
> The HTML:
> http://wicket.apache.org";>
>  
>      
>  
>  [Feedback message(s)]
>  
>  
>  
> 
>
> And the Java:
> import org.apache.wicket.feedback.IFeedbackMessageFilter;
> import org.apache.wicket.markup.html.panel.FeedbackPanel;
>
> public class MyFeedbackPanel extends FeedbackPanel {
>  private static final long serialVersionUID = 1L;
>  
>  public MyFeedbackPanel (String id) {
>  this(id, null);
>  }
>  
>  public MyFeedbackPanel (String id, IFeedbackMessageFilter filter) {
>  super(id, filter);
>  setOutputMarkupId(true);
>  }
> }
>
> Our application wide CSS:
>
> /* FEEDBACK MESSAGES */
>
> .feedbackMessages {
>  padding-left: 0;
>  padding-top: 0;
>  text-align: left;
>  margin-left: 0;
>  margin-top: 0;
>  padding-bottom: 1em;
> }
>
> .feedbackMessages div {
>  padding: 0.5em;
>  font-size: xx-small;
>  border: none;
> }
>
> .feedbackMessages div.feedbackPanelERROR {
>  background-color: lightsalmon;
>  border: 1px solid darkred;
> }
>
> .feedbackMessages div.feedbackPanelWARNING {
>  background-color: #FFB90F;
>  border: 1px solid darkgoldenrod;
> }
>
> .feedbackMessages div.feedbackPanelINFO {
>  background-color: lightgreen;
>  border: 1px solid darkgreen;
> }
>
> This code was written for Wicket 1.3.x and migrated to 1.5.x w/o any 
> changes (we're not yet up to 6.x).
>
> ~ Thank you,
>Paul Bors
>
> -Original Message-
> From: Alec Swan [mailto:alecs...@gmail.com]
> Sent: Tuesday, October 23, 2012 6:08 PM
> To: users@wicket.apache.org
> Subject: Re: Custom CSS for Feedback message is broken in 1.5
>
> Sebastien, List, ListItem and Label make sense to me and match the 
> terms used in FeedbackPanel class. However, I try not to get too hung 
> up on naming for the sake of making progress :)
>
> On Tue, Oct 23, 2012 at 3:39 PM, Sebastien  wrote:
>> Alec, you are right, I did thought about that.
>>
>> My reflection was that getListCSS applies to list *element* (li) and 
>> it is quite easy to understand that getLabelCSS (which applies to the
>> label) stands for the message itself (which is a span element).
>>
>> But in another hand we can imagine that these naming are related to 
>> wicket
>> *component* instead; so, it is true that it would technically best to 
>> have getListItemCSS (applies to ListItem) and getLabelCSS (applies to
> Label).
>> But what if the user overrides #newMessageDisplayComponent and return 
>> something other than a Label? A Panel for instance? Maybe getLabelCSS 
>> appears to not be logical anymore in this context: we have a 
>> getListItemCSS which still applies to a ListItem and a getLabelCSS 
>> which applies to... a Panel.
>>
>> In another hand (again), we can also imagine that the HTML markup is 
>> getting "overridden" (while extending FeedbackPanel), li and span 
>> elements may have been replaced by other elements (2 divs for 
>> instance)... So getListCSS may also not be logical in this context, 
>> and would have better been getContainerCSS or something like that...
>>
>> Not easy to find right naming; its a kind of Ouroboros* ** discussion 
>> in this case...
>> But at the end, will the user better understand getListCSS or 
>> getListItemCSS? Also, is getLab

Re: Custom CSS for Feedback message is broken in 1.5

[Sven Meier]

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


Sven

On 10/24/2012 12:24 AM, Paul Bors wrote:

There is nothing stopping you from extending from the FeedBackPanel and
override the HTML the Wicket component is using.

This is how we did it.

The HTML:
http://wicket.apache.org";>
 
 
 
     [Feedback message(s)]
 
 
 


And the Java:
import org.apache.wicket.feedback.IFeedbackMessageFilter;
import org.apache.wicket.markup.html.panel.FeedbackPanel;

public class MyFeedbackPanel extends FeedbackPanel {
 private static final long serialVersionUID = 1L;
 
 public MyFeedbackPanel (String id) {

 this(id, null);
 }
 
 public MyFeedbackPanel (String id, IFeedbackMessageFilter filter) {

 super(id, filter);
 setOutputMarkupId(true);
 }
}

Our application wide CSS:

/* FEEDBACK MESSAGES */

.feedbackMessages {
 padding-left: 0;
 padding-top: 0;
 text-align: left;
 margin-left: 0;
 margin-top: 0;
 padding-bottom: 1em;
}

.feedbackMessages div {
 padding: 0.5em;
 font-size: xx-small;
 border: none;
}

.feedbackMessages div.feedbackPanelERROR {
 background-color: lightsalmon;
 border: 1px solid darkred;
}

.feedbackMessages div.feedbackPanelWARNING {
 background-color: #FFB90F;
 border: 1px solid darkgoldenrod;
}

.feedbackMessages div.feedbackPanelINFO {
 background-color: lightgreen;
 border: 1px solid darkgreen;
}

This code was written for Wicket 1.3.x and migrated to 1.5.x w/o any changes
(we're not yet up to 6.x).

~ Thank you,
   Paul Bors

-Original Message-
From: Alec Swan [mailto:alecs...@gmail.com]
Sent: Tuesday, October 23, 2012 6:08 PM
To: users@wicket.apache.org
Subject: Re: Custom CSS for Feedback message is broken in 1.5

Sebastien, List, ListItem and Label make sense to me and match the terms
used in FeedbackPanel class. However, I try not to get too hung up on naming
for the sake of making progress :)

On Tue, Oct 23, 2012 at 3:39 PM, Sebastien  wrote:

Alec, you are right, I did thought about that.

My reflection was that getListCSS applies to list *element* (li) and
it is quite easy to understand that getLabelCSS (which applies to the
label) stands for the message itself (which is a span element).

But in another hand we can imagine that these naming are related to
wicket
*component* instead; so, it is true that it would technically best to
have getListItemCSS (applies to ListItem) and getLabelCSS (applies to

Label).

But what if the user overrides #newMessageDisplayComponent and return
something other than a Label? A Panel for instance? Maybe getLabelCSS
appears to not be logical anymore in this context: we have a
getListItemCSS which still applies to a ListItem and a getLabelCSS
which applies to... a Panel.

In another hand (again), we can also imagine that the HTML markup is
getting "overridden" (while extending FeedbackPanel), li and span
elements may have been replaced by other elements (2 divs for
instance)... So getListCSS may also not be logical in this context,
and would have better been getContainerCSS or something like that...

Not easy to find right naming; its a kind of Ouroboros* ** discussion
in this case...
But at the end, will the user better understand getListCSS or
getListItemCSS? Also, is getLabelCSS the best? What about getMessageCSS?

That's all open questions... I wish you a good night with that! ;)
Sebastien

* http://en.wikipedia.org/wiki/Ouroboros
** I am pretty sure this term has previously been used in this mailing
list but I don't remember who... So there is a credit for someone
somewhere :)


On Tue, Oct 23, 2012 at 9:15 PM, Alec Swan  wrote:


Technically it should be getListItemCSS, not getListCSS. Or maybe
have all three getListCSS, getListItemCSS and getLabelCSS

On Mon, Oct 22, 2012 at 12:46 PM, Sebastien  wrote:

Done, https://issues.apache.org/jira/browse/WICKET-4831
Please let me know if your encounter any issue (wrong base code for
instance) or if you have any questions...

Thanks,
Sebastien.

On Mon, Oct 22, 2012 at 8:06 PM, Sven Meier  wrote:


Please open a Jira issue and provide a patch as you suggested.

Thanks
Sven



On 10/21/2012 01:06 AM, Sebastien wrote:


Sven,

If you agree to have two methods: getListCSSClass and
getLabelCSSClass (which apply respectively on li and span), and
mark getCSSClass as deprecated (until marked as private), then
the path is ready for branch wicket-1.5.x. I am waiting for your
go-ahead to send the patch

somewhere

or
submit the pull request on github.

If you do not agree, please tell me what I can do.

Thanks & best regards,
Sebastien.





--**--**-


To unsubscribe, e-mail: users-unsubscribe@wicket.**apache.org<

users-unsubscr...@wicket.apache.org>

For additional com

RE: Custom CSS for Feedback message is broken in 1.5

[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:
http://wicket.apache.org";>



    [Feedback message(s)]





And the Java:
import org.apache.wicket.feedback.IFeedbackMessageFilter;
import org.apache.wicket.markup.html.panel.FeedbackPanel;

public class MyFeedbackPanel extends FeedbackPanel {
private static final long serialVersionUID = 1L;

public MyFeedbackPanel (String id) {
this(id, null);
}

public MyFeedbackPanel (String id, IFeedbackMessageFilter filter) {
super(id, filter);
setOutputMarkupId(true);
}
}

Our application wide CSS:

/* FEEDBACK MESSAGES */

.feedbackMessages {
padding-left: 0;
padding-top: 0;
text-align: left;
margin-left: 0;
margin-top: 0;
padding-bottom: 1em;
}

.feedbackMessages div {
padding: 0.5em;
font-size: xx-small;
border: none;
}

.feedbackMessages div.feedbackPanelERROR {
background-color: lightsalmon;
border: 1px solid darkred;
}

.feedbackMessages div.feedbackPanelWARNING {
background-color: #FFB90F;
border: 1px solid darkgoldenrod;
}

.feedbackMessages div.feedbackPanelINFO {
background-color: lightgreen;
border: 1px solid darkgreen;
}

This code was written for Wicket 1.3.x and migrated to 1.5.x w/o any changes
(we're not yet up to 6.x).

~ Thank you,
  Paul Bors

-Original Message-
From: Alec Swan [mailto:alecs...@gmail.com] 
Sent: Tuesday, October 23, 2012 6:08 PM
To: users@wicket.apache.org
Subject: Re: Custom CSS for Feedback message is broken in 1.5

Sebastien, List, ListItem and Label make sense to me and match the terms
used in FeedbackPanel class. However, I try not to get too hung up on naming
for the sake of making progress :)

On Tue, Oct 23, 2012 at 3:39 PM, Sebastien  wrote:
> Alec, you are right, I did thought about that.
>
> My reflection was that getListCSS applies to list *element* (li) and 
> it is quite easy to understand that getLabelCSS (which applies to the 
> label) stands for the message itself (which is a span element).
>
> But in another hand we can imagine that these naming are related to 
> wicket
> *component* instead; so, it is true that it would technically best to 
> have getListItemCSS (applies to ListItem) and getLabelCSS (applies to
Label).
> But what if the user overrides #newMessageDisplayComponent and return 
> something other than a Label? A Panel for instance? Maybe getLabelCSS 
> appears to not be logical anymore in this context: we have a 
> getListItemCSS which still applies to a ListItem and a getLabelCSS 
> which applies to... a Panel.
>
> In another hand (again), we can also imagine that the HTML markup is 
> getting "overridden" (while extending FeedbackPanel), li and span 
> elements may have been replaced by other elements (2 divs for 
> instance)... So getListCSS may also not be logical in this context, 
> and would have better been getContainerCSS or something like that...
>
> Not easy to find right naming; its a kind of Ouroboros* ** discussion 
> in this case...
> But at the end, will the user better understand getListCSS or 
> getListItemCSS? Also, is getLabelCSS the best? What about getMessageCSS?
>
> That's all open questions... I wish you a good night with that! ;) 
> Sebastien
>
> * http://en.wikipedia.org/wiki/Ouroboros
> ** I am pretty sure this term has previously been used in this mailing 
> list but I don't remember who... So there is a credit for someone 
> somewhere :)
>
>
> On Tue, Oct 23, 2012 at 9:15 PM, Alec Swan  wrote:
>
>> Technically it should be getListItemCSS, not getListCSS. Or maybe 
>> have all three getListCSS, getListItemCSS and getLabelCSS
>>
>> On Mon, Oct 22, 2012 at 12:46 PM, Sebastien  wrote:
>> > Done, https://issues.apache.org/jira/browse/WICKET-4831
>> > Please let me know if your encounter any issue (wrong base code for
>> > instance) or if you have any questions...
>> >
>> > Thanks,
>> > Sebastien.
>> >
>> > On Mon, Oct 22, 2012 at 8:06 PM, Sven Meier  wrote:
>> >
>> >> Please open a Jira issue and provide a patch as you suggested.
>> >>
>> >> Thanks
>> >> Sven
>> >>
>> >>
>> >>
>> >> On 10/21/2012 01:06 AM, Sebastien wrote:
>> >>
>> >>> Sven,
>> >>>
>> >>> If you agree to have two methods: getListCSSClass and 
>> >>> getLabelCSSClass (which apply respectively on li and span), and 
>> >>> mark getCSSClass as deprecated (until marked as private), then 
>> >>&

Re: Custom CSS for Feedback message is broken in 1.5

[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  wrote:
> Alec, you are right, I did thought about that.
>
> My reflection was that getListCSS applies to list *element* (li) and it is
> quite easy to understand that getLabelCSS (which applies to the label)
> stands for the message itself (which is a span element).
>
> But in another hand we can imagine that these naming are related to wicket
> *component* instead; so, it is true that it would technically best to have
> getListItemCSS (applies to ListItem) and getLabelCSS (applies to Label).
> But what if the user overrides #newMessageDisplayComponent and return
> something other than a Label? A Panel for instance? Maybe getLabelCSS
> appears to not be logical anymore in this context: we have a getListItemCSS
> which still applies to a ListItem and a getLabelCSS which applies to... a
> Panel.
>
> In another hand (again), we can also imagine that the HTML markup is
> getting "overridden" (while extending FeedbackPanel), li and span elements
> may have been replaced by other elements (2 divs for instance)... So
> getListCSS may also not be logical in this context, and would have better
> been getContainerCSS or something like that...
>
> Not easy to find right naming; its a kind of Ouroboros* ** discussion in
> this case...
> But at the end, will the user better understand getListCSS or
> getListItemCSS? Also, is getLabelCSS the best? What about getMessageCSS?
>
> That's all open questions... I wish you a good night with that! ;)
> Sebastien
>
> * http://en.wikipedia.org/wiki/Ouroboros
> ** I am pretty sure this term has previously been used in this mailing list
> but I don't remember who... So there is a credit for someone somewhere :)
>
>
> On Tue, Oct 23, 2012 at 9:15 PM, Alec Swan  wrote:
>
>> Technically it should be getListItemCSS, not getListCSS. Or maybe have
>> all three getListCSS, getListItemCSS and getLabelCSS
>>
>> On Mon, Oct 22, 2012 at 12:46 PM, Sebastien  wrote:
>> > Done, https://issues.apache.org/jira/browse/WICKET-4831
>> > Please let me know if your encounter any issue (wrong base code for
>> > instance) or if you have any questions...
>> >
>> > Thanks,
>> > Sebastien.
>> >
>> > On Mon, Oct 22, 2012 at 8:06 PM, Sven Meier  wrote:
>> >
>> >> Please open a Jira issue and provide a patch as you suggested.
>> >>
>> >> Thanks
>> >> Sven
>> >>
>> >>
>> >>
>> >> On 10/21/2012 01:06 AM, Sebastien wrote:
>> >>
>> >>> Sven,
>> >>>
>> >>> If you agree to have two methods: getListCSSClass and getLabelCSSClass
>> >>> (which apply respectively on li and span), and mark getCSSClass as
>> >>> deprecated (until marked as private), then the path is ready for branch
>> >>> wicket-1.5.x. I am waiting for your go-ahead to send the patch
>> somewhere
>> >>> or
>> >>> submit the pull request on github.
>> >>>
>> >>> If you do not agree, please tell me what I can do.
>> >>>
>> >>> Thanks & best regards,
>> >>> Sebastien.
>> >>>
>> >>>
>> >>
>> >>
>> --**--**-
>> >> To unsubscribe, e-mail: users-unsubscribe@wicket.**apache.org<
>> users-unsubscr...@wicket.apache.org>
>> >> For additional commands, e-mail: users-h...@wicket.apache.org
>> >>
>> >>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>

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

Re: Custom CSS for Feedback message is broken in 1.5

[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  wrote:

> Technically it should be getListItemCSS, not getListCSS. Or maybe have
> all three getListCSS, getListItemCSS and getLabelCSS
>
> On Mon, Oct 22, 2012 at 12:46 PM, Sebastien  wrote:
> > Done, https://issues.apache.org/jira/browse/WICKET-4831
> > Please let me know if your encounter any issue (wrong base code for
> > instance) or if you have any questions...
> >
> > Thanks,
> > Sebastien.
> >
> > On Mon, Oct 22, 2012 at 8:06 PM, Sven Meier  wrote:
> >
> >> Please open a Jira issue and provide a patch as you suggested.
> >>
> >> Thanks
> >> Sven
> >>
> >>
> >>
> >> On 10/21/2012 01:06 AM, Sebastien wrote:
> >>
> >>> Sven,
> >>>
> >>> If you agree to have two methods: getListCSSClass and getLabelCSSClass
> >>> (which apply respectively on li and span), and mark getCSSClass as
> >>> deprecated (until marked as private), then the path is ready for branch
> >>> wicket-1.5.x. I am waiting for your go-ahead to send the patch
> somewhere
> >>> or
> >>> submit the pull request on github.
> >>>
> >>> If you do not agree, please tell me what I can do.
> >>>
> >>> Thanks & best regards,
> >>> Sebastien.
> >>>
> >>>
> >>
> >>
> --**--**-
> >> To unsubscribe, e-mail: users-unsubscribe@wicket.**apache.org<
> users-unsubscr...@wicket.apache.org>
> >> For additional commands, e-mail: users-h...@wicket.apache.org
> >>
> >>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

Re: Custom CSS for Feedback message is broken in 1.5

[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  wrote:
> Done, https://issues.apache.org/jira/browse/WICKET-4831
> Please let me know if your encounter any issue (wrong base code for
> instance) or if you have any questions...
>
> Thanks,
> Sebastien.
>
> On Mon, Oct 22, 2012 at 8:06 PM, Sven Meier  wrote:
>
>> Please open a Jira issue and provide a patch as you suggested.
>>
>> Thanks
>> Sven
>>
>>
>>
>> On 10/21/2012 01:06 AM, Sebastien wrote:
>>
>>> Sven,
>>>
>>> If you agree to have two methods: getListCSSClass and getLabelCSSClass
>>> (which apply respectively on li and span), and mark getCSSClass as
>>> deprecated (until marked as private), then the path is ready for branch
>>> wicket-1.5.x. I am waiting for your go-ahead to send the patch somewhere
>>> or
>>> submit the pull request on github.
>>>
>>> If you do not agree, please tell me what I can do.
>>>
>>> Thanks & best regards,
>>> Sebastien.
>>>
>>>
>>
>> --**--**-
>> To unsubscribe, e-mail: 
>> users-unsubscribe@wicket.**apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>

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

Re: Custom CSS for Feedback message is broken in 1.5

[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  wrote:

> Please open a Jira issue and provide a patch as you suggested.
>
> Thanks
> Sven
>
>
>
> On 10/21/2012 01:06 AM, Sebastien wrote:
>
>> Sven,
>>
>> If you agree to have two methods: getListCSSClass and getLabelCSSClass
>> (which apply respectively on li and span), and mark getCSSClass as
>> deprecated (until marked as private), then the path is ready for branch
>> wicket-1.5.x. I am waiting for your go-ahead to send the patch somewhere
>> or
>> submit the pull request on github.
>>
>> If you do not agree, please tell me what I can do.
>>
>> Thanks & best regards,
>> Sebastien.
>>
>>
>
> --**--**-
> To unsubscribe, e-mail: 
> users-unsubscribe@wicket.**apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

Re: Custom CSS for Feedback message is broken in 1.5

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

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

[Alec Swan]

Because if you use Twitter bootstrap and add "alert alert-info" CSS
classes, then it's not going to look nice if it's applied to  and
.

On Sat, Oct 20, 2012 at 3:05 PM, Sven Meier  wrote:
> I was just going to ask you why you don't overwrite #getCSSClass().
>
> What harm does it if the CSS class is on the  too?
>
> Sven
>
>
> On 10/20/2012 11:01 PM, Alec Swan wrote:
>>
>> Note that I need to set CSS styles on the label () and not the
>> list item () and hence cannot override getCSSClass() because it is
>> applied to both.
>>
>> On Sat, Oct 20, 2012 at 2:58 PM, Alec Swan  wrote:
>>>
>>> Hello,
>>>
>>> This Wiki page explains how to add custom CSS styles to Feedback
>>> messages in 1.4+:
>>> https://cwiki.apache.org/WICKET/css-enabled-feedback-panel.html
>>>
>>> Basically, it suggests that you override
>>> FeedbackPanel#newMessageDisplayComponent(..) method and add the custom
>>> CSS class to the component before returning it.
>>>
>>> However, this approach does not work in 1.5 because
>>> FeedbackPanel.MessageListView#populateItem calls
>>> FeedbackPanel#newMessageDisplayComponent(..) and then immediately adds
>>> an AttributeModifier that replaces CSS class that was set inside
>>> newMessageDisplayComponent().
>>>
>>> Is this a bug or Wiki is wrong?
>>> Is there any workaround without creating a custom FeedbackPanel?
>>>
>>> Thanks,
>>>
>>> Alec
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>

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

Re: Custom CSS for Feedback message is broken in 1.5

[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");
Iterator iterator = messages.iterator();

while (iterator.hasNext())
{
Component component = iterator.next().get("message");
//iterator.next() returns the ListItem

if (component != null)
{
component.add(AttributeModifier.remove("class"));
}
}
}

Best regards,
Sebastien.


On Sat, Oct 20, 2012 at 11:05 PM, Sven Meier  wrote:

> I was just going to ask you why you don't overwrite #getCSSClass().
>
> What harm does it if the CSS class is on the  too?
>
> Sven
>
>
> On 10/20/2012 11:01 PM, Alec Swan wrote:
>
>> Note that I need to set CSS styles on the label () and not the
>> list item () and hence cannot override getCSSClass() because it is
>> applied to both.
>>
>> On Sat, Oct 20, 2012 at 2:58 PM, Alec Swan  wrote:
>>
>>> Hello,
>>>
>>> This Wiki page explains how to add custom CSS styles to Feedback
>>> messages in 1.4+:
>>> https://cwiki.apache.org/**WICKET/css-enabled-feedback-**panel.html
>>>
>>> Basically, it suggests that you override
>>> FeedbackPanel#**newMessageDisplayComponent(..) method and add the custom
>>> CSS class to the component before returning it.
>>>
>>> However, this approach does not work in 1.5 because
>>> FeedbackPanel.MessageListView#**populateItem calls
>>> FeedbackPanel#**newMessageDisplayComponent(..) and then immediately adds
>>> an AttributeModifier that replaces CSS class that was set inside
>>> newMessageDisplayComponent().
>>>
>>> Is this a bug or Wiki is wrong?
>>> Is there any workaround without creating a custom FeedbackPanel?
>>>
>>> Thanks,
>>>
>>> Alec
>>>
>> --**--**-
>> To unsubscribe, e-mail: 
>> users-unsubscribe@wicket.**apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>
>
> --**--**-
> To unsubscribe, e-mail: 
> users-unsubscribe@wicket.**apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

Re: Custom CSS for Feedback message is broken in 1.5

[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  too?

Sven

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

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

On Sat, Oct 20, 2012 at 2:58 PM, Alec Swan  wrote:

Hello,

This Wiki page explains how to add custom CSS styles to Feedback
messages in 1.4+:
https://cwiki.apache.org/WICKET/css-enabled-feedback-panel.html

Basically, it suggests that you override
FeedbackPanel#newMessageDisplayComponent(..) method and add the custom
CSS class to the component before returning it.

However, this approach does not work in 1.5 because
FeedbackPanel.MessageListView#populateItem calls
FeedbackPanel#newMessageDisplayComponent(..) and then immediately adds
an AttributeModifier that replaces CSS class that was set inside
newMessageDisplayComponent().

Is this a bug or Wiki is wrong?
Is there any workaround without creating a custom FeedbackPanel?

Thanks,

Alec

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




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

Re: Custom CSS for Feedback message is broken in 1.5

[Alec Swan]

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

On Sat, Oct 20, 2012 at 2:58 PM, Alec Swan  wrote:
> Hello,
>
> This Wiki page explains how to add custom CSS styles to Feedback
> messages in 1.4+:
> https://cwiki.apache.org/WICKET/css-enabled-feedback-panel.html
>
> Basically, it suggests that you override
> FeedbackPanel#newMessageDisplayComponent(..) method and add the custom
> CSS class to the component before returning it.
>
> However, this approach does not work in 1.5 because
> FeedbackPanel.MessageListView#populateItem calls
> FeedbackPanel#newMessageDisplayComponent(..) and then immediately adds
> an AttributeModifier that replaces CSS class that was set inside
> newMessageDisplayComponent().
>
> Is this a bug or Wiki is wrong?
> Is there any workaround without creating a custom FeedbackPanel?
>
> Thanks,
>
> Alec

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

Custom CSS for Feedback message is broken in 1.5

[Alec Swan]

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: add feedback message a to new panel.

[Andrea Del Bene]

Hi,

calling error() on your new panel should work. Obviously you must have a 
FeedbackPanel somewhere on your page ;)

I have a Button, which replaces parent panel with a new panel. In the new
panel I want to display an error/warn/info, but I can't seem to figure out
how. I've tried with getSession.error(..), but that ain't working.

What's the best way to do this? Should I use an AjaxButton instead for
instance?

--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/add-feedback-message-a-to-new-panel-tp4640997.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

add feedback message a to new panel.

[Taag]

I have a Button, which replaces parent panel with a new panel. In the new
panel I want to display an error/warn/info, but I can't seem to figure out
how. I've tried with getSession.error(..), but that ain't working.

What's the best way to do this? Should I use an AjaxButton instead for
instance?

--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/add-feedback-message-a-to-new-panel-tp4640997.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: Show feedback message from modal window in parent page

[heapifyman]

Hi,

I am using wicket 1.5 and I had already tried adding the page-level
FeedbackPanel in the onSubmit() response - to no avail.
But Session#info() seens to be doing the trick.

Thanks for the help!

Philip


2011/10/3 Dan Retzlaff 

> I'm looking at 1.4's WebSession#cleanupFeedbackMessages(), and it looks
> like
> only feedback messages associated with a component are always cleared. So
> if
> you associate the message with the Session itself (Session#info(...)), and
> make sure no FeedbackPanels are rendered in the onSubmit() response, they
> should still be available for your close button callback response.
>
> A hacky solution might be including the page-level FeedbackPanel in the
> onSubmit() response, and *not* in the close button callback response.
>
> Let us know if you come up with a better solution.
>
> On Mon, Oct 3, 2011 at 8:57 AM, heapifyman  wrote:
>
> >
> > Ok, that I understand. Do you have an idea how to circumvent this and get
> > the feedback message into the parent page?
> >
> >
> > Am 03.10.2011 um 17:51 schrieb Dan Retzlaff:
> >
> >
> >  We use our own modal window class so I'm not sure what the best way to
> go
> >> is. But I can probably explain what's happening. The onSubmit request
> >> renders the feedback into the modal, then clears the messages from the
> >> session. Then in a separate close button callback request you're
> >> re-rendering the page-level FeedbackPanel but at that point the feedback
> >> messages are gone.
> >>
> >> On Mon, Oct 3, 2011 at 8:44 AM, heapifyman 
> wrote:
> >>
> >>  In the ModalWindow I have an AjaxButton in whose onSubmit method I
> >>> call ModalWindow.closeCurrent(**target);
> >>>
> >>> Is that not the right way to go?
> >>>
> >>>
> >>> 2011/9/30 Dan Retzlaff 
> >>>
> >>>  Each FeedbackPanel rendered in a response includes all messages
> >>>> generated
> >>>> during that request. The messages are then cleared from the session
> and
> >>>> won't be included in subsequent responses. Are you closing the modal
> in
> >>>> a
> >>>> way that immediately generates a second request?
> >>>>
> >>>> Dan
> >>>>
> >>>> On Fri, Sep 30, 2011 at 9:02 AM, heapifyman 
> >>>>
> >>> wrote:
> >>>
> >>>>
> >>>>  Hello,
> >>>>>
> >>>>> I have a page that contains a list of entries and a modal window
> opened
> >>>>> from
> >>>>> that page. The modal window contains a form to add new entries to the
> >>>>>
> >>>> list
> >>>>
> >>>>> on the parent page.
> >>>>> Submitting the form in the modal window adds the new entry, closes
> the
> >>>>> modal
> >>>>> window and updates the list of entries in the parent page.
> >>>>> This works fine.
> >>>>> However, I would like to show a "success" message on the parent page
> >>>>>
> >>>> after
> >>>>
> >>>>> I
> >>>>> submit the form in the modal window and close it.
> >>>>> This does not seem to work because I have another FeedbackPanel in
> the
> >>>>> modal
> >>>>> window for showing error messages when required fields are not
> filled.
> >>>>> This FeedbackPanel in the modal window seems to receive the success
> >>>>>
> >>>> message
> >>>>
> >>>>> instead of the FeedbackPanel on the parent page.
> >>>>>
> >>>>> I tried google and I also tried using an IFeedbackMessageFilter on
> the
> >>>>> modal
> >>>>> window's FeedbackPanel, but to no avail.
> >>>>> Any hints would be appreciated. Thanks
> >>>>>
> >>>>>
> >>>>
> >>>
> >
>

Re: Show feedback message from modal window in parent page

[Dan Retzlaff]

I'm looking at 1.4's WebSession#cleanupFeedbackMessages(), and it looks like
only feedback messages associated with a component are always cleared. So if
you associate the message with the Session itself (Session#info(...)), and
make sure no FeedbackPanels are rendered in the onSubmit() response, they
should still be available for your close button callback response.

A hacky solution might be including the page-level FeedbackPanel in the
onSubmit() response, and *not* in the close button callback response.

Let us know if you come up with a better solution.

On Mon, Oct 3, 2011 at 8:57 AM, heapifyman  wrote:

>
> Ok, that I understand. Do you have an idea how to circumvent this and get
> the feedback message into the parent page?
>
>
> Am 03.10.2011 um 17:51 schrieb Dan Retzlaff:
>
>
>  We use our own modal window class so I'm not sure what the best way to go
>> is. But I can probably explain what's happening. The onSubmit request
>> renders the feedback into the modal, then clears the messages from the
>> session. Then in a separate close button callback request you're
>> re-rendering the page-level FeedbackPanel but at that point the feedback
>> messages are gone.
>>
>> On Mon, Oct 3, 2011 at 8:44 AM, heapifyman  wrote:
>>
>>  In the ModalWindow I have an AjaxButton in whose onSubmit method I
>>> call ModalWindow.closeCurrent(**target);
>>>
>>> Is that not the right way to go?
>>>
>>>
>>> 2011/9/30 Dan Retzlaff 
>>>
>>>  Each FeedbackPanel rendered in a response includes all messages
>>>> generated
>>>> during that request. The messages are then cleared from the session and
>>>> won't be included in subsequent responses. Are you closing the modal in
>>>> a
>>>> way that immediately generates a second request?
>>>>
>>>> Dan
>>>>
>>>> On Fri, Sep 30, 2011 at 9:02 AM, heapifyman 
>>>>
>>> wrote:
>>>
>>>>
>>>>  Hello,
>>>>>
>>>>> I have a page that contains a list of entries and a modal window opened
>>>>> from
>>>>> that page. The modal window contains a form to add new entries to the
>>>>>
>>>> list
>>>>
>>>>> on the parent page.
>>>>> Submitting the form in the modal window adds the new entry, closes the
>>>>> modal
>>>>> window and updates the list of entries in the parent page.
>>>>> This works fine.
>>>>> However, I would like to show a "success" message on the parent page
>>>>>
>>>> after
>>>>
>>>>> I
>>>>> submit the form in the modal window and close it.
>>>>> This does not seem to work because I have another FeedbackPanel in the
>>>>> modal
>>>>> window for showing error messages when required fields are not filled.
>>>>> This FeedbackPanel in the modal window seems to receive the success
>>>>>
>>>> message
>>>>
>>>>> instead of the FeedbackPanel on the parent page.
>>>>>
>>>>> I tried google and I also tried using an IFeedbackMessageFilter on the
>>>>> modal
>>>>> window's FeedbackPanel, but to no avail.
>>>>> Any hints would be appreciated. Thanks
>>>>>
>>>>>
>>>>
>>>
>

Re: Show feedback message from modal window in parent page

[heapifyman]

Ok, that I understand. Do you have an idea how to circumvent this and  
get the feedback message into the parent page?



Am 03.10.2011 um 17:51 schrieb Dan Retzlaff:

We use our own modal window class so I'm not sure what the best way  
to go

is. But I can probably explain what's happening. The onSubmit request
renders the feedback into the modal, then clears the messages from the
session. Then in a separate close button callback request you're
re-rendering the page-level FeedbackPanel but at that point the  
feedback

messages are gone.

On Mon, Oct 3, 2011 at 8:44 AM, heapifyman   
wrote:



In the ModalWindow I have an AjaxButton in whose onSubmit method I
call ModalWindow.closeCurrent(target);

Is that not the right way to go?


2011/9/30 Dan Retzlaff 

Each FeedbackPanel rendered in a response includes all messages  
generated
during that request. The messages are then cleared from the  
session and
won't be included in subsequent responses. Are you closing the  
modal in a

way that immediately generates a second request?

Dan

On Fri, Sep 30, 2011 at 9:02 AM, heapifyman 

wrote:



Hello,

I have a page that contains a list of entries and a modal window  
opened

from
that page. The modal window contains a form to add new entries to  
the

list

on the parent page.
Submitting the form in the modal window adds the new entry,  
closes the

modal
window and updates the list of entries in the parent page.
This works fine.
However, I would like to show a "success" message on the parent  
page

after

I
submit the form in the modal window and close it.
This does not seem to work because I have another FeedbackPanel  
in the

modal
window for showing error messages when required fields are not  
filled.

This FeedbackPanel in the modal window seems to receive the success

message

instead of the FeedbackPanel on the parent page.

I tried google and I also tried using an IFeedbackMessageFilter  
on the

modal
window's FeedbackPanel, but to no avail.
Any hints would be appreciated. Thanks









PGP.sig
Description: Signierter Teil der Nachricht

Re: Show feedback message from modal window in parent page

[Dan Retzlaff]

We use our own modal window class so I'm not sure what the best way to go
is. But I can probably explain what's happening. The onSubmit request
renders the feedback into the modal, then clears the messages from the
session. Then in a separate close button callback request you're
re-rendering the page-level FeedbackPanel but at that point the feedback
messages are gone.

On Mon, Oct 3, 2011 at 8:44 AM, heapifyman  wrote:

> In the ModalWindow I have an AjaxButton in whose onSubmit method I
> call ModalWindow.closeCurrent(target);
>
> Is that not the right way to go?
>
>
> 2011/9/30 Dan Retzlaff 
>
> > Each FeedbackPanel rendered in a response includes all messages generated
> > during that request. The messages are then cleared from the session and
> > won't be included in subsequent responses. Are you closing the modal in a
> > way that immediately generates a second request?
> >
> > Dan
> >
> > On Fri, Sep 30, 2011 at 9:02 AM, heapifyman 
> wrote:
> >
> > > Hello,
> > >
> > > I have a page that contains a list of entries and a modal window opened
> > > from
> > > that page. The modal window contains a form to add new entries to the
> > list
> > > on the parent page.
> > > Submitting the form in the modal window adds the new entry, closes the
> > > modal
> > > window and updates the list of entries in the parent page.
> > > This works fine.
> > > However, I would like to show a "success" message on the parent page
> > after
> > > I
> > > submit the form in the modal window and close it.
> > > This does not seem to work because I have another FeedbackPanel in the
> > > modal
> > > window for showing error messages when required fields are not filled.
> > > This FeedbackPanel in the modal window seems to receive the success
> > message
> > > instead of the FeedbackPanel on the parent page.
> > >
> > > I tried google and I also tried using an IFeedbackMessageFilter on the
> > > modal
> > > window's FeedbackPanel, but to no avail.
> > > Any hints would be appreciated. Thanks
> > >
> >
>

Re: Show feedback message from modal window in parent page

[heapifyman]

In the ModalWindow I have an AjaxButton in whose onSubmit method I
call ModalWindow.closeCurrent(target);

Is that not the right way to go?


2011/9/30 Dan Retzlaff 

> Each FeedbackPanel rendered in a response includes all messages generated
> during that request. The messages are then cleared from the session and
> won't be included in subsequent responses. Are you closing the modal in a
> way that immediately generates a second request?
>
> Dan
>
> On Fri, Sep 30, 2011 at 9:02 AM, heapifyman  wrote:
>
> > Hello,
> >
> > I have a page that contains a list of entries and a modal window opened
> > from
> > that page. The modal window contains a form to add new entries to the
> list
> > on the parent page.
> > Submitting the form in the modal window adds the new entry, closes the
> > modal
> > window and updates the list of entries in the parent page.
> > This works fine.
> > However, I would like to show a "success" message on the parent page
> after
> > I
> > submit the form in the modal window and close it.
> > This does not seem to work because I have another FeedbackPanel in the
> > modal
> > window for showing error messages when required fields are not filled.
> > This FeedbackPanel in the modal window seems to receive the success
> message
> > instead of the FeedbackPanel on the parent page.
> >
> > I tried google and I also tried using an IFeedbackMessageFilter on the
> > modal
> > window's FeedbackPanel, but to no avail.
> > Any hints would be appreciated. Thanks
> >
>

Re: Show feedback message from modal window in parent page

[Dan Retzlaff]

Each FeedbackPanel rendered in a response includes all messages generated
during that request. The messages are then cleared from the session and
won't be included in subsequent responses. Are you closing the modal in a
way that immediately generates a second request?

Dan

On Fri, Sep 30, 2011 at 9:02 AM, heapifyman  wrote:

> Hello,
>
> I have a page that contains a list of entries and a modal window opened
> from
> that page. The modal window contains a form to add new entries to the list
> on the parent page.
> Submitting the form in the modal window adds the new entry, closes the
> modal
> window and updates the list of entries in the parent page.
> This works fine.
> However, I would like to show a "success" message on the parent page after
> I
> submit the form in the modal window and close it.
> This does not seem to work because I have another FeedbackPanel in the
> modal
> window for showing error messages when required fields are not filled.
> This FeedbackPanel in the modal window seems to receive the success message
> instead of the FeedbackPanel on the parent page.
>
> I tried google and I also tried using an IFeedbackMessageFilter on the
> modal
> window's FeedbackPanel, but to no avail.
> Any hints would be appreciated. Thanks
>

Show feedback message from modal window in parent page

[heapifyman]

Hello,

I have a page that contains a list of entries and a modal window opened from
that page. The modal window contains a form to add new entries to the list
on the parent page.
Submitting the form in the modal window adds the new entry, closes the modal
window and updates the list of entries in the parent page.
This works fine.
However, I would like to show a "success" message on the parent page after I
submit the form in the modal window and close it.
This does not seem to work because I have another FeedbackPanel in the modal
window for showing error messages when required fields are not filled.
This FeedbackPanel in the modal window seems to receive the success message
instead of the FeedbackPanel on the parent page.

I tried google and I also tried using an IFeedbackMessageFilter on the modal
window's FeedbackPanel, but to no avail.
Any hints would be appreciated. Thanks

Re: Component-targetted feedback message was left unrendered even if I add Feedback Panel

[Mathilde Pellerin]

thanks ! I forget to override onError method in my AjaxButton...

now it works with FeedbackPanel, but doesn't work with
ComponentFeedbackPanel. I guess it's because each component send it's own
error on validation.

So I will try with Martin link, I think it can be very useful to me.

Thanks a lot both of you for your help !


2011/6/10 Andrea Del Bene 

> No no, it doesn't interfere. But since you use ajax for form submitting you
> have to ensure that feedback panel is refreshed adding it to
> AjaxRequestTarget.
> Have you done it in your code?
>
>  Is Ajax interfering with feedback Panel?
>>
>>
>>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>


-- 
 Mathilde Pellerin  Ingénieur en Génie Logiciel  Tél mobile :
06.60.78.79.03   E-mail
: mathilde.pelle...@gmail.com   Mon CV en ligne :
 http://www.mathilde-pellerin.fr/Mes
liens :  

Re: Component-targetted feedback message was left unrendered even if I add Feedback Panel

[Andrea Del Bene]

No no, it doesn't interfere. But since you use ajax for form submitting 
you have to ensure that feedback panel is refreshed adding it to 
AjaxRequestTarget.

Have you done it in your code?

Is Ajax interfering with feedback Panel?





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

Re: Component-targetted feedback message was left unrendered even if I add Feedback Panel

[Martin Grigorov]

http://www.jeremythomerson.com/blog/2011/01/catching-all-feedback-messages-that-arent-rendered-by-other-feedback-panels/
check whether this helps you

On Fri, Jun 10, 2011 at 11:03 AM, Mathilde Pellerin
 wrote:
> Hi all,
>
> I have a form which can send error message (on validation or on submit) and
> I try to show them in feedbak panel :
> I try with FeedBack panel like this :
> Java :
>            add(new FeedbackPanel("feedbackPanelPassword"));
>
>            Form formNouveauPwd =
> creationFormChangementPwd(membre);
>            add(formNouveauPwd);
>
> HTML:
>            
>            
>            [...]
>            
>
> and I try with ComponentFeedbackPanel like this :
> Java :
>            formNouveauPwd.add(new
> ComponentFeedbackPanel("feedbackPanelPassword", formNouveauPwd));
>
> HTML :
>            
>                
>                   
>                         wicket:id="feedbackPanelPassword">
>                    
>                    
>                        Ancien mot de passe :
>                         />
>                    
>                    
>                        Nouveau mot de passe :
>                         />
>                    
>                    
>                        Confirmation du nouveau mot de passe :
>                         />
>                    
>                    
>                        
>                             type="submit" value="Changer de mot de passe"/>
>                        
>                    
>                
>            
>
> but each time I have "Component-targetted feedback message was left
> unrendered " error.
> At the beginning, I thougth that I was these error because I had to forms in
> my page. But then I test with only one form and errors still there and
> feedbackPanel is not shown in my page.
>
> I really don't understand why, because in another page my feedbackPanel
> works well : the only difference is that it is in a panel component. But in
> wicket documentation it doesn't seem necessary to have panel component to
> feedbackPanel works...
>
> Thanks.
>
> --
> *Mathilde Pellerin*
> Ingénieur en développement de logiciel
>
> STATLIFE
> tel : 01.42.11.64.88
> mail : mathilde.pelle...@statlife.fr
>



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

Re: Component-targetted feedback message was left unrendered even if I add Feedback Panel

[Mathilde Pellerin]

I don't have any ListView, but I use Ajax for form submitting.
Is Ajax interfering with feedback Panel?


2011/6/10 Andrea Del Bene 

> Hi Mathilde,
>
> have you got any ListView component in your form? Do you use AJAX for form
> submitting?
>
>  Hi all,
>>
>> I have a form which can send error message (on validation or on submit)
>> and
>> I try to show them in feedbak panel :
>> I try with FeedBack panel like this :
>> Java :
>> add(new FeedbackPanel("feedbackPanelPassword"));
>>
>> Form  formNouveauPwd =
>> creationFormChangementPwd(membre);
>> add(formNouveauPwd);
>>
>> HTML:
>> 
>> 
>> [...]
>> 
>>
>> and I try with ComponentFeedbackPanel like this :
>> Java :
>> formNouveauPwd.add(new
>> ComponentFeedbackPanel("feedbackPanelPassword", formNouveauPwd));
>>
>> HTML :
>> 
>> 
>>
>> > wicket:id="feedbackPanelPassword">
>> 
>> 
>> Ancien mot de passe :
>> > />
>> 
>> 
>> Nouveau mot de passe :
>> > />
>> 
>> 
>> Confirmation du nouveau mot de passe :
>> > type="password"
>> />
>> 
>> 
>> 
>> > type="submit" value="Changer de mot de passe"/>
>> 
>> 
>> 
>> 
>>
>> but each time I have "Component-targetted feedback message was left
>> unrendered " error.
>> At the beginning, I thougth that I was these error because I had to forms
>> in
>> my page. But then I test with only one form and errors still there and
>> feedbackPanel is not shown in my page.
>>
>> I really don't understand why, because in another page my feedbackPanel
>> works well : the only difference is that it is in a panel component. But
>> in
>> wicket documentation it doesn't seem necessary to have panel component to
>> feedbackPanel works...
>>
>> Thanks.
>>
>>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
>

Re: Component-targetted feedback message was left unrendered even if I add Feedback Panel

[Andrea Del Bene]

Hi Mathilde,

have you got any ListView component in your form? Do you use AJAX for 
form submitting?

Hi all,

I have a form which can send error message (on validation or on submit) and
I try to show them in feedbak panel :
I try with FeedBack panel like this :
Java :
 add(new FeedbackPanel("feedbackPanelPassword"));

 Form  formNouveauPwd =
creationFormChangementPwd(membre);
 add(formNouveauPwd);

HTML:
 
 
 [...]
 

and I try with ComponentFeedbackPanel like this :
Java :
 formNouveauPwd.add(new
ComponentFeedbackPanel("feedbackPanelPassword", formNouveauPwd));

HTML :
 
 

 
 
 
 Ancien mot de passe :
 
 
 
 Nouveau mot de passe :
 
 
 
 Confirmation du nouveau mot de passe :
 
 
 
 
 
 
 
 
 

but each time I have "Component-targetted feedback message was left
unrendered " error.
At the beginning, I thougth that I was these error because I had to forms in
my page. But then I test with only one form and errors still there and
feedbackPanel is not shown in my page.

I really don't understand why, because in another page my feedbackPanel
works well : the only difference is that it is in a panel component. But in
wicket documentation it doesn't seem necessary to have panel component to
feedbackPanel works...

Thanks.




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

Component-targetted feedback message was left unrendered even if I add Feedback Panel

[Mathilde Pellerin]

Hi all,

I have a form which can send error message (on validation or on submit) and
I try to show them in feedbak panel :
I try with FeedBack panel like this :
Java :
add(new FeedbackPanel("feedbackPanelPassword"));

Form formNouveauPwd =
creationFormChangementPwd(membre);
add(formNouveauPwd);

HTML:


[...]


and I try with ComponentFeedbackPanel like this :
Java :
formNouveauPwd.add(new
ComponentFeedbackPanel("feedbackPanelPassword", formNouveauPwd));

HTML :


   



Ancien mot de passe :



Nouveau mot de passe :



Confirmation du nouveau mot de passe :










but each time I have "Component-targetted feedback message was left
unrendered " error.
At the beginning, I thougth that I was these error because I had to forms in
my page. But then I test with only one form and errors still there and
feedbackPanel is not shown in my page.

I really don't understand why, because in another page my feedbackPanel
works well : the only difference is that it is in a panel component. But in
wicket documentation it doesn't seem necessary to have panel component to
feedbackPanel works...

Thanks.

-- 
*Mathilde Pellerin*
Ingénieur en développement de logiciel

STATLIFE
tel : 01.42.11.64.88
mail : mathilde.pelle...@statlife.fr

Displaying error in renderComponent() causes "Component-targetted feedback message was left unrendered." @L

[Alec Swan]

Hello,

I have a custom component which extends AjaxEditableMultiLineLabel
with a model that sometimes throws a RuntimeException in
Model#getObject() when component is being rendered. However, the
message does not get displayed on the Feedback panel which is attached
to the WebPage until the page is refreshed. Also, the following
exception is being logged:
"Component-targetted feedback message was left unrendered. This could
be because you are missing a FeedbackPanel on the page."

My guess is that the child's Component#renderComponent() method is
called after the Feedback panel on the parent page has been rendered,
hence the error message is not displayed until the page is refreshed.
Is there any way to display the error message in this scenario without
adding a Feedback panel to the child component?

Thanks,

Alec

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

Re: Display component feedback message once: "safety net" renders them always before

[Jeremy Thomerson]

On Wed, Jan 5, 2011 at 3:12 AM, Martin Grigorov  wrote:
> Hi Jeremy,
>
> In the blog you use code as:
>
>
>   1. final TextField name = new TextField("name", new
>    PropertyModel(productModel, "name"));
>   2. name.setRequired(true);
>   3. name.add(new FeedbackPanel("nameFeedback", new
>    ComponentFeedbackMessageFilter(name)));
>
>
> I wonder what kind of .html do you use for that snippet ?
>
>  is
> not HTML valid.
>
> Sorry, for my fiddling criticism. I know this is not the main topic of the
> blog article ;-)

Thanks Martin!  I copied that example from a working example that I
have... but in the working example, I have a border that adds the
feedback panel and a css border for errors, etc.  When I hastily
stripped that out, I made a mistake writing that code in WordPress.

It's corrected now.  Thanks again!

-- 
Jeremy Thomerson
http://wickettraining.com
Need a CMS for Wicket?  Use Brix! http://brixcms.org

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

Re: Display component feedback message once: "safety net" renders them always before

[Martin Grigorov]

Hi Jeremy,

In the blog you use code as:


   1. final TextField name = new TextField("name", new
PropertyModel(productModel, "name"));
   2. name.setRequired(true);
   3. name.add(new FeedbackPanel("nameFeedback", new
ComponentFeedbackMessageFilter(name)));


I wonder what kind of .html do you use for that snippet ?

 is
not HTML valid.

Sorry, for my fiddling criticism. I know this is not the main topic of the
blog article ;-)

On Tue, Jan 4, 2011 at 5:13 PM, Jeremy Thomerson
wrote:

> On Thu, Dec 2, 2010 at 5:52 AM, Joseph Pachod  wrote:
>
> > Hi
> >
> > I'm trying to apply the behaviors presented by Alastair Maw in his
> > presentation Wicket Forms
> > with Flair (cf
> >
> http://code.google.com/p/londonwicket/downloads/detail?name=LondonWicket-FormsWithFlair.pdf&can=2&q=
> )
> >
> > Basically, Alastair uses behavior to display feedback message specific to
> > some components next to the component in question.
> >
> > We use our components in form with feedback panel, for non component
> > specific messages.
> >
> > Overall, we would like these functionalities:
> > A - no message should be rendered twice
> > B - no message should be left unrendered (safety net)
> > C - component specific message should be rendered next to their component
> > D - when some messages were displayed next to their components, the
> > feedback panel should display a message for it (like "one of more input
> > didn't validate, please check them)
> >
> > In order to try to achieve that, I used the FeedbackMessage.isRendered()
> > method in both the behaviors and the feedback panel
> IFeedbackMessageFilter.
> >
>
> As you've discovered, using the isRendered() method for this really is
> difficult because it depends on the order of traversal.  This makes it
> brittle to use this for your "safety net" or "catch all" feedback panel.
>
> I had encountered this issue and for one of my training classes, I threw
> together a solution.  Your post prodded me to go ahead and post my solution
> as a blog post.  After dusting off my long-forgotten blog, here it is:
>
> http://www.jeremythomerson.com/blog/2011/01/catching-all-feedback-messages-that-arent-rendered-by-other-feedback-panels/(or
> http://bit.ly/eHUEuN if that gets chopped up).
>
> Hopefully that helps someone.
>
> --
> Jeremy Thomerson
> http://wickettraining.com
> *Need a CMS for Wicket?  Use Brix! http://brixcms.org*
>

Re: Display component feedback message once: "safety net" renders them always before

[Jeremy Thomerson]

On Thu, Dec 2, 2010 at 5:52 AM, Joseph Pachod  wrote:

> Hi
>
> I'm trying to apply the behaviors presented by Alastair Maw in his
> presentation Wicket Forms
> with Flair (cf
> http://code.google.com/p/londonwicket/downloads/detail?name=LondonWicket-FormsWithFlair.pdf&can=2&q=)
>
> Basically, Alastair uses behavior to display feedback message specific to
> some components next to the component in question.
>
> We use our components in form with feedback panel, for non component
> specific messages.
>
> Overall, we would like these functionalities:
> A - no message should be rendered twice
> B - no message should be left unrendered (safety net)
> C - component specific message should be rendered next to their component
> D - when some messages were displayed next to their components, the
> feedback panel should display a message for it (like "one of more input
> didn't validate, please check them)
>
> In order to try to achieve that, I used the FeedbackMessage.isRendered()
> method in both the behaviors and the feedback panel IFeedbackMessageFilter.
>

As you've discovered, using the isRendered() method for this really is
difficult because it depends on the order of traversal.  This makes it
brittle to use this for your "safety net" or "catch all" feedback panel.

I had encountered this issue and for one of my training classes, I threw
together a solution.  Your post prodded me to go ahead and post my solution
as a blog post.  After dusting off my long-forgotten blog, here it is:
http://www.jeremythomerson.com/blog/2011/01/catching-all-feedback-messages-that-arent-rendered-by-other-feedback-panels/(or
http://bit.ly/eHUEuN if that gets chopped up).

Hopefully that helps someone.

-- 
Jeremy Thomerson
http://wickettraining.com
*Need a CMS for Wicket?  Use Brix! http://brixcms.org*

Re: Display component feedback message once: "safety net" renders them always before

[Joseph Pachod]

Hi Pedro

thanks a lot for your ongoing feedback ;)

I hadn't dig too much into ComponentFeedbackPanel, but I've now done it.

So, my current impressions:
- extra markup required. A bit annoying, I don't need or want that. On 
top of that I would like some design which circles the faulty input, and 
I couldn't do something like:





(I may have misses something though, I'm a ComponentFeedbackPanel newbe !)
It 's as well annoying for reusable components: this feedback can't be 
simply added from the outside to inner components, it has to be there in 
the markup as well


- ordering of component addition in the container matters
I first had this ordering:
creation of the form
addition of the form to the parent container
creation of the input field
addition of the input field to the form
creation of the ComponentFeedbackPanel
addition of the ComponentFeedbackPanel to the form
creation of the feedback panel filtering on already rendered messages
addition of the feedback panel to the parent container

in this order the messages of the input field weren't rendered twice

Then I went for creating and adding the feedback panel to the parent 
container as the first action: the messages of the input field were 
rendered twice...


This could be workaround with a Filter similar to the one I used for the 
behavior, meaning the feedback panel shouldn't display messages which 
are linked to a component having a ComponentFeedbackPanel. However I'm 
not sure it's so easy to achieve: the link is from the 
ComponentFeedbackPanel to the Component, not the other way around, 
whereas the feedbackmessage goes at the component...


As such, overall, AFAIK, I don't think that a ComponentFeedbackPanel 
would do it in my use case.


Please let me know if I'm missing something.

Thanks again for your input !

best
joseph


On 01/03/2011 01:05 PM, Pedro Santos wrote:

You are testing the behaviors types of reporter, but if two components with
an FeedbackHighlightBehavior report an feedback you break the functionality
A - no message should be rendered twice

On Wed, Dec 29, 2010 at 12:05 PM, joseph.pachod  wrote:


Hi Pedro Santos

I hadn't seen your answer, sorry.

In between, I had time again to look into my issue.

Actually, the root of it was about not displaying the feedback message
twice: once in the general feedback panel and once close from the
generating
component.

As such, while helpful, your solution didn't help there.

But I now found this "workaround" for this:
  add(new FeedbackPanel("plainFeedback", new IFeedbackMessageFilter()
{

@Override
public boolean accept(final FeedbackMessage message)
{
List  behaviors =
message.getReporter().getBehaviors();
for (IBehavior behavior : behaviors)
{
if (behavior instanceof FeedbackHighlightBehavior)
{
return false;
}
}
return true;
}
}));

=>  the feedback panel doesn't display the message twice :)

I have yet to put this change in production, where maybe I would have to do
extra check (like to check that the reporter component is effectively
visible in order to be sure of the feedback message display), but at least
I've found a way to go.

:)

++
joseph


--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/Display-component-feedback-message-once-safety-net-renders-them-always-before-tp3068969p3167130.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







--
Joseph Pachod
IT

THOMAS DAILY GmbH
Adlerstraße 19
79098 Freiburg
Deutschland
T  + 49 761 3 85 59 506
F  + 49 761 3 85 59 550
E  joseph.pac...@thomas-daily.de
www.thomas-daily.de

Geschäftsführer/Managing Directors:
Wendy Thomas, Susanne Larbig
Handelsregister Freiburg i.Br., HRB 3947

Registrieren Sie sich unter https://www.thomas-daily.de/user/sign-in für die TD 
Morning News, eine kostenlose Auswahl aktueller Themen aus TD Premium, morgens 
ab 9:15 in Ihrer Mailbox.

Aktuelle Presseinformationen für die TD Morning News und TD Premium nimmt 
unsere Redaktion unter redakt...@thomas-daily.de entgegen.
Redaktionsschluss für die TD Morning News ist täglich um 8:45.

Register free of charge at https://www.thomas-daily.de/user/sign-in to have the 
TD Morning News, a selection of the latest topics from TD Premium, delivered to 
your mailbox from 9:15 every morning.

Our editorial department receives the latest press releases for the TD Morning 
News 

Re: Display component feedback message once: "safety net" renders them always before

[Pedro Santos]

You are testing the behaviors types of reporter, but if two components with
an FeedbackHighlightBehavior report an feedback you break the functionality
A - no message should be rendered twice

On Wed, Dec 29, 2010 at 12:05 PM, joseph.pachod  wrote:

>
> Hi Pedro Santos
>
> I hadn't seen your answer, sorry.
>
> In between, I had time again to look into my issue.
>
> Actually, the root of it was about not displaying the feedback message
> twice: once in the general feedback panel and once close from the
> generating
> component.
>
> As such, while helpful, your solution didn't help there.
>
> But I now found this "workaround" for this:
>  add(new FeedbackPanel("plainFeedback", new IFeedbackMessageFilter()
>{
>
>@Override
>public boolean accept(final FeedbackMessage message)
>{
>List behaviors =
> message.getReporter().getBehaviors();
>for (IBehavior behavior : behaviors)
>{
>if (behavior instanceof FeedbackHighlightBehavior)
>{
>return false;
>}
>}
>return true;
>}
>}));
>
> => the feedback panel doesn't display the message twice :)
>
> I have yet to put this change in production, where maybe I would have to do
> extra check (like to check that the reporter component is effectively
> visible in order to be sure of the feedback message display), but at least
> I've found a way to go.
>
> :)
>
> ++
> joseph
>
>
> --
> View this message in context:
> http://apache-wicket.1842946.n4.nabble.com/Display-component-feedback-message-once-safety-net-renders-them-always-before-tp3068969p3167130.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
>
>


-- 
Pedro Henrique Oliveira dos Santos

Re: Display component feedback message once: "safety net" renders them always before

[Pedro Santos]

Hi Joseph, I didn't understood your solution

If have an page with 3 form components and 5 feedback panels: 1 for each
form component, 1 for the form, and the last one for the page. And I want
feedback messages address to form components to be presented only by the
correspondent feedback panel.
I would create:
FeedbackPanel fp1 = new
ComponentFeedbackPanel("formComponent1FeedbackPanel", formComponent1);
FeedbackPanel fp2 = new
ComponentFeedbackPanel("formComponent2FeedbackPanel", formComponent2);
FeedbackPanel fp3 = new
ComponentFeedbackPanel("formComponent3FeedbackPanel", formComponent3);
FeedbackPanel fp4 = new ComponentFeedbackPanel("formFeedbackPanel", form);
FeedbackPanel fp5 = new ComponentFeedbackPanel("pageFeedbackPanel", page);

formComponent1.info("some message") register an message that will only be
presented by fp1
form.error("some message") register an message that will only be presented
by the form

On Wed, Dec 29, 2010 at 12:05 PM, joseph.pachod  wrote:

>
> Hi Pedro Santos
>
> I hadn't seen your answer, sorry.
>
> In between, I had time again to look into my issue.
>
> Actually, the root of it was about not displaying the feedback message
> twice: once in the general feedback panel and once close from the
> generating
> component.
>
> As such, while helpful, your solution didn't help there.
>
> But I now found this "workaround" for this:
>  add(new FeedbackPanel("plainFeedback", new IFeedbackMessageFilter()
>{
>
>@Override
>public boolean accept(final FeedbackMessage message)
>{
>List behaviors =
> message.getReporter().getBehaviors();
>for (IBehavior behavior : behaviors)
>{
>if (behavior instanceof FeedbackHighlightBehavior)
>{
>return false;
>}
>}
>return true;
>}
>}));
>
> => the feedback panel doesn't display the message twice :)
>
> I have yet to put this change in production, where maybe I would have to do
> extra check (like to check that the reporter component is effectively
> visible in order to be sure of the feedback message display), but at least
> I've found a way to go.
>
> :)
>
> ++
> joseph
>
>
> --
> View this message in context:
> http://apache-wicket.1842946.n4.nabble.com/Display-component-feedback-message-once-safety-net-renders-them-always-before-tp3068969p3167130.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
>
>


-- 
Pedro Henrique Oliveira dos Santos

Re: Display component feedback message once: "safety net" renders them always before

[joseph.pachod]

Hi Pedro Santos

I hadn't seen your answer, sorry. 

In between, I had time again to look into my issue. 

Actually, the root of it was about not displaying the feedback message
twice: once in the general feedback panel and once close from the generating
component.

As such, while helpful, your solution didn't help there.

But I now found this "workaround" for this:
  add(new FeedbackPanel("plainFeedback", new IFeedbackMessageFilter()
{

@Override
public boolean accept(final FeedbackMessage message)
{
List behaviors =
message.getReporter().getBehaviors();
for (IBehavior behavior : behaviors)
{
if (behavior instanceof FeedbackHighlightBehavior)
{
return false;
}
}
return true;
}
}));

=> the feedback panel doesn't display the message twice :)

I have yet to put this change in production, where maybe I would have to do
extra check (like to check that the reporter component is effectively
visible in order to be sure of the feedback message display), but at least
I've found a way to go.

:)

++
joseph


-- 
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Display-component-feedback-message-once-safety-net-renders-them-always-before-tp3068969p3167130.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: Display component feedback message once: "safety net" renders them always before

[Pedro Santos]

Hi Joseph, I use an ComponentFeedbackPanel next to the component when I want
its feedback message presented in an special place.

On Thu, Dec 2, 2010 at 9:52 AM, Joseph Pachod  wrote:

> Hi
>
> I'm trying to apply the behaviors presented by Alastair Maw in his
> presentation Wicket Forms
> with Flair (cf
> http://code.google.com/p/londonwicket/downloads/detail?name=LondonWicket-FormsWithFlair.pdf&can=2&q=)
>
> Basically, Alastair uses behavior to display feedback message specific to
> some components next to the component in question.
>
> We use our components in form with feedback panel, for non component
> specific messages.
>
> Overall, we would like these functionalities:
> A - no message should be rendered twice
> B - no message should be left unrendered (safety net)
> C - component specific message should be rendered next to their component
> D - when some messages were displayed next to their components, the
> feedback panel should display a message for it (like "one of more input
> didn't validate, please check them)
>
> In order to try to achieve that, I used the FeedbackMessage.isRendered()
> method in both the behaviors and the feedback panel IFeedbackMessageFilter.
>
> However, it looks like the feedback panel is always the first to be
> rendered, whatever the components ordering. As such, it always get to render
> first the feedback messages.
>
> I tried to use only behavior based feedback messages display, but looks
> like the behavior added on the top level elements also always get rendered
> first.
>
> Next stuff coming in my mind is to keep track of all these behaviors to be
> able to ask each of these if they would render some message. Doing so in the
> "safety net" component would allow to avoid duplicates. However, this feels
> poor to do (list to give around or to access somehow in the background,
> maybe through some thread local container).
>
> so, the big question: is there a nice and easy way to do that ? Anything
> better than this behavior tracking stuff is welcome ;)
>
> best
> --
>
> Joseph Pachod
> IT
>
> THOMAS DAILY GmbH
> Adlerstraße 19
> 79098 Freiburg
> Deutschland
> T  + 49 761 3 85 59 506
> F  + 49 761 3 85 59 550
> E  joseph.pac...@thomas-daily.de
> www.thomas-daily.de
>
> Geschäftsführer/Managing Directors:
> Wendy Thomas, Susanne Larbig
> Handelsregister Freiburg i.Br., HRB 3947
>
> Registrieren Sie sich unter https://www.thomas-daily.de/user/sign-in für
> die TD Morning News, eine kostenlose Auswahl aktueller Themen aus TD
> Premium, morgens ab 9:15 in Ihrer Mailbox.
>
> Aktuelle Presseinformationen für die TD Morning News und TD Premium nimmt
> unsere Redaktion unter redakt...@thomas-daily.de entgegen.
> Redaktionsschluss für die TD Morning News ist täglich um 8:45.
>
> Register free of charge at https://www.thomas-daily.de/user/sign-in to
> have the TD Morning News, a selection of the latest topics from TD Premium,
> delivered to your mailbox from 9:15 every morning.
>
> Our editorial department receives the latest press releases for the TD
> Morning News and TD Premium at redakt...@thomas-daily.de. The editorial
> deadline for the TD Morning News is 8.45am daily.
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>


-- 
Pedro Henrique Oliveira dos Santos

Display component feedback message once: "safety net" renders them always before

[Joseph Pachod]

Hi

I'm trying to apply the behaviors presented by Alastair Maw in his 
presentation Wicket Forms
with Flair (cf 
http://code.google.com/p/londonwicket/downloads/detail?name=LondonWicket-FormsWithFlair.pdf&can=2&q= 
)


Basically, Alastair uses behavior to display feedback message specific 
to some components next to the component in question.


We use our components in form with feedback panel, for non component 
specific messages.


Overall, we would like these functionalities:
A - no message should be rendered twice
B - no message should be left unrendered (safety net)
C - component specific message should be rendered next to their component
D - when some messages were displayed next to their components, the 
feedback panel should display a message for it (like "one of more input 
didn't validate, please check them)


In order to try to achieve that, I used the FeedbackMessage.isRendered() 
method in both the behaviors and the feedback panel IFeedbackMessageFilter.


However, it looks like the feedback panel is always the first to be 
rendered, whatever the components ordering. As such, it always get to 
render first the feedback messages.


I tried to use only behavior based feedback messages display, but looks 
like the behavior added on the top level elements also always get 
rendered first.


Next stuff coming in my mind is to keep track of all these behaviors to 
be able to ask each of these if they would render some message. Doing so 
in the "safety net" component would allow to avoid duplicates. However, 
this feels poor to do (list to give around or to access somehow in the 
background, maybe through some thread local container).


so, the big question: is there a nice and easy way to do that ? Anything 
better than this behavior tracking stuff is welcome ;)


best
--

Joseph Pachod
IT

THOMAS DAILY GmbH
Adlerstraße 19
79098 Freiburg
Deutschland
T  + 49 761 3 85 59 506
F  + 49 761 3 85 59 550
E  joseph.pac...@thomas-daily.de
www.thomas-daily.de

Geschäftsführer/Managing Directors:
Wendy Thomas, Susanne Larbig
Handelsregister Freiburg i.Br., HRB 3947

Registrieren Sie sich unter https://www.thomas-daily.de/user/sign-in für die TD 
Morning News, eine kostenlose Auswahl aktueller Themen aus TD Premium, morgens 
ab 9:15 in Ihrer Mailbox.

Aktuelle Presseinformationen für die TD Morning News und TD Premium nimmt 
unsere Redaktion unter redakt...@thomas-daily.de entgegen.
Redaktionsschluss für die TD Morning News ist täglich um 8:45.

Register free of charge at https://www.thomas-daily.de/user/sign-in to have the 
TD Morning News, a selection of the latest topics from TD Premium, delivered to 
your mailbox from 9:15 every morning.

Our editorial department receives the latest press releases for the TD Morning 
News and TD Premium at redakt...@thomas-daily.de. The editorial deadline for 
the TD Morning News is 8.45am daily.


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

Re: Missing FeedbackPanel : Component-targetted feedback message was left unrendered

[Andrea Del Bene]

Thanks for sharing your solution!

Bye.

I got the solution!
Just adding setReuseItems(true) to the ListView and it's working!
   



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

Re: Missing FeedbackPanel : Component-targetted feedback message was left unrendered

[rawe]

I got the solution!
Just adding setReuseItems(true) to the ListView and it's working!
-- 
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/ListView-Missing-FeedbackPanel-Component-targetted-feedback-message-was-left-unrendered-tp3044576p3046430.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: Missing FeedbackPanel : Component-targetted feedback message was left unrendered

[rawe]

Yes, I've tried it and it works!
But my goal is to use several FeedbackPanels in my page.
So I'm using several fragments each with an own FeedbackPanel.
This design also works well if the fragment uses static FormComponents.
But if the fragment uses a ListView (or DataView) where the FormComponents
are created dynamically 
the FeedbackPanel is not rendered.


-- 
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/ListView-Missing-FeedbackPanel-Component-targetted-feedback-message-was-left-unrendered-tp3044576p3046298.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: Missing FeedbackPanel : Component-targetted feedback message was left unrendered

[Andrea Del Bene]

Hi, have you tried moving FeedbackPanel out of fragment? You could put 
it at the end of the form like this:




...






and then you could add it directly to form:


form.add(new RedFeedbackPanel("feedback"));

My Problem is the correct display of a feedbackpanel.
The feedbackpanel is defined in a fragment component.
I have a page including a form including a fragment including a repeater
(DataView).
The DataView creates  textfields in the populateItem() method.
The textfields are set to required=true.

I want to validate and display the textfield when submitting the form.
Problem: I get following message and no feedbackpanel:
(WebSession.java:193) -Component-targetted feedback message was left
unrendered. This could be because you are missing a FeedbackPanel on the
page.
Message: [FeedbackMessage message = " error message ...", reporter = tfi,
level = ERROR]

But:
When I set an Ajax event on the textfield e.g.
AjaxFormComponentUpdatingBehavior("onblur") and
call target.addComponent(feedbackPanel); in onUpdate() method the
feedbackpanel is displayed correctly.

How is it possible to display the feedback panel when doing a "normal" form
submit without ajax ?
It seems to be the problem that the textfield components are created
dynamically and they don't know their feedbackpanel !?
Is there a solution to set the textfields the feedbackpanel (without ajax) ?

Thanks for hints!

Ralph

see my code example:


public class MyPage extends WebPage {

public MyPage() {

Form form = new Form("form") {

@Override
protected void onSubmit() {
setResponsePage(IndexPage.class);
}

@Override
protected void onError() {
...
}

}

form.add(new MyFragment("fragment"));

Button btnSave = new Button("btnSave", "Save");
form.add(btnSave);

this.add(form);
}

}


public class MyFragment extends Fragment {

private FeedbackPanel feedbackpanel;

public MyFragment1(String id) {
super(id, "fragment1", MyPage.this);

feedbackpanel = new FeedbackPanel("feedback1",
new 
ContainerFeedbackMessageFilter(this));
add(feedbackpanel);

myContainer = new WebMarkupContainer("myContainer");
myContainer.add(new MyDataViewTable("tblList", list));
add(myContainer);
 }

}


Here my  DataView - Repeater populateItem method:


protected void populateItem(Item item) {
...
TextField tfi = new TextField();
tfi.setRequired(true);
tfi.add(new AjaxFormComponentUpdatingBehavior("onblur") {
@Override
protected void onUpdate(AjaxRequestTarget target) {
target.addComponent(feedbackPanel);
}

@Override
protected void onError(AjaxRequestTarget target, 
RuntimeException e) {
target.addComponent(feedbackPanel);
}
});


item.add(tfi);

...

}


My Markup:




... 






















   



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

Re: Link inside feedback message

[Anna Simbirtsev]

Thank you.

On Tue, Nov 16, 2010 at 10:26 AM, Manfred Bergmann
 wrote:
>
> Check the API docs for Component.
> You'll find urlFor() methods that take a Page subclass and PareParameters.
>
> => urlFor(Class pageClass, PageParameters parameters)
>
>
> Manfred
> --
> View this message in context: 
> http://apache-wicket.1842946.n4.nabble.com/Link-inside-feedback-message-tp3043825p3045009.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
>
>



-- 
Anna Simbirtsev
(416) 729-7331

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

Re: Link inside feedback message

[Manfred Bergmann]

Check the API docs for Component.
You'll find urlFor() methods that take a Page subclass and PareParameters.

=> urlFor(Class pageClass, PageParameters parameters) 


Manfred
-- 
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Link-inside-feedback-message-tp3043825p3045009.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: Link inside feedback message

[Anna Simbirtsev]

And I need to provide the whole URL? What if I need to use
bookmarkable page link. For example:
add(new BookmarkablePageLink("homelink", Home.class));

On Mon, Nov 15, 2010 at 10:01 PM, Alexander Morozov
 wrote:
>
> /* add feedback */
> FeedbackPanel panel = new FeedbackPanel("feedback");
> panel.setEscapeModelStrings(false);
>
> /* message with HTML*/
> info("Please, visit 
>
>
>
> --
> View this message in context: 
> http://apache-wicket.1842946.n4.nabble.com/Link-inside-feedback-message-tp3043825p3044162.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
>
>



-- 
Anna Simbirtsev
(416) 729-7331

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