AjaxRequestTarget.addComponent does not work after RequestCycle.setResponsePage was called
Once setResponsePage is called the AjaxRequestTarget is pushed down in the list of request targets and AjaxRequestTarget won't be called anymore because AbstractRequestCycleProcessor.respond invokes the current request target only. My page has some ajax links that delegates handling to different module and link does not know whether redirect happens. The link still has to update some components. But in case of redirect all the updates aren't applied and backbuttoning shows old state (actually with ajax indicator covering all the page so any element is not clickable). I believe it makes sence to defer switching to different request target until finishing responding on ajax request. https://issues.apache.org/jira/browse/WICKET-3010
Re: Best practice for component interaction
Igor Vaynberg schrieb: onclick(final AjaxRequestTarget target) { getPage().visitChildren(CaresAboutMyAjaxEvent.class, new IVisitorCaresAboutMyAjaxEvent () { Object visit(CaresAboutMyAjaxEent object) { object.onMyAjaxEvent(target); }}} Interesting. A colleague also found the following blogpost: http://techblog.molindo.at/2008/09/wicket-loose-coupling-of-componens-for-ajax-updates.html Cheers, Patrick - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Best practice for component interaction
I don't like subscriptions implementation. Somewhen it becomes difficult to realize when to add/remove observers. It depends on the order of instantiations. Visitor pattern seems to be much more reliable. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Best-practice-for-component-interaction-tp2336888p2337874.html Sent from the Wicket - User 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: Best practice for component interaction
What about if we modify this idea a bit? What if we use dynamic proxies to make it more generic? So, your onclick method would look like: public void onClick(AjaxRequestTarget target) { fire(MyCustomEventListener.class).someAjaxEvent(target); } Then, the fire() method would return an object (a dynamic proxy) that implements the MyCustomEventListener interface. The method implementation would do the visitor thing by looking for all components implementing the MyCustomEventListener interface and then call the someAjaxEvent() method. On Wed, Aug 25, 2010 at 5:10 AM, vladimir.kovalyuk koval...@gmail.com wrote: I don't like subscriptions implementation. Somewhen it becomes difficult to realize when to add/remove observers. It depends on the order of instantiations. Visitor pattern seems to be much more reliable. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Best-practice-for-component-interaction-tp2336888p2337874.html Sent from the Wicket - User 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: Best practice for component interaction
Not sure about the best practice, but instead of passing a reference I use getParent or getPage methods, then find the target component by its id. Bilgin On Tue, Aug 24, 2010 at 4:37 PM, Patrick Petermair patrick.peterm...@openforce.com wrote: Hi! Let's say I have a page with 2 panels. CalendarPanel shows a simple calendar, FormPanel a basic form. Whenever the user clicks on a date in the calendar, the textfield of the form should show the selected date. What is the best practice for this kind of interaction? Right now we hold a reference to the FormPanel in CalendarPanel and attach our custom CalendarAjaxBehavior to it. Whenever the CalendarAjaxBehavior gets a request / click, it updates the FormPanel's model directly. I don't really know if this is some ugly hack or if there is a better way of different panels to update / communicate with each other - other than holding references to one another... Cheers, Patrick - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Cache key collisions (IMarkupCacheKeyProvider)
On Tue, August 24, 2010, Igor Vaynberg wrote: IMarkupCacheKeyProvider is for advanced users. you have to know what you are doing when you implement the interface. OK, that's fine with me. Why not add a comment to the interface stating just this plus a hint that in general adding the fully qualified class name to the cache key is a good idea? Cheers, M'bert -- --- / http://herbert.the-little-red-haired-girl.org / - =+= Es genuegt nicht, keine Gedanken zu haben, man muss auch unfaehig sein, sie auszudruecken. -- Stanislav Jerzy Lec - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Best practice for component interaction
Hi James, I like the idea of having a way of automatically includes components in the AjaxRequestTarget without the need to do it explicitly (target.add(..)), by using a Marking Interface and the Visitor, it really would make things easier when you want to add a new component to the current Ajax Response. The idea of the DynamicProxy seems very promising and i thinks it something way much better of having Pub/Sub event implementation. Just my +0.05 cents :) On Wed, Aug 25, 2010 at 9:11 AM, James Carman [via Apache Wicket] ml-node+2338119-2003757039-65...@n4.nabble.comml-node%2b2338119-2003757039-65...@n4.nabble.com wrote: What about if we modify this idea a bit? What if we use dynamic proxies to make it more generic? So, your onclick method would look like: public void onClick(AjaxRequestTarget target) { fire(MyCustomEventListener.class).someAjaxEvent(target); } Then, the fire() method would return an object (a dynamic proxy) that implements the MyCustomEventListener interface. The method implementation would do the visitor thing by looking for all components implementing the MyCustomEventListener interface and then call the someAjaxEvent() method. On Wed, Aug 25, 2010 at 5:10 AM, vladimir.kovalyuk [hidden email]http://user/SendEmail.jtp?type=nodenode=2338119i=0 wrote: I don't like subscriptions implementation. Somewhen it becomes difficult to realize when to add/remove observers. It depends on the order of instantiations. Visitor pattern seems to be much more reliable. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Best-practice-for-component-interaction-tp2336888p2337874.htmlhttp://apache-wicket.1842946.n4.nabble.com/Best-practice-for-component-interaction-tp2336888p2337874.html?by-user=t Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [hidden email]http://user/SendEmail.jtp?type=nodenode=2338119i=1 For additional commands, e-mail: [hidden email]http://user/SendEmail.jtp?type=nodenode=2338119i=2 - To unsubscribe, e-mail: [hidden email]http://user/SendEmail.jtp?type=nodenode=2338119i=3 For additional commands, e-mail: [hidden email]http://user/SendEmail.jtp?type=nodenode=2338119i=4 -- View message @ http://apache-wicket.1842946.n4.nabble.com/Best-practice-for-component-interaction-tp2336888p2338119.html To unsubscribe from Apache Wicket, click herehttp://apache-wicket.1842946.n4.nabble.com/template/TplServlet.jtp?tpl=unsubscribe_by_codenode=1842946code=amNnYXJjaWFtQGdtYWlsLmNvbXwxODQyOTQ2fDEyNTYxMzc3ODY=. -- Sincerely, JC (http://www.linkedin.com/in/jcgarciam) Work smarter, not harder!. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Best-practice-for-component-interaction-tp2336888p2338205.html Sent from the Wicket - User mailing list archive at Nabble.com.
Re: Best practice for component interaction
Do you want an example of how it would work or are you confident in how to implement it yourself? On Wed, Aug 25, 2010 at 9:05 AM, jcgarciam jcgarc...@gmail.com wrote: Hi James, I like the idea of having a way of automatically includes components in the AjaxRequestTarget without the need to do it explicitly (target.add(..)), by using a Marking Interface and the Visitor, it really would make things easier when you want to add a new component to the current Ajax Response. The idea of the DynamicProxy seems very promising and i thinks it something way much better of having Pub/Sub event implementation. Just my +0.05 cents :) On Wed, Aug 25, 2010 at 9:11 AM, James Carman [via Apache Wicket] ml-node+2338119-2003757039-65...@n4.nabble.comml-node%2b2338119-2003757039-65...@n4.nabble.com wrote: What about if we modify this idea a bit? What if we use dynamic proxies to make it more generic? So, your onclick method would look like: public void onClick(AjaxRequestTarget target) { fire(MyCustomEventListener.class).someAjaxEvent(target); } Then, the fire() method would return an object (a dynamic proxy) that implements the MyCustomEventListener interface. The method implementation would do the visitor thing by looking for all components implementing the MyCustomEventListener interface and then call the someAjaxEvent() method. On Wed, Aug 25, 2010 at 5:10 AM, vladimir.kovalyuk [hidden email]http://user/SendEmail.jtp?type=nodenode=2338119i=0 wrote: I don't like subscriptions implementation. Somewhen it becomes difficult to realize when to add/remove observers. It depends on the order of instantiations. Visitor pattern seems to be much more reliable. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Best-practice-for-component-interaction-tp2336888p2337874.htmlhttp://apache-wicket.1842946.n4.nabble.com/Best-practice-for-component-interaction-tp2336888p2337874.html?by-user=t Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [hidden email]http://user/SendEmail.jtp?type=nodenode=2338119i=1 For additional commands, e-mail: [hidden email]http://user/SendEmail.jtp?type=nodenode=2338119i=2 - To unsubscribe, e-mail: [hidden email]http://user/SendEmail.jtp?type=nodenode=2338119i=3 For additional commands, e-mail: [hidden email]http://user/SendEmail.jtp?type=nodenode=2338119i=4 -- View message @ http://apache-wicket.1842946.n4.nabble.com/Best-practice-for-component-interaction-tp2336888p2338119.html To unsubscribe from Apache Wicket, click herehttp://apache-wicket.1842946.n4.nabble.com/template/TplServlet.jtp?tpl=unsubscribe_by_codenode=1842946code=amNnYXJjaWFtQGdtYWlsLmNvbXwxODQyOTQ2fDEyNTYxMzc3ODY=. -- Sincerely, JC (http://www.linkedin.com/in/jcgarciam) Work smarter, not harder!. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Best-practice-for-component-interaction-tp2336888p2338205.html Sent from the Wicket - User 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: Best practice for component interaction
Share your genius with us ;) For serious: I'am really looking forward to see and example implementation! :) -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Best-practice-for-component-interaction-tp2336888p2338213.html Sent from the Wicket - User 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: Best practice for component interaction
Thanks for expressing your help on this, im already working on it :-), since is not that hard to implement, but i would like to see this kind of functionality in the core . :) On Wed, Aug 25, 2010 at 10:09 AM, James Carman [via Apache Wicket] ml-node+2338212-617428318-65...@n4.nabble.comml-node%2b2338212-617428318-65...@n4.nabble.com wrote: Do you want an example of how it would work or are you confident in how to implement it yourself? On Wed, Aug 25, 2010 at 9:05 AM, jcgarciam [hidden email]http://user/SendEmail.jtp?type=nodenode=2338212i=0 wrote: Hi James, I like the idea of having a way of automatically includes components in the AjaxRequestTarget without the need to do it explicitly (target.add(..)), by using a Marking Interface and the Visitor, it really would make things easier when you want to add a new component to the current Ajax Response. The idea of the DynamicProxy seems very promising and i thinks it something way much better of having Pub/Sub event implementation. Just my +0.05 cents :) On Wed, Aug 25, 2010 at 9:11 AM, James Carman [via Apache Wicket] [hidden email] http://user/SendEmail.jtp?type=nodenode=2338212i=1[hidden email] http://user/SendEmail.jtp?type=nodenode=2338212i=2 wrote: What about if we modify this idea a bit? What if we use dynamic proxies to make it more generic? So, your onclick method would look like: public void onClick(AjaxRequestTarget target) { fire(MyCustomEventListener.class).someAjaxEvent(target); } Then, the fire() method would return an object (a dynamic proxy) that implements the MyCustomEventListener interface. The method implementation would do the visitor thing by looking for all components implementing the MyCustomEventListener interface and then call the someAjaxEvent() method. On Wed, Aug 25, 2010 at 5:10 AM, vladimir.kovalyuk [hidden email] http://user/SendEmail.jtp?type=nodenode=2338119i=0 wrote: I don't like subscriptions implementation. Somewhen it becomes difficult to realize when to add/remove observers. It depends on the order of instantiations. Visitor pattern seems to be much more reliable. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Best-practice-for-component-interaction-tp2336888p2337874.htmlhttp://apache-wicket.1842946.n4.nabble.com/Best-practice-for-component-interaction-tp2336888p2337874.html?by-user=t http://apache-wicket.1842946.n4.nabble.com/Best-practice-for-component-interaction-tp2336888p2337874.html?by-user=thttp://apache-wicket.1842946.n4.nabble.com/Best-practice-for-component-interaction-tp2336888p2337874.html?by-user=tby-user=t Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [hidden email] http://user/SendEmail.jtp?type=nodenode=2338119i=1 For additional commands, e-mail: [hidden email] http://user/SendEmail.jtp?type=nodenode=2338119i=2 - To unsubscribe, e-mail: [hidden email] http://user/SendEmail.jtp?type=nodenode=2338119i=3 For additional commands, e-mail: [hidden email] http://user/SendEmail.jtp?type=nodenode=2338119i=4 -- View message @ http://apache-wicket.1842946.n4.nabble.com/Best-practice-for-component-interaction-tp2336888p2338119.htmlhttp://apache-wicket.1842946.n4.nabble.com/Best-practice-for-component-interaction-tp2336888p2338119.html?by-user=t To unsubscribe from Apache Wicket, click here http://apache-wicket.1842946.n4.nabble.com/template/TplServlet.jtp?tpl=unsubscribe_by_codenode=1842946code=amNnYXJjaWFtQGdtYWlsLmNvbXwxODQyOTQ2fDEyNTYxMzc3ODY=http://apache-wicket.1842946.n4.nabble.com/template/TplServlet.jtp?tpl=unsubscribe_by_codenode=1842946code=amNnYXJjaWFtQGdtYWlsLmNvbXwxODQyOTQ2fDEyNTYxMzc3ODY=by-user=t. -- Sincerely, JC (http://www.linkedin.com/in/jcgarciam) Work smarter, not harder!. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Best-practice-for-component-interaction-tp2336888p2338205.htmlhttp://apache-wicket.1842946.n4.nabble.com/Best-practice-for-component-interaction-tp2336888p2338205.html?by-user=t Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [hidden email]http://user/SendEmail.jtp?type=nodenode=2338212i=3 For additional commands, e-mail: [hidden email]http://user/SendEmail.jtp?type=nodenode=2338212i=4 -- View message @ http://apache-wicket.1842946.n4.nabble.com/Best-practice-for-component-interaction-tp2336888p2338212.html To unsubscribe from Apache Wicket, click
Re: Best practice for component interaction
So, submit a JIRA with a patch once you get it working. It would be good to have this on the Page class so that it's portable (no casting). On Wed, Aug 25, 2010 at 9:12 AM, jcgarciam jcgarc...@gmail.com wrote: Thanks for expressing your help on this, im already working on it :-), since is not that hard to implement, but i would like to see this kind of functionality in the core . :) On Wed, Aug 25, 2010 at 10:09 AM, James Carman [via Apache Wicket] ml-node+2338212-617428318-65...@n4.nabble.comml-node%2b2338212-617428318-65...@n4.nabble.com wrote: Do you want an example of how it would work or are you confident in how to implement it yourself? On Wed, Aug 25, 2010 at 9:05 AM, jcgarciam [hidden email]http://user/SendEmail.jtp?type=nodenode=2338212i=0 wrote: Hi James, I like the idea of having a way of automatically includes components in the AjaxRequestTarget without the need to do it explicitly (target.add(..)), by using a Marking Interface and the Visitor, it really would make things easier when you want to add a new component to the current Ajax Response. The idea of the DynamicProxy seems very promising and i thinks it something way much better of having Pub/Sub event implementation. Just my +0.05 cents :) On Wed, Aug 25, 2010 at 9:11 AM, James Carman [via Apache Wicket] [hidden email] http://user/SendEmail.jtp?type=nodenode=2338212i=1[hidden email] http://user/SendEmail.jtp?type=nodenode=2338212i=2 wrote: What about if we modify this idea a bit? What if we use dynamic proxies to make it more generic? So, your onclick method would look like: public void onClick(AjaxRequestTarget target) { fire(MyCustomEventListener.class).someAjaxEvent(target); } Then, the fire() method would return an object (a dynamic proxy) that implements the MyCustomEventListener interface. The method implementation would do the visitor thing by looking for all components implementing the MyCustomEventListener interface and then call the someAjaxEvent() method. On Wed, Aug 25, 2010 at 5:10 AM, vladimir.kovalyuk [hidden email] http://user/SendEmail.jtp?type=nodenode=2338119i=0 wrote: I don't like subscriptions implementation. Somewhen it becomes difficult to realize when to add/remove observers. It depends on the order of instantiations. Visitor pattern seems to be much more reliable. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Best-practice-for-component-interaction-tp2336888p2337874.htmlhttp://apache-wicket.1842946.n4.nabble.com/Best-practice-for-component-interaction-tp2336888p2337874.html?by-user=t http://apache-wicket.1842946.n4.nabble.com/Best-practice-for-component-interaction-tp2336888p2337874.html?by-user=thttp://apache-wicket.1842946.n4.nabble.com/Best-practice-for-component-interaction-tp2336888p2337874.html?by-user=tby-user=t Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [hidden email] http://user/SendEmail.jtp?type=nodenode=2338119i=1 For additional commands, e-mail: [hidden email] http://user/SendEmail.jtp?type=nodenode=2338119i=2 - To unsubscribe, e-mail: [hidden email] http://user/SendEmail.jtp?type=nodenode=2338119i=3 For additional commands, e-mail: [hidden email] http://user/SendEmail.jtp?type=nodenode=2338119i=4 -- View message @ http://apache-wicket.1842946.n4.nabble.com/Best-practice-for-component-interaction-tp2336888p2338119.htmlhttp://apache-wicket.1842946.n4.nabble.com/Best-practice-for-component-interaction-tp2336888p2338119.html?by-user=t To unsubscribe from Apache Wicket, click here http://apache-wicket.1842946.n4.nabble.com/template/TplServlet.jtp?tpl=unsubscribe_by_codenode=1842946code=amNnYXJjaWFtQGdtYWlsLmNvbXwxODQyOTQ2fDEyNTYxMzc3ODY=http://apache-wicket.1842946.n4.nabble.com/template/TplServlet.jtp?tpl=unsubscribe_by_codenode=1842946code=amNnYXJjaWFtQGdtYWlsLmNvbXwxODQyOTQ2fDEyNTYxMzc3ODY=by-user=t. -- Sincerely, JC (http://www.linkedin.com/in/jcgarciam) Work smarter, not harder!. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Best-practice-for-component-interaction-tp2336888p2338205.htmlhttp://apache-wicket.1842946.n4.nabble.com/Best-practice-for-component-interaction-tp2336888p2338205.html?by-user=t Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [hidden email]http://user/SendEmail.jtp?type=nodenode=2338212i=3 For additional commands, e-mail: [hidden email]http://user/SendEmail.jtp?type=nodenode=2338212i=4 -- View message @
Re: Best practice for component interaction
There's an issue in trunk where they nail down the type parameter to extend Component on the visitChildren() method. If you're looking for a listener interface, that's not possible, because Component is a class and your listener interface can't extend that. Why the restriction? On Wed, Aug 25, 2010 at 9:35 AM, James Carman ja...@carmanconsulting.com wrote: So, submit a JIRA with a patch once you get it working. It would be good to have this on the Page class so that it's portable (no casting). On Wed, Aug 25, 2010 at 9:12 AM, jcgarciam jcgarc...@gmail.com wrote: Thanks for expressing your help on this, im already working on it :-), since is not that hard to implement, but i would like to see this kind of functionality in the core . :) On Wed, Aug 25, 2010 at 10:09 AM, James Carman [via Apache Wicket] ml-node+2338212-617428318-65...@n4.nabble.comml-node%2b2338212-617428318-65...@n4.nabble.com wrote: Do you want an example of how it would work or are you confident in how to implement it yourself? On Wed, Aug 25, 2010 at 9:05 AM, jcgarciam [hidden email]http://user/SendEmail.jtp?type=nodenode=2338212i=0 wrote: Hi James, I like the idea of having a way of automatically includes components in the AjaxRequestTarget without the need to do it explicitly (target.add(..)), by using a Marking Interface and the Visitor, it really would make things easier when you want to add a new component to the current Ajax Response. The idea of the DynamicProxy seems very promising and i thinks it something way much better of having Pub/Sub event implementation. Just my +0.05 cents :) On Wed, Aug 25, 2010 at 9:11 AM, James Carman [via Apache Wicket] [hidden email] http://user/SendEmail.jtp?type=nodenode=2338212i=1[hidden email] http://user/SendEmail.jtp?type=nodenode=2338212i=2 wrote: What about if we modify this idea a bit? What if we use dynamic proxies to make it more generic? So, your onclick method would look like: public void onClick(AjaxRequestTarget target) { fire(MyCustomEventListener.class).someAjaxEvent(target); } Then, the fire() method would return an object (a dynamic proxy) that implements the MyCustomEventListener interface. The method implementation would do the visitor thing by looking for all components implementing the MyCustomEventListener interface and then call the someAjaxEvent() method. On Wed, Aug 25, 2010 at 5:10 AM, vladimir.kovalyuk [hidden email] http://user/SendEmail.jtp?type=nodenode=2338119i=0 wrote: I don't like subscriptions implementation. Somewhen it becomes difficult to realize when to add/remove observers. It depends on the order of instantiations. Visitor pattern seems to be much more reliable. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Best-practice-for-component-interaction-tp2336888p2337874.htmlhttp://apache-wicket.1842946.n4.nabble.com/Best-practice-for-component-interaction-tp2336888p2337874.html?by-user=t http://apache-wicket.1842946.n4.nabble.com/Best-practice-for-component-interaction-tp2336888p2337874.html?by-user=thttp://apache-wicket.1842946.n4.nabble.com/Best-practice-for-component-interaction-tp2336888p2337874.html?by-user=tby-user=t Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [hidden email] http://user/SendEmail.jtp?type=nodenode=2338119i=1 For additional commands, e-mail: [hidden email] http://user/SendEmail.jtp?type=nodenode=2338119i=2 - To unsubscribe, e-mail: [hidden email] http://user/SendEmail.jtp?type=nodenode=2338119i=3 For additional commands, e-mail: [hidden email] http://user/SendEmail.jtp?type=nodenode=2338119i=4 -- View message @ http://apache-wicket.1842946.n4.nabble.com/Best-practice-for-component-interaction-tp2336888p2338119.htmlhttp://apache-wicket.1842946.n4.nabble.com/Best-practice-for-component-interaction-tp2336888p2338119.html?by-user=t To unsubscribe from Apache Wicket, click here http://apache-wicket.1842946.n4.nabble.com/template/TplServlet.jtp?tpl=unsubscribe_by_codenode=1842946code=amNnYXJjaWFtQGdtYWlsLmNvbXwxODQyOTQ2fDEyNTYxMzc3ODY=http://apache-wicket.1842946.n4.nabble.com/template/TplServlet.jtp?tpl=unsubscribe_by_codenode=1842946code=amNnYXJjaWFtQGdtYWlsLmNvbXwxODQyOTQ2fDEyNTYxMzc3ODY=by-user=t. -- Sincerely, JC (http://www.linkedin.com/in/jcgarciam) Work smarter, not harder!. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Best-practice-for-component-interaction-tp2336888p2338205.htmlhttp://apache-wicket.1842946.n4.nabble.com/Best-practice-for-component-interaction-tp2336888p2338205.html?by-user=t Sent from the Wicket - User mailing list archive at Nabble.com.
Re: Best practice for component interaction
already done https://issues.apache.org/jira/browse/WICKET-1312 -igor On Wed, Aug 25, 2010 at 6:12 AM, jcgarciam jcgarc...@gmail.com wrote: Thanks for expressing your help on this, im already working on it :-), since is not that hard to implement, but i would like to see this kind of functionality in the core . :) On Wed, Aug 25, 2010 at 10:09 AM, James Carman [via Apache Wicket] ml-node+2338212-617428318-65...@n4.nabble.comml-node%2b2338212-617428318-65...@n4.nabble.com wrote: Do you want an example of how it would work or are you confident in how to implement it yourself? On Wed, Aug 25, 2010 at 9:05 AM, jcgarciam [hidden email]http://user/SendEmail.jtp?type=nodenode=2338212i=0 wrote: Hi James, I like the idea of having a way of automatically includes components in the AjaxRequestTarget without the need to do it explicitly (target.add(..)), by using a Marking Interface and the Visitor, it really would make things easier when you want to add a new component to the current Ajax Response. The idea of the DynamicProxy seems very promising and i thinks it something way much better of having Pub/Sub event implementation. Just my +0.05 cents :) On Wed, Aug 25, 2010 at 9:11 AM, James Carman [via Apache Wicket] [hidden email] http://user/SendEmail.jtp?type=nodenode=2338212i=1[hidden email] http://user/SendEmail.jtp?type=nodenode=2338212i=2 wrote: What about if we modify this idea a bit? What if we use dynamic proxies to make it more generic? So, your onclick method would look like: public void onClick(AjaxRequestTarget target) { fire(MyCustomEventListener.class).someAjaxEvent(target); } Then, the fire() method would return an object (a dynamic proxy) that implements the MyCustomEventListener interface. The method implementation would do the visitor thing by looking for all components implementing the MyCustomEventListener interface and then call the someAjaxEvent() method. On Wed, Aug 25, 2010 at 5:10 AM, vladimir.kovalyuk [hidden email] http://user/SendEmail.jtp?type=nodenode=2338119i=0 wrote: I don't like subscriptions implementation. Somewhen it becomes difficult to realize when to add/remove observers. It depends on the order of instantiations. Visitor pattern seems to be much more reliable. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Best-practice-for-component-interaction-tp2336888p2337874.htmlhttp://apache-wicket.1842946.n4.nabble.com/Best-practice-for-component-interaction-tp2336888p2337874.html?by-user=t http://apache-wicket.1842946.n4.nabble.com/Best-practice-for-component-interaction-tp2336888p2337874.html?by-user=thttp://apache-wicket.1842946.n4.nabble.com/Best-practice-for-component-interaction-tp2336888p2337874.html?by-user=tby-user=t Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [hidden email] http://user/SendEmail.jtp?type=nodenode=2338119i=1 For additional commands, e-mail: [hidden email] http://user/SendEmail.jtp?type=nodenode=2338119i=2 - To unsubscribe, e-mail: [hidden email] http://user/SendEmail.jtp?type=nodenode=2338119i=3 For additional commands, e-mail: [hidden email] http://user/SendEmail.jtp?type=nodenode=2338119i=4 -- View message @ http://apache-wicket.1842946.n4.nabble.com/Best-practice-for-component-interaction-tp2336888p2338119.htmlhttp://apache-wicket.1842946.n4.nabble.com/Best-practice-for-component-interaction-tp2336888p2338119.html?by-user=t To unsubscribe from Apache Wicket, click here http://apache-wicket.1842946.n4.nabble.com/template/TplServlet.jtp?tpl=unsubscribe_by_codenode=1842946code=amNnYXJjaWFtQGdtYWlsLmNvbXwxODQyOTQ2fDEyNTYxMzc3ODY=http://apache-wicket.1842946.n4.nabble.com/template/TplServlet.jtp?tpl=unsubscribe_by_codenode=1842946code=amNnYXJjaWFtQGdtYWlsLmNvbXwxODQyOTQ2fDEyNTYxMzc3ODY=by-user=t. -- Sincerely, JC (http://www.linkedin.com/in/jcgarciam) Work smarter, not harder!. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Best-practice-for-component-interaction-tp2336888p2338205.htmlhttp://apache-wicket.1842946.n4.nabble.com/Best-practice-for-component-interaction-tp2336888p2338205.html?by-user=t Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [hidden email]http://user/SendEmail.jtp?type=nodenode=2338212i=3 For additional commands, e-mail: [hidden email]http://user/SendEmail.jtp?type=nodenode=2338212i=4 -- View message @ http://apache-wicket.1842946.n4.nabble.com/Best-practice-for-component-interaction-tp2336888p2338212.html To unsubscribe
Re: Best practice for component interaction
James, taking Igor example why not providing simple marking interfaces in the Core and then something like this in the Page implementation, (i was thinking of the Dynamic Proxy approach you mention, but i'm not seeing why it would be needed here since all you want is to propagate the Component re-rendering into the current AjaxRequestTarget) i.e: Defining a root Event named: AjaxEventResponseListener then defining a simple method in base page: protected void propagateAjaxEvent(Class? extends AjaxEventResponseListener listener, final AjaxRequestTarget target) { getPage().visitChildren(listener, new IVisitorComponent() { public Object component(Component component) { target.addComponent(component); return CONTINUE_TRAVERSAL_BUT_DONT_GO_DEEPER; } }); } On Wed, Aug 25, 2010 at 11:08 AM, James Carman [via Apache Wicket] ml-node+2338298-400135988-65...@n4.nabble.comml-node%2b2338298-400135988-65...@n4.nabble.com wrote: There's an issue in trunk where they nail down the type parameter to extend Component on the visitChildren() method. If you're looking for a listener interface, that's not possible, because Component is a class and your listener interface can't extend that. Why the restriction? On Wed, Aug 25, 2010 at 9:35 AM, James Carman [hidden email] http://user/SendEmail.jtp?type=nodenode=2338298i=0 wrote: So, submit a JIRA with a patch once you get it working. It would be good to have this on the Page class so that it's portable (no casting). On Wed, Aug 25, 2010 at 9:12 AM, jcgarciam [hidden email]http://user/SendEmail.jtp?type=nodenode=2338298i=1 wrote: Thanks for expressing your help on this, im already working on it :-), since is not that hard to implement, but i would like to see this kind of functionality in the core . :) On Wed, Aug 25, 2010 at 10:09 AM, James Carman [via Apache Wicket] [hidden email] http://user/SendEmail.jtp?type=nodenode=2338298i=2[hidden email] http://user/SendEmail.jtp?type=nodenode=2338298i=3 wrote: Do you want an example of how it would work or are you confident in how to implement it yourself? On Wed, Aug 25, 2010 at 9:05 AM, jcgarciam [hidden email] http://user/SendEmail.jtp?type=nodenode=2338212i=0 wrote: Hi James, I like the idea of having a way of automatically includes components in the AjaxRequestTarget without the need to do it explicitly (target.add(..)), by using a Marking Interface and the Visitor, it really would make things easier when you want to add a new component to the current Ajax Response. The idea of the DynamicProxy seems very promising and i thinks it something way much better of having Pub/Sub event implementation. Just my +0.05 cents :) On Wed, Aug 25, 2010 at 9:11 AM, James Carman [via Apache Wicket] [hidden email] http://user/SendEmail.jtp?type=nodenode=2338212i=1[hidden email] http://user/SendEmail.jtp?type=nodenode=2338212i=2 wrote: What about if we modify this idea a bit? What if we use dynamic proxies to make it more generic? So, your onclick method would look like: public void onClick(AjaxRequestTarget target) { fire(MyCustomEventListener.class).someAjaxEvent(target); } Then, the fire() method would return an object (a dynamic proxy) that implements the MyCustomEventListener interface. The method implementation would do the visitor thing by looking for all components implementing the MyCustomEventListener interface and then call the someAjaxEvent() method. On Wed, Aug 25, 2010 at 5:10 AM, vladimir.kovalyuk [hidden email] http://user/SendEmail.jtp?type=nodenode=2338119i=0 wrote: I don't like subscriptions implementation. Somewhen it becomes difficult to realize when to add/remove observers. It depends on the order of instantiations. Visitor pattern seems to be much more reliable. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Best-practice-for-component-interaction-tp2336888p2337874.htmlhttp://apache-wicket.1842946.n4.nabble.com/Best-practice-for-component-interaction-tp2336888p2337874.html?by-user=t http://apache-wicket.1842946.n4.nabble.com/Best-practice-for-component-interaction-tp2336888p2337874.html?by-user=thttp://apache-wicket.1842946.n4.nabble.com/Best-practice-for-component-interaction-tp2336888p2337874.html?by-user=tby-user=t http://apache-wicket.1842946.n4.nabble.com/Best-practice-for-component-interaction-tp2336888p2337874.html?by-user=thttp://apache-wicket.1842946.n4.nabble.com/Best-practice-for-component-interaction-tp2336888p2337874.html?by-user=tby-user=t http://apache-wicket.1842946.n4.nabble.com/Best-practice-for-component-interaction-tp2336888p2337874.html?by-user=tby-user=thttp://apache-wicket.1842946.n4.nabble.com/Best-practice-for-component-interaction-tp2336888p2337874.html?by-user=tby-user=tby-user=t Sent from the Wicket - User mailing list
Re: Best practice for component interaction
Thanks Igor, i will review that Item. On Wed, Aug 25, 2010 at 11:46 AM, Igor Vaynberg-2 [via Apache Wicket] ml-node+2338351-880928828-65...@n4.nabble.comml-node%2b2338351-880928828-65...@n4.nabble.com wrote: already done https://issues.apache.org/jira/browse/WICKET-1312 -igor On Wed, Aug 25, 2010 at 6:12 AM, jcgarciam [hidden email]http://user/SendEmail.jtp?type=nodenode=2338351i=0 wrote: Thanks for expressing your help on this, im already working on it :-), since is not that hard to implement, but i would like to see this kind of functionality in the core . :) On Wed, Aug 25, 2010 at 10:09 AM, James Carman [via Apache Wicket] [hidden email] http://user/SendEmail.jtp?type=nodenode=2338351i=1[hidden email] http://user/SendEmail.jtp?type=nodenode=2338351i=2 wrote: Do you want an example of how it would work or are you confident in how to implement it yourself? On Wed, Aug 25, 2010 at 9:05 AM, jcgarciam [hidden email] http://user/SendEmail.jtp?type=nodenode=2338212i=0 wrote: Hi James, I like the idea of having a way of automatically includes components in the AjaxRequestTarget without the need to do it explicitly (target.add(..)), by using a Marking Interface and the Visitor, it really would make things easier when you want to add a new component to the current Ajax Response. The idea of the DynamicProxy seems very promising and i thinks it something way much better of having Pub/Sub event implementation. Just my +0.05 cents :) On Wed, Aug 25, 2010 at 9:11 AM, James Carman [via Apache Wicket] [hidden email] http://user/SendEmail.jtp?type=nodenode=2338212i=1[hidden email] http://user/SendEmail.jtp?type=nodenode=2338212i=2 wrote: What about if we modify this idea a bit? What if we use dynamic proxies to make it more generic? So, your onclick method would look like: public void onClick(AjaxRequestTarget target) { fire(MyCustomEventListener.class).someAjaxEvent(target); } Then, the fire() method would return an object (a dynamic proxy) that implements the MyCustomEventListener interface. The method implementation would do the visitor thing by looking for all components implementing the MyCustomEventListener interface and then call the someAjaxEvent() method. On Wed, Aug 25, 2010 at 5:10 AM, vladimir.kovalyuk [hidden email] http://user/SendEmail.jtp?type=nodenode=2338119i=0 wrote: I don't like subscriptions implementation. Somewhen it becomes difficult to realize when to add/remove observers. It depends on the order of instantiations. Visitor pattern seems to be much more reliable. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Best-practice-for-component-interaction-tp2336888p2337874.htmlhttp://apache-wicket.1842946.n4.nabble.com/Best-practice-for-component-interaction-tp2336888p2337874.html?by-user=t http://apache-wicket.1842946.n4.nabble.com/Best-practice-for-component-interaction-tp2336888p2337874.html?by-user=thttp://apache-wicket.1842946.n4.nabble.com/Best-practice-for-component-interaction-tp2336888p2337874.html?by-user=tby-user=t http://apache-wicket.1842946.n4.nabble.com/Best-practice-for-component-interaction-tp2336888p2337874.html?by-user=thttp://apache-wicket.1842946.n4.nabble.com/Best-practice-for-component-interaction-tp2336888p2337874.html?by-user=tby-user=t http://apache-wicket.1842946.n4.nabble.com/Best-practice-for-component-interaction-tp2336888p2337874.html?by-user=tby-user=thttp://apache-wicket.1842946.n4.nabble.com/Best-practice-for-component-interaction-tp2336888p2337874.html?by-user=tby-user=tby-user=t Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [hidden email] http://user/SendEmail.jtp?type=nodenode=2338119i=1 For additional commands, e-mail: [hidden email] http://user/SendEmail.jtp?type=nodenode=2338119i=2 - To unsubscribe, e-mail: [hidden email] http://user/SendEmail.jtp?type=nodenode=2338119i=3 For additional commands, e-mail: [hidden email] http://user/SendEmail.jtp?type=nodenode=2338119i=4 -- View message @ http://apache-wicket.1842946.n4.nabble.com/Best-practice-for-component-interaction-tp2336888p2338119.htmlhttp://apache-wicket.1842946.n4.nabble.com/Best-practice-for-component-interaction-tp2336888p2338119.html?by-user=t http://apache-wicket.1842946.n4.nabble.com/Best-practice-for-component-interaction-tp2336888p2338119.html?by-user=thttp://apache-wicket.1842946.n4.nabble.com/Best-practice-for-component-interaction-tp2336888p2338119.html?by-user=tby-user=t To unsubscribe from Apache Wicket, click here
Re: Best practice for component interaction
What if you have different event types that happen on a page? On Wed, Aug 25, 2010 at 10:47 AM, jcgarciam jcgarc...@gmail.com wrote: James, taking Igor example why not providing simple marking interfaces in the Core and then something like this in the Page implementation, (i was thinking of the Dynamic Proxy approach you mention, but i'm not seeing why it would be needed here since all you want is to propagate the Component re-rendering into the current AjaxRequestTarget) i.e: Defining a root Event named: AjaxEventResponseListener then defining a simple method in base page: protected void propagateAjaxEvent(Class? extends AjaxEventResponseListener listener, final AjaxRequestTarget target) { getPage().visitChildren(listener, new IVisitorComponent() { public Object component(Component component) { target.addComponent(component); return CONTINUE_TRAVERSAL_BUT_DONT_GO_DEEPER; } }); } On Wed, Aug 25, 2010 at 11:08 AM, James Carman [via Apache Wicket] ml-node+2338298-400135988-65...@n4.nabble.comml-node%2b2338298-400135988-65...@n4.nabble.com wrote: There's an issue in trunk where they nail down the type parameter to extend Component on the visitChildren() method. If you're looking for a listener interface, that's not possible, because Component is a class and your listener interface can't extend that. Why the restriction? On Wed, Aug 25, 2010 at 9:35 AM, James Carman [hidden email] http://user/SendEmail.jtp?type=nodenode=2338298i=0 wrote: So, submit a JIRA with a patch once you get it working. It would be good to have this on the Page class so that it's portable (no casting). On Wed, Aug 25, 2010 at 9:12 AM, jcgarciam [hidden email]http://user/SendEmail.jtp?type=nodenode=2338298i=1 wrote: Thanks for expressing your help on this, im already working on it :-), since is not that hard to implement, but i would like to see this kind of functionality in the core . :) On Wed, Aug 25, 2010 at 10:09 AM, James Carman [via Apache Wicket] [hidden email] http://user/SendEmail.jtp?type=nodenode=2338298i=2[hidden email] http://user/SendEmail.jtp?type=nodenode=2338298i=3 wrote: Do you want an example of how it would work or are you confident in how to implement it yourself? On Wed, Aug 25, 2010 at 9:05 AM, jcgarciam [hidden email] http://user/SendEmail.jtp?type=nodenode=2338212i=0 wrote: Hi James, I like the idea of having a way of automatically includes components in the AjaxRequestTarget without the need to do it explicitly (target.add(..)), by using a Marking Interface and the Visitor, it really would make things easier when you want to add a new component to the current Ajax Response. The idea of the DynamicProxy seems very promising and i thinks it something way much better of having Pub/Sub event implementation. Just my +0.05 cents :) On Wed, Aug 25, 2010 at 9:11 AM, James Carman [via Apache Wicket] [hidden email] http://user/SendEmail.jtp?type=nodenode=2338212i=1[hidden email] http://user/SendEmail.jtp?type=nodenode=2338212i=2 wrote: What about if we modify this idea a bit? What if we use dynamic proxies to make it more generic? So, your onclick method would look like: public void onClick(AjaxRequestTarget target) { fire(MyCustomEventListener.class).someAjaxEvent(target); } Then, the fire() method would return an object (a dynamic proxy) that implements the MyCustomEventListener interface. The method implementation would do the visitor thing by looking for all components implementing the MyCustomEventListener interface and then call the someAjaxEvent() method. On Wed, Aug 25, 2010 at 5:10 AM, vladimir.kovalyuk [hidden email] http://user/SendEmail.jtp?type=nodenode=2338119i=0 wrote: I don't like subscriptions implementation. Somewhen it becomes difficult to realize when to add/remove observers. It depends on the order of instantiations. Visitor pattern seems to be much more reliable. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Best-practice-for-component-interaction-tp2336888p2337874.htmlhttp://apache-wicket.1842946.n4.nabble.com/Best-practice-for-component-interaction-tp2336888p2337874.html?by-user=t http://apache-wicket.1842946.n4.nabble.com/Best-practice-for-component-interaction-tp2336888p2337874.html?by-user=thttp://apache-wicket.1842946.n4.nabble.com/Best-practice-for-component-interaction-tp2336888p2337874.html?by-user=tby-user=t http://apache-wicket.1842946.n4.nabble.com/Best-practice-for-component-interaction-tp2336888p2337874.html?by-user=thttp://apache-wicket.1842946.n4.nabble.com/Best-practice-for-component-interaction-tp2336888p2337874.html?by-user=tby-user=t
Re: Best practice for component interaction
Let see if this answer your question, in my example i have this Interface: [AjaxEventResponseListener] as root Event interface Then i have 2 more specifics interfaces named: [MyHomePageEvent1] and [MyHomePageEvent2] Now i have 2 panels component: 1-CounterPanel extends Panel implements MyHomePageEvent1 2-MessagePanel extends Panel implements MyHomePageEvent2 And in finally in HomePage i added them and provide several link to test them: code add(new AjaxLinkInteger(counterInc1) { @Override public void onClick(final AjaxRequestTarget target) { HomePage.this.updateCounter(); propagateAjaxEvent(MyHomePageEvent1.class, target); //Only CounterPanel get Updated } }); add(new AjaxLinkInteger(counterInc2) { @Override public void onClick(final AjaxRequestTarget target) { HomePage.this.updateCounter(); propagateAjaxEvent(MyHomePageEvent2.class, target); // Only MessagePanel get Updated } }); add(new AjaxLinkInteger(counterInc3) { @Override public void onClick(final AjaxRequestTarget target) { HomePage.this.updateCounter(); propagateAjaxEvent(AjaxEventResponseListener.class, target); // Both Panel get Updated } }); /code Are we on the same page? On Wed, Aug 25, 2010 at 12:00 PM, James Carman [via Apache Wicket] ml-node+2338371-59596-65...@n4.nabble.comml-node%2b2338371-59596-65...@n4.nabble.com wrote: What if you have different event types that happen on a page? On Wed, Aug 25, 2010 at 10:47 AM, jcgarciam [hidden email]http://user/SendEmail.jtp?type=nodenode=2338371i=0 wrote: James, taking Igor example why not providing simple marking interfaces in the Core and then something like this in the Page implementation, (i was thinking of the Dynamic Proxy approach you mention, but i'm not seeing why it would be needed here since all you want is to propagate the Component re-rendering into the current AjaxRequestTarget) i.e: Defining a root Event named: AjaxEventResponseListener then defining a simple method in base page: protected void propagateAjaxEvent(Class? extends AjaxEventResponseListener listener, final AjaxRequestTarget target) { getPage().visitChildren(listener, new IVisitorComponent() { public Object component(Component component) { target.addComponent(component); return CONTINUE_TRAVERSAL_BUT_DONT_GO_DEEPER; } }); } On Wed, Aug 25, 2010 at 11:08 AM, James Carman [via Apache Wicket] [hidden email] http://user/SendEmail.jtp?type=nodenode=2338371i=1[hidden email] http://user/SendEmail.jtp?type=nodenode=2338371i=2 wrote: There's an issue in trunk where they nail down the type parameter to extend Component on the visitChildren() method. If you're looking for a listener interface, that's not possible, because Component is a class and your listener interface can't extend that. Why the restriction? On Wed, Aug 25, 2010 at 9:35 AM, James Carman [hidden email] http://user/SendEmail.jtp?type=nodenode=2338298i=0 wrote: So, submit a JIRA with a patch once you get it working. It would be good to have this on the Page class so that it's portable (no casting). On Wed, Aug 25, 2010 at 9:12 AM, jcgarciam [hidden email] http://user/SendEmail.jtp?type=nodenode=2338298i=1 wrote: Thanks for expressing your help on this, im already working on it :-), since is not that hard to implement, but i would like to see this kind of functionality in the core . :) On Wed, Aug 25, 2010 at 10:09 AM, James Carman [via Apache Wicket] [hidden email] http://user/SendEmail.jtp?type=nodenode=2338298i=2[hidden email] http://user/SendEmail.jtp?type=nodenode=2338298i=3 wrote: Do you want an example of how it would work or are you confident in how to implement it yourself? On Wed, Aug 25, 2010 at 9:05 AM, jcgarciam [hidden email] http://user/SendEmail.jtp?type=nodenode=2338212i=0 wrote: Hi James, I like the idea of having a way of automatically includes components in the AjaxRequestTarget without the need to do it explicitly (target.add(..)), by using a Marking Interface and the Visitor, it really would make things easier when you want to add a new component to the current Ajax Response. The idea of the DynamicProxy seems very promising and i thinks it something way much better of having Pub/Sub event implementation. Just my +0.05 cents :) On Wed, Aug 25, 2010 at 9:11 AM, James Carman [via Apache Wicket] [hidden email] http://user/SendEmail.jtp?type=nodenode=2338212i=1[hidden email] http://user/SendEmail.jtp?type=nodenode=2338212i=2 wrote: What about if we modify this idea a bit? What if we use dynamic proxies to make it more generic? So, your onclick method would look like: public void onClick(AjaxRequestTarget target) { fire(MyCustomEventListener.class).someAjaxEvent(target); } Then, the fire()
Re: Best practice for component interaction
Not exactly. Here's how I would implement your example 1. You'd have three interfaces AjaxEventListener, MyHomePageListener1, MyHomePageListener2. 2. Then you'd have the panels that implement the interfaces. 3. Then, in your home page, you'd do: add(new AjaxLinkInteger(counterInc1) { public void onClick( AjaxRequestTarget target ) { updateCounter(); fire(MyHomePageListener1.class).event1Happened(target); } } ); add(new AjaxLinkInteger(counterInc2) { public void onClick(AjaxRequestTarget target ) { updateCounter(); fire(MyHomePageListener2.class).event2Happened(target); } } ); add(new AjaxLinkInteger(counterInc3) { public void onClick(AjaxRequestTarget target ) { updateCounter(); fire(AjaxEventListener.class).onAjaxEvent(target); } } ); I wouldn't use marker interfaces. I'd use real listener interfaces with method names that reflect what the event is. It makes the code more readable. On Wed, Aug 25, 2010 at 11:09 AM, jcgarciam jcgarc...@gmail.com wrote: Let see if this answer your question, in my example i have this Interface: [AjaxEventResponseListener] as root Event interface Then i have 2 more specifics interfaces named: [MyHomePageEvent1] and [MyHomePageEvent2] Now i have 2 panels component: 1- CounterPanel extends Panel implements MyHomePageEvent1 2- MessagePanel extends Panel implements MyHomePageEvent2 And in finally in HomePage i added them and provide several link to test them: code add(new AjaxLinkInteger(counterInc1) { �...@override public void onClick(final AjaxRequestTarget target) { HomePage.this.updateCounter(); propagateAjaxEvent(MyHomePageEvent1.class, target); //Only CounterPanel get Updated } }); add(new AjaxLinkInteger(counterInc2) { �...@override public void onClick(final AjaxRequestTarget target) { HomePage.this.updateCounter(); propagateAjaxEvent(MyHomePageEvent2.class, target); // Only MessagePanel get Updated } }); add(new AjaxLinkInteger(counterInc3) { �...@override public void onClick(final AjaxRequestTarget target) { HomePage.this.updateCounter(); propagateAjaxEvent(AjaxEventResponseListener.class, target); // Both Panel get Updated } }); /code Are we on the same page? On Wed, Aug 25, 2010 at 12:00 PM, James Carman [via Apache Wicket] ml-node+2338371-59596-65...@n4.nabble.comml-node%2b2338371-59596-65...@n4.nabble.com wrote: What if you have different event types that happen on a page? On Wed, Aug 25, 2010 at 10:47 AM, jcgarciam [hidden email]http://user/SendEmail.jtp?type=nodenode=2338371i=0 wrote: James, taking Igor example why not providing simple marking interfaces in the Core and then something like this in the Page implementation, (i was thinking of the Dynamic Proxy approach you mention, but i'm not seeing why it would be needed here since all you want is to propagate the Component re-rendering into the current AjaxRequestTarget) i.e: Defining a root Event named: AjaxEventResponseListener then defining a simple method in base page: protected void propagateAjaxEvent(Class? extends AjaxEventResponseListener listener, final AjaxRequestTarget target) { getPage().visitChildren(listener, new IVisitorComponent() { public Object component(Component component) { target.addComponent(component); return CONTINUE_TRAVERSAL_BUT_DONT_GO_DEEPER; } }); } On Wed, Aug 25, 2010 at 11:08 AM, James Carman [via Apache Wicket] [hidden email] http://user/SendEmail.jtp?type=nodenode=2338371i=1[hidden email] http://user/SendEmail.jtp?type=nodenode=2338371i=2 wrote: There's an issue in trunk where they nail down the type parameter to extend Component on the visitChildren() method. If you're looking for a listener interface, that's not possible, because Component is a class and your listener interface can't extend that. Why the restriction? On Wed, Aug 25, 2010 at 9:35 AM, James Carman [hidden email] http://user/SendEmail.jtp?type=nodenode=2338298i=0 wrote: So, submit a JIRA with a patch once you get it working. It would be good to have this on the Page class so that it's portable (no casting). On Wed, Aug 25, 2010 at 9:12 AM, jcgarciam [hidden email] http://user/SendEmail.jtp?type=nodenode=2338298i=1 wrote: Thanks for expressing your help on this, im already working on it :-), since is not that hard to implement, but i would like to see this kind of functionality in the core . :) On Wed, Aug 25, 2010 at 10:09 AM, James Carman [via Apache Wicket] [hidden email] http://user/SendEmail.jtp?type=nodenode=2338298i=2[hidden email] http://user/SendEmail.jtp?type=nodenode=2338298i=3 wrote: Do you want an example of how it would work or are you confident in how to implement it yourself? On Wed, Aug 25, 2010 at 9:05 AM, jcgarciam [hidden email] http://user/SendEmail.jtp?type=nodenode=2338212i=0 wrote:
Re: Best practice for component interaction
I guess we are targeting different things here, a) You want to control on each Interfaces implementation what component should be added by passing the [target] around b) I want to just add the component automatically to the ajax response if it just implement the Event Interface, imagine a Very rich component UI and where a lots of component get added to the AjaxTarget, and later you need to add another component for what ever reason. After that you need to go an manually push the component to the target, i would just let the component implement the market interfaces and get re-render automatically. Thanks for sharing your thoughts. On Wed, Aug 25, 2010 at 12:27 PM, James Carman [via Apache Wicket] ml-node+2338421-1360946432-65...@n4.nabble.comml-node%2b2338421-1360946432-65...@n4.nabble.com wrote: Not exactly. Here's how I would implement your example 1. You'd have three interfaces AjaxEventListener, MyHomePageListener1, MyHomePageListener2. 2. Then you'd have the panels that implement the interfaces. 3. Then, in your home page, you'd do: add(new AjaxLinkInteger(counterInc1) { public void onClick( AjaxRequestTarget target ) { updateCounter(); fire(MyHomePageListener1.class).event1Happened(target); } } ); add(new AjaxLinkInteger(counterInc2) { public void onClick(AjaxRequestTarget target ) { updateCounter(); fire(MyHomePageListener2.class).event2Happened(target); } } ); add(new AjaxLinkInteger(counterInc3) { public void onClick(AjaxRequestTarget target ) { updateCounter(); fire(AjaxEventListener.class).onAjaxEvent(target); } } ); I wouldn't use marker interfaces. I'd use real listener interfaces with method names that reflect what the event is. It makes the code more readable. On Wed, Aug 25, 2010 at 11:09 AM, jcgarciam [hidden email]http://user/SendEmail.jtp?type=nodenode=2338421i=0 wrote: Let see if this answer your question, in my example i have this Interface: [AjaxEventResponseListener] as root Event interface Then i have 2 more specifics interfaces named: [MyHomePageEvent1] and [MyHomePageEvent2] Now i have 2 panels component: 1-CounterPanel extends Panel implements MyHomePageEvent1 2-MessagePanel extends Panel implements MyHomePageEvent2 And in finally in HomePage i added them and provide several link to test them: code add(new AjaxLinkInteger(counterInc1) { @Override public void onClick(final AjaxRequestTarget target) { HomePage.this.updateCounter(); propagateAjaxEvent(MyHomePageEvent1.class, target); //Only CounterPanel get Updated } }); add(new AjaxLinkInteger(counterInc2) { @Override public void onClick(final AjaxRequestTarget target) { HomePage.this.updateCounter(); propagateAjaxEvent(MyHomePageEvent2.class, target); // Only MessagePanel get Updated } }); add(new AjaxLinkInteger(counterInc3) { @Override public void onClick(final AjaxRequestTarget target) { HomePage.this.updateCounter(); propagateAjaxEvent(AjaxEventResponseListener.class, target); // Both Panel get Updated } }); /code Are we on the same page? On Wed, Aug 25, 2010 at 12:00 PM, James Carman [via Apache Wicket] [hidden email] http://user/SendEmail.jtp?type=nodenode=2338421i=1[hidden email] http://user/SendEmail.jtp?type=nodenode=2338421i=2 wrote: What if you have different event types that happen on a page? On Wed, Aug 25, 2010 at 10:47 AM, jcgarciam [hidden email] http://user/SendEmail.jtp?type=nodenode=2338371i=0 wrote: James, taking Igor example why not providing simple marking interfaces in the Core and then something like this in the Page implementation, (i was thinking of the Dynamic Proxy approach you mention, but i'm not seeing why it would be needed here since all you want is to propagate the Component re-rendering into the current AjaxRequestTarget) i.e: Defining a root Event named: AjaxEventResponseListener then defining a simple method in base page: protected void propagateAjaxEvent(Class? extends AjaxEventResponseListener listener, final AjaxRequestTarget target) { getPage().visitChildren(listener, new IVisitorComponent() { public Object component(Component component) { target.addComponent(component); return CONTINUE_TRAVERSAL_BUT_DONT_GO_DEEPER; } }); } On Wed, Aug 25, 2010 at 11:08 AM, James Carman [via Apache Wicket] [hidden email] http://user/SendEmail.jtp?type=nodenode=2338371i=1[hidden email] http://user/SendEmail.jtp?type=nodenode=2338371i=2 wrote: There's an issue in trunk where they nail down the type parameter to extend Component on the visitChildren() method. If you're looking for a listener interface, that's not possible, because Component is a class and your listener interface can't extend that. Why the restriction? On Wed, Aug 25, 2010 at
Re: Downloading generated PDF behavior different with apache in front of appserver
Are you using IE? There are many troubles generating PDF over SSL. See for an example : http://eirikhoem.wordpress.com/2007/06/15/generated-pdfs-over-https-with-internet-explorer/ http://eirikhoem.wordpress.com/2007/06/15/generated-pdfs-over-https-with-internet-explorer/ If you google IE PDF SSL, you will find many answers. Here's the workaround I use in my wicket applications (i'm generating PDF with jasperreports) : WebResponse response = (WebResponse) getRequestCycle().getResponse(); response.setDateHeader(Expires, -1); response.setHeader(Pragma, public); response.setHeader(Cache-Control, public); Regards, Gabriel. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Downloading-generated-PDF-behavior-different-with-apache-in-front-of-appserver-tp2336943p2338770.html Sent from the Wicket - User 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: How to show any type of exception in feedbackpanel or in popup window
you could catch them in the request cycle? 2010/8/25 arunarapole arunakumm...@gmail.com Hi I have a Exception called Violation of UNIQUE KEY constraint 'UQ__usr__FE76F85348BAC3E5'. Cannot insert duplicate key in object abc table above Exception i have to display in same page feedbackpanel or in popup window . If any one knows about please post me your ideas Thank you Aruna -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/How-to-show-any-type-of-exception-in-feedbackpanel-or-in-popup-window-tp2338841p2338841.html Sent from the Wicket - User 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: How to show any type of exception in feedbackpanel or in popup window
put that around the code in your page that causes the exception: try { databaseMethodThatThrows(); } catch(DatabaseException x) { error(e.getMessage); } Am 25.08.2010 um 22:46 schrieb nino martinez wael: you could catch them in the request cycle? 2010/8/25 arunarapole arunakumm...@gmail.com Hi I have a Exception called Violation of UNIQUE KEY constraint 'UQ__usr__FE76F85348BAC3E5'. Cannot insert duplicate key in object abc table above Exception i have to display in same page feedbackpanel or in popup window . If any one knows about please post me your ideas Thank you Aruna -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/How-to-show-any-type-of-exception-in-feedbackpanel-or-in-popup-window-tp2338841p2338841.html Sent from the Wicket - User 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