Re: Centralizing ajax inline javascript
Sebastien, Ernesto, I had to repost because after centralizing the ajax behavior I saw the browser does not send CheckBox ajax requests in parallel any more. Is this because we centralized the behavior? Lucas Kuperman -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Centralizing-ajax-inline-javascript-tp4652499p4652772.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: Centralizing ajax inline javascript
Hi Sebastien, I applied your last approach and I think it would work. It is working but step 4 Get the component back is not finding the checkbox because of (what I believe) an incomplete path. It doesn't sound complicated, I'll investigate. However I am starting to understand things more due to your answer, and because I am dealing with an unusual large page, I am wondering what do you think about changing the use case and -since we centralized the behavior- not call the checkbox's onUpdate() anymore but rather just the behavior's respond() ? All checkboxes do the same thing. So if the checkbox name received as parameter gives me everything I need to load the models for my processing, I no longer require the checkbox instance(s) be stored in session contributing in my main issue which is performance in large pages. Am I right? It is really motivating having answers like yours. Thank you so much Lucas Kuperman -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Centralizing-ajax-inline-javascript-tp4652499p4652548.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: Centralizing ajax inline javascript
Hi Ernesto. We seem to be in the same page now. Sebastien's approach is also about a single behavior, with the small difference of adding the CheckBoxes onclick event in the server side (I did it in the onComponentTag method instead of relying on attributemodifiers because of performance) rather than through a small JavaScript on the client. Since I am dealing with an unusual big table and my main problem is performance, I'll consider your JS approach now that I have centralized the behavior (thanks Sebastien!). I am considering applying the dynamic load that Vineet suggested because I still can't bring numbers down, but planning to do that after the table is as 'efficient' as I can get it to be. Thank you so much for your contribution! I'll keep you posted Lucas -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Centralizing-ajax-inline-javascript-tp4652499p4652549.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: Centralizing ajax inline javascript
hi ! dynamic load will only be useful if you can add new items without repainting the repeater's parent (repainting parent will cause the repeater to render again), read Igor Vaynberg's article for the idea http://wicketinaction.com/2008/10/repainting-only-newly-created-repeater-items-via-ajax/ On Mon, Oct 1, 2012 at 2:45 AM, lukuperman lukuper...@hotmail.com wrote: Hi Ernesto. We seem to be in the same page now. Sebastien's approach is also about a single behavior, with the small difference of adding the CheckBoxes onclick event in the server side (I did it in the onComponentTag method instead of relying on attributemodifiers because of performance) rather than through a small JavaScript on the client. Since I am dealing with an unusual big table and my main problem is performance, I'll consider your JS approach now that I have centralized the behavior (thanks Sebastien!). I am considering applying the dynamic load that Vineet suggested because I still can't bring numbers down, but planning to do that after the table is as 'efficient' as I can get it to be. Thank you so much for your contribution! I'll keep you posted Lucas -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Centralizing-ajax-inline-javascript-tp4652499p4652549.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 -- regards, Vineet Semwal - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Centralizing ajax inline javascript
Hi Sebastien, just to understand, if I don't need an AjaxCheckBox anymore then I shouldn't extend from it right? I'm in troubles, cause if I dont extend, I have no behavior to call back, and if I do extend then the original problem arise about the inline onclick script being attached to each checkbox resulting in dozens of MB in my large pages. I can't identify what I'm missing from your answer, sorry. Any final thought ? Lucas Kuperman -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Centralizing-ajax-inline-javascript-tp4652499p4652554.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: Centralizing ajax inline javascript
Thanks Ernesto and Sebastien! I'm going to apply your suggestions during the weekend and keep you posted. In the meantime, Ernesto, I want to clarify that I don't want to pass any additional parameter to the server. I just want the proper onUpdate() method of the proper AjaxCheckBox instance be called, for which I assume the URL you mention in step 2 can't be static but dynamically computed with the corresponding checkbox id (or name?) that I have clicked on. I hope it made sense since I'm not yet familiar with ajax callbacks URL concepts yet. Lucas Kuperman -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Centralizing-ajax-inline-javascript-tp4652499p4652533.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: Centralizing ajax inline javascript
assuming you are using a repeater say dataview/gridview,think about that in this way 200*200==40k items of repeater,are you rendering that number of items at once? i would have used a small table with navigator or some ajax scroll behavior .. On Fri, Sep 28, 2012 at 6:11 PM, lukuperman lukuper...@hotmail.com wrote: Hello all, I am working on an application that was built with Wicket 1.4.15. It has to show a table with an AjaxCheckBox on each cell. Most of the final html size is because of the inline ajax behavior on each cb (ie 20Mb for a 200x200 table). Leaving aside the fact of rendering big tables (which is imposed by business), can you give me some hints or ideas on how can I decrease final html size maintaining ajax behavior? For example, how can I: -centralize the javascript and make checkboxes call it passing the minimum parameters needed (id, etc) -or event registration, without migrating to Wicket 6 (not allowed to) -some other way? Thank you! Lucas -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Centralizing-ajax-inline-javascript-tp4652499.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 -- regards, Vineet Semwal - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Centralizing ajax inline javascript
Yes, I think the AbstractDefaultAjaxBehavior could look to something like:
public void renderHead(Component component, IHeaderResponse response)
{
super.renderHead(component, response);
response.renderJavaScript(function boup(id) { +
this.getCallbackScript() + }, my-script-id);
//TODO: input type=checkbox onclick=boup(10); / where (id = 10)
}
protected CharSequence getCallbackScript()
{
return this.generateCallbackScript(wicketAjaxGet(' +
this.getCallbackUrl() + id=' + id); //warning, do not close script with
)!
}
protected void respond(AjaxRequestTarget target)
{
final IRequestParameters parameters =
RequestCycle.get().getRequest().getQueryParameters();
int id = parameters.getParameterValue(id).toInt();
//TODO: do something with id
}
On Fri, Sep 28, 2012 at 2:52 PM, Ernesto Reinaldo Barreiro
reier...@gmail.com wrote:
Hi,
I would do the following
1- attach an AbstractDefaultAjaxBehavior to the table
2- Use that behavior as a context for making AJAX call-backs (i.e. generate
a URL to it amd pas it to the client side).
3- On client side use some jquery (or similar machinery) to generate
wickeAjaxGet(URL in step 2) passing as extra parameter the info you need
This way you reduce the amount of code to be streamed back to the client
as well as the foot-print on server side. This approach should work in
any of the current version of wicket (AFAIK).
On Fri, Sep 28, 2012 at 5:41 AM, lukuperman lukuper...@hotmail.com
wrote:
Hello all, I am working on an application that was built with Wicket
1.4.15.
It has to show a table with an AjaxCheckBox on each cell. Most of the
final
html size is because of the inline ajax behavior on each cb (ie 20Mb for
a
200x200 table). Leaving aside the fact of rendering big tables (which is
imposed by business), can you give me some hints or ideas on how can I
decrease final html size maintaining ajax behavior? For example, how can
I:
-centralize the javascript and make checkboxes call it passing the
minimum
parameters needed (id, etc)
-or event registration, without migrating to Wicket 6 (not allowed to)
-some other way?
Thank you!
Lucas
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/Centralizing-ajax-inline-javascript-tp4652499.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
--
Regards - Ernesto Reinaldo Barreiro
Antilia Soft
http://antiliasoft.com
Re: Centralizing ajax inline javascript
Hi Vineet. I knew someone would ask. Lots of components right? Yes, I agree. The component tree is giving us a hard time with performance in general (around 5 minutes to process) and stack overflows when serializing, etc. But focusing back to my original question, unfortunately the business requirement remains. Pagination is not allowed. The page is currently loaded at once, but lazy loading is certainly an option if end result is the same. I'll search for ajax scroll behaviors. If you happen to have used something like that with Wicket and have a link handy, it would be appreciated. Thanks for contributing on my thread Lucas Kuperman -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Centralizing-ajax-inline-javascript-tp4652499p4652505.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: Centralizing ajax inline javascript
actually i have the elegant solution for your problem in 6.x ,i didn't recommend it before because you are on 1.4 i wrote Quickview and QuickGridView ,the whole project is available at https://github.com/vineetsemwal/quickview including examples. the way of using QuickView is almost like DataView the way of using QuickGridView is almost like Gridview what they offer is they can add/remove new items/rows without the need to repaint the whole repeater.i have written a navigator and a scroll behavior for that so on demand/scroll you can add new rows.this in working is like how new rows are added on demand/scroll in social networking sites.a user practically doesn't have to learn anything. the problem is i don't want to port/support any version less than 6.x On Fri, Sep 28, 2012 at 8:34 PM, lukuperman lukuper...@hotmail.com wrote: Hi Vineet. I knew someone would ask. Lots of components right? Yes, I agree. The component tree is giving us a hard time with performance in general (around 5 minutes to process) and stack overflows when serializing, etc. But focusing back to my original question, unfortunately the business requirement remains. Pagination is not allowed. The page is currently loaded at once, but lazy loading is certainly an option if end result is the same. I'll search for ajax scroll behaviors. If you happen to have used something like that with Wicket and have a link handy, it would be appreciated. Thanks for contributing on my thread Lucas Kuperman -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Centralizing-ajax-inline-javascript-tp4652499p4652505.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 -- regards, Vineet Semwal - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
