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: 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
herehttp://apache-wicket.1842946.n4.nabble.com/template/TplServlet.jtp?tpl=unsubscribe_by_codenode=1842946code
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 @
http://apache-wicket.1842946.n4.nabble.com/Best
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
http://apache-wicket.1842946.n4.nabble.com
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
http://apache-wicket.1842946.n4.nabble.com/Best-practice-for-component-interaction-tp2336888p2337874.html?by-user=tby-user=thttp://apache-wicket.1842946
Re: Best practice for component interaction
() 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 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 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 http://apache-wicket.1842946.n4.nabble.com/Best-practice-for-component-interaction-tp2336888p2337874.html?by-user=tby-user=tby-user=thttp://apache-wicket.1842946.n4.nabble.com/Best-practice-for-component-interaction-tp2336888p2337874.html?by-user=tby-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 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 http://apache-wicket.1842946.n4.nabble.com/Best-practice-for-component-interaction-tp2336888p2338119.html?by-user=tby-user=thttp://apache-wicket.1842946.n4.nabble.com/Best-practice-for-component-interaction-tp2336888p2338119.html?by-user=tby-user=tby-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 http://apache-wicket.1842946.n4.nabble.com/template/TplServlet.jtp?tpl=unsubscribe_by_codenode=1842946code
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]
[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
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
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
http://apache-wicket.1842946.n4.nabble.com/Best-practice-for-component-interaction-tp2336888p2337874.html?by-user=tby-user=tby-user=thttp://apache-wicket.1842946.n4.nabble.com/Best-practice-for-component-interaction-tp2336888p2337874.html?by-user=tby-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
Re: Best practice for component interaction
: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
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
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
http://apache-wicket.1842946.n4.nabble.com/Best-practice-for-component-interaction-tp2336888p2337874.html?by-user=tby-user=tby-user=thttp://apache-wicket.1842946.n4.nabble.com/Best-practice-for-component-interaction-tp2336888p2337874.html?by-user=tby-user=tby-user=tby-user=t
http://apache-wicket
Best practice for component interaction
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: Best practice for component interaction
usually this kind of linkage is created by pointing both the calendar and the textfield to the same model object, like a property of a common parent, etc. -igor On Tue, Aug 24, 2010 at 8:37 AM, 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 - 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
Yes, but how do you make sure all the components that need to be updated via ajax are updated? They can point to the same model, but if they're not added to the AjaxRequestTarget, then they won't be updated when their values change. You'd need some sort of event listener I would think (unless you want to pass around references to the components that need updating). On Tue, Aug 24, 2010 at 12:56 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote: usually this kind of linkage is created by pointing both the calendar and the textfield to the same model object, like a property of a common parent, etc. -igor On Tue, Aug 24, 2010 at 8:37 AM, 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 - 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
you can accomplish it using a simple visitor. 1.5 has a more formalized approach for managing events between components. -igor On Tue, Aug 24, 2010 at 10:07 AM, James Carman ja...@carmanconsulting.com wrote: Yes, but how do you make sure all the components that need to be updated via ajax are updated? They can point to the same model, but if they're not added to the AjaxRequestTarget, then they won't be updated when their values change. You'd need some sort of event listener I would think (unless you want to pass around references to the components that need updating). On Tue, Aug 24, 2010 at 12:56 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote: usually this kind of linkage is created by pointing both the calendar and the textfield to the same model object, like a property of a common parent, etc. -igor On Tue, Aug 24, 2010 at 8:37 AM, 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 - 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: Best practice for component interaction
What do you mean? What would the visitor look for? On Tue, Aug 24, 2010 at 1:12 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote: you can accomplish it using a simple visitor. 1.5 has a more formalized approach for managing events between components. -igor On Tue, Aug 24, 2010 at 10:07 AM, James Carman ja...@carmanconsulting.com wrote: Yes, but how do you make sure all the components that need to be updated via ajax are updated? They can point to the same model, but if they're not added to the AjaxRequestTarget, then they won't be updated when their values change. You'd need some sort of event listener I would think (unless you want to pass around references to the components that need updating). On Tue, Aug 24, 2010 at 12:56 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote: usually this kind of linkage is created by pointing both the calendar and the textfield to the same model object, like a property of a common parent, etc. -igor On Tue, Aug 24, 2010 at 8:37 AM, 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 - 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 - 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
onclick(final AjaxRequestTarget target) {
getPage().visitChildren(CaresAboutMyAjaxEvent.class, new
IVisitorCaresAboutMyAjaxEvent () {
Object visit(CaresAboutMyAjaxEent object) {
object.onMyAjaxEvent(target);
}}}
-igor
On Tue, Aug 24, 2010 at 10:19 AM, James Carman
ja...@carmanconsulting.com wrote:
What do you mean? What would the visitor look for?
On Tue, Aug 24, 2010 at 1:12 PM, Igor Vaynberg igor.vaynb...@gmail.com
wrote:
you can accomplish it using a simple visitor. 1.5 has a more
formalized approach for managing events between components.
-igor
On Tue, Aug 24, 2010 at 10:07 AM, James Carman
ja...@carmanconsulting.com wrote:
Yes, but how do you make sure all the components that need to be
updated via ajax are updated? They can point to the same model, but
if they're not added to the AjaxRequestTarget, then they won't be
updated when their values change. You'd need some sort of event
listener I would think (unless you want to pass around references to
the components that need updating).
On Tue, Aug 24, 2010 at 12:56 PM, Igor Vaynberg igor.vaynb...@gmail.com
wrote:
usually this kind of linkage is created by pointing both the calendar
and the textfield to the same model object, like a property of a
common parent, etc.
-igor
On Tue, Aug 24, 2010 at 8:37 AM, 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
-
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
-
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
So, you're saying you'd introduce an interface that you'd have all of
the components implement if they're interested in a certain event.
Interesting. What about just using a metadata key?
On Tue, Aug 24, 2010 at 1:24 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote:
onclick(final AjaxRequestTarget target) {
getPage().visitChildren(CaresAboutMyAjaxEvent.class, new
IVisitorCaresAboutMyAjaxEvent () {
Object visit(CaresAboutMyAjaxEent object) {
object.onMyAjaxEvent(target);
}}}
-igor
On Tue, Aug 24, 2010 at 10:19 AM, James Carman
ja...@carmanconsulting.com wrote:
What do you mean? What would the visitor look for?
On Tue, Aug 24, 2010 at 1:12 PM, Igor Vaynberg igor.vaynb...@gmail.com
wrote:
you can accomplish it using a simple visitor. 1.5 has a more
formalized approach for managing events between components.
-igor
On Tue, Aug 24, 2010 at 10:07 AM, James Carman
ja...@carmanconsulting.com wrote:
Yes, but how do you make sure all the components that need to be
updated via ajax are updated? They can point to the same model, but
if they're not added to the AjaxRequestTarget, then they won't be
updated when their values change. You'd need some sort of event
listener I would think (unless you want to pass around references to
the components that need updating).
On Tue, Aug 24, 2010 at 12:56 PM, Igor Vaynberg igor.vaynb...@gmail.com
wrote:
usually this kind of linkage is created by pointing both the calendar
and the textfield to the same model object, like a property of a
common parent, etc.
-igor
On Tue, Aug 24, 2010 at 8:37 AM, 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
-
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
-
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: Best practice for component interaction
anything way to identify components that subscribe to a topic works.
-igor
On Tue, Aug 24, 2010 at 10:30 AM, James Carman
ja...@carmanconsulting.com wrote:
So, you're saying you'd introduce an interface that you'd have all of
the components implement if they're interested in a certain event.
Interesting. What about just using a metadata key?
On Tue, Aug 24, 2010 at 1:24 PM, Igor Vaynberg igor.vaynb...@gmail.com
wrote:
onclick(final AjaxRequestTarget target) {
getPage().visitChildren(CaresAboutMyAjaxEvent.class, new
IVisitorCaresAboutMyAjaxEvent () {
Object visit(CaresAboutMyAjaxEent object) {
object.onMyAjaxEvent(target);
}}}
-igor
On Tue, Aug 24, 2010 at 10:19 AM, James Carman
ja...@carmanconsulting.com wrote:
What do you mean? What would the visitor look for?
On Tue, Aug 24, 2010 at 1:12 PM, Igor Vaynberg igor.vaynb...@gmail.com
wrote:
you can accomplish it using a simple visitor. 1.5 has a more
formalized approach for managing events between components.
-igor
On Tue, Aug 24, 2010 at 10:07 AM, James Carman
ja...@carmanconsulting.com wrote:
Yes, but how do you make sure all the components that need to be
updated via ajax are updated? They can point to the same model, but
if they're not added to the AjaxRequestTarget, then they won't be
updated when their values change. You'd need some sort of event
listener I would think (unless you want to pass around references to
the components that need updating).
On Tue, Aug 24, 2010 at 12:56 PM, Igor Vaynberg igor.vaynb...@gmail.com
wrote:
usually this kind of linkage is created by pointing both the calendar
and the textfield to the same model object, like a property of a
common parent, etc.
-igor
On Tue, Aug 24, 2010 at 8:37 AM, 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
-
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
-
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
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
