Re: Replacing markup generated by a Behavior
On Fri, Oct 29, 2010 at 12:39 AM, Clint Checketts checke...@gmail.comwrote: Elegant! I'd been trying to think of ways to add my own markup ID and piggyback off any render requests that redraw the component to trigger and render the feedback, just using the component markupId will work great! Instead of setOutputMarkupId(false), I'll detect that to decide to add the ID or not and just remove the ID attribute in the onComponentTag() method. I'll code it up tomorrow. I've got a good feeling about this. Thanks for the help. Also I'll check out the IAjaxRegionMarkupIdProvider. Always good to check out the new interfaces. Yeah, using the IAjaxRegionMarkupIdProvider you can eliminate all the aforementioned complexity. The markup ID of your component stays the same. In the interface, you just create an ID that will be rendered in your behavior's markup. You render that in your behavior-generated markup, and then Wicket will use the same ID for when it replaces the markup for that component - thus replacing both together. -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org*
Re: Replacing markup generated by a Behavior
Clint, Very interesting ! Please share some code and docs on https://cwiki.apache.org/WICKET/ Once you get it working ;-) Thanks :-) On Fri, Oct 29, 2010 at 8:49 AM, Jeremy Thomerson jer...@wickettraining.com wrote: On Fri, Oct 29, 2010 at 12:39 AM, Clint Checketts checke...@gmail.com wrote: Elegant! I'd been trying to think of ways to add my own markup ID and piggyback off any render requests that redraw the component to trigger and render the feedback, just using the component markupId will work great! Instead of setOutputMarkupId(false), I'll detect that to decide to add the ID or not and just remove the ID attribute in the onComponentTag() method. I'll code it up tomorrow. I've got a good feeling about this. Thanks for the help. Also I'll check out the IAjaxRegionMarkupIdProvider. Always good to check out the new interfaces. Yeah, using the IAjaxRegionMarkupIdProvider you can eliminate all the aforementioned complexity. The markup ID of your component stays the same. In the interface, you just create an ID that will be rendered in your behavior's markup. You render that in your behavior-generated markup, and then Wicket will use the same ID for when it replaces the markup for that component - thus replacing both together. -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org*
Replacing markup generated by a Behavior
I have a Visitor that iterates through my forms and adds a Behavior that writes out to the Response a div and any feedback messages that belong to that component. This is really great because it gives me inline feedback panels. Here is the problem: if the component is ever updated via ajax, the component the behavior is tied to get replaced in the DOM, but the feedback messages get written out in another div again. My core need is to create some sort of auto-adding inline feedbackpanel. Any good recommendations on how to work around this? It's such a good design pratice to have error messages next to the offending input fields, I'm sure others have had to deal with this.
Re: Replacing markup generated by a Behavior
On Thu, Oct 28, 2010 at 5:19 PM, Clint Checketts checke...@gmail.comwrote: I have a Visitor that iterates through my forms and adds a Behavior that writes out to the Response a div and any feedback messages that belong to that component. This is really great because it gives me inline feedback panels. Here is the problem: if the component is ever updated via ajax, the component the behavior is tied to get replaced in the DOM, but the feedback messages get written out in another div again. My core need is to create some sort of auto-adding inline feedbackpanel. Any good recommendations on how to work around this? It's such a good design pratice to have error messages next to the offending input fields, I'm sure others have had to deal with this. A couple options: - Use a Border. Of course, then it's harder to add this automatically because a border will look for the html in the parent container. - in your behavior, in the div you render, render the div with the markup ID of the component you are wrapping, and then call setOutputMarkupId(false) on the component you are wrapping. thus, you are moving the markup id up to the wrapping div. - if you are using wicket 1.4.10 or greater, implement IAjaxRegionMarkupIdProvider, which allows you to override the id of the markup region that will updated via ajax -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org*
Re: Replacing markup generated by a Behavior
Elegant! I'd been trying to think of ways to add my own markup ID and piggyback off any render requests that redraw the component to trigger and render the feedback, just using the component markupId will work great! Instead of setOutputMarkupId(false), I'll detect that to decide to add the ID or not and just remove the ID attribute in the onComponentTag() method. I'll code it up tomorrow. I've got a good feeling about this. Thanks for the help. Also I'll check out the IAjaxRegionMarkupIdProvider. Always good to check out the new interfaces. -Clint On Thu, Oct 28, 2010 at 5:28 PM, Jeremy Thomerson jer...@wickettraining.com wrote: On Thu, Oct 28, 2010 at 5:19 PM, Clint Checketts checke...@gmail.com wrote: I have a Visitor that iterates through my forms and adds a Behavior that writes out to the Response a div and any feedback messages that belong to that component. This is really great because it gives me inline feedback panels. Here is the problem: if the component is ever updated via ajax, the component the behavior is tied to get replaced in the DOM, but the feedback messages get written out in another div again. My core need is to create some sort of auto-adding inline feedbackpanel. Any good recommendations on how to work around this? It's such a good design pratice to have error messages next to the offending input fields, I'm sure others have had to deal with this. A couple options: - Use a Border. Of course, then it's harder to add this automatically because a border will look for the html in the parent container. - in your behavior, in the div you render, render the div with the markup ID of the component you are wrapping, and then call setOutputMarkupId(false) on the component you are wrapping. thus, you are moving the markup id up to the wrapping div. - if you are using wicket 1.4.10 or greater, implement IAjaxRegionMarkupIdProvider, which allows you to override the id of the markup region that will updated via ajax -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org*
