You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Kirk Israel <ki...@kisrael.com> on 2007/08/13 16:50:34 UTC
sharing a context menu across components
I have a Context Menu Object and Behavior... right now I construct one
Context Menu for the whole Data Table (extends
AjaxFallbackDefaultDataTable) component that links to it... then on
newRowItem() I add a unique ContextMenuBehavior (extends
AbstractBehavior) to that item before returning.
My ContextMenuComponent currently constructs AjaxFallbackLink
derivatives to connect to the functions that will actually do the
work.
My question is, what's the best way of getting information on which
Table item was actually clicked to the context menu? Obviously I'd
rather not give each table item its own context menu... is there
anything in AbstractBehavior that would get triggered when the user
right clicks, and thus let me set a global-ish variable in the parent
component that the contextmenu could then read? Or have we gone about
that wrong, and it needs to be some other kind of behavior to activate
server-side code when the behavior gets activated?
I might be still having trouble setting my mind to the appropriate
Wicket way of thinking about this kind of issue.
Thanks...
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: sharing a context menu across components
Posted by Kirk Israel <ki...@kisrael.com>.
So I haven't found what setup would provide a reference to the
Behavior to the AjaxFallbackLink. Is the problem in how I'm relying on
overloading the page's document.oncontextmenu to handle the right
click event, and I should be using something else?
As a workaround, is there any available Javascript function that other
javascript can call to set the property of a page? Then the context
menu could read the id from the <tr> the rowItem built, store that in
the current page for the session, and then when the AjaxFallbacklink
is triggered it could read it from there... is anything like that
available, some public bit of API, like for an AjaxFallback link or
something more direct, that javascript could easily call?
On 8/14/07, Kirk Israel <ki...@kisrael.com> wrote:
> I guess, then, the problem might be with the way I'm using the
> behavior(s) to activate some javascript to display the context menu at
> the appropriate place. (Code I took over, though I'm free to refactor
> it.) Sure each behavior has a unique path, but the AjaxLink in the
> context menu, the bit that actually does the work has no object
> reference (or otherwise) to the Behavior, so it doesn't help me
> determine what row was clicked.
>
> So either there is another way to set up the objects to produce the
> context menu, so that the Behavior is "handed" to whatever responds to
> the click, or I need to continue my current path of still having
> multiple behaviors, but modifying the javascript somehow to store the
> id in a hidden form or hack some URL that I haven't dug up yet.
>
>
>
> On 8/13/07, Igor Vaynberg <ig...@gmail.com> wrote:
> > what i am suggesting is this:
> >
> > if you only want to have a single instance of behavior per table, yet have
> > onclick react per row you need to have some javascript on the clientside
> > that can tell what row is clicked by appending something meaningful to the
> > behavior's callback url.
> >
> > you do not need this when you use an instance of behavior per row - because
> > wicket already builds the unique name that can identify that row/behavior
> > for you - which is the component path of the component that contains the
> > behavior.
> >
> > -igor
> >
> >
> > On 8/13/07, Kirk Israel <ki...@kisrael.com> wrote:
> > >
> > > I guess I'm not understanding what you're suggesting.
> > >
> > > I've added a ContextMenuBehavior to the dataTableComponent row.
> > > Inside the ContextMenuComponent that is also on the page, there is an
> > > AjaxLink anonymous inner class. that overrides
> > > onClick(AjaxRequestTarget pRequestTarget)
> > >
> > > But the result of getPath() always has the same "problem", even when I
> > > do ContextMenuComponent.this.getPath(). The Behavior isn't in the
> > > path, because it's not part of the nesting hierarchy. It stands
> > > outside and connects, and as you can see below the path says
> > > dataTableComponent:campaignContextMenuComponent - the fact that
> > > behaviors have been added to the dataTableComponent's rows doesn't
> > > matter to the path, at least in the straight forward way I've made the
> > > contextMenuComponent.
> > >
> > > (Just to make sure I wasn't missing something obvious, I tried adding
> > > the contextMenuComponent to the Behavior rather than to the
> > > dataTableComponent, but of course there is no ".add(Component)" for
> > > behaviors, so the concept didn't make sense.. you can add a behavior
> > > to a component but not vice versa)
> > >
> > > What am I not getting here?
> > > Is there some other kind of special menu item class I need to use that
> > > would capture the path of the behavior that invoked it?( Because right
> > > now it's just a component that happens to be showing up and relocated
> > > because of the behavior i added to the rowitem.)
> > > Is there some sort of way of jamming the behavior into the path,
> > > besides the fact that the behavior is added to the appropriate
> > > rowitem?
> > >
> > >
> > > On 8/13/07, Igor Vaynberg <ig...@gmail.com> wrote:
> > > > see component.getpath()
> > > >
> > > > -igor
> > > >
> > > > On 8/13/07, Kirk Israel <ki...@kisrael.com> wrote:
> > > > >
> > > > > Where can I retrieve that path? Each row is generating a unique
> > > > > behavior object instance, but in the onClick for one of the menu
> > > > > items, code like
> > > > > this.getRequest().getPath();
> > > > > (which, through some documentation surfing and trial and error seemed
> > > > > the only thing close to what you were talking about) comes back with
> > > > >
> > > > >
> > > 1:campaignManagerViewContainer:dataTableComponent:campaignContextMenuComponent:contextmenuNewLink
> > > > >
> > > > > with no mention of the behavior that is connecting dataTableComponent
> > > > > and campaignContextMenuComponent
> > > > >
> > > > > Is there another object that would be carrying more meaningful request
> > > > > path info, or is my only hope to start hacking in the javascript? I
> > > > > really hate breaking the abstraction layer Wicket provides by putting
> > > > > so much in javascript, and the path to even do so isn't clear to me.
> > > > >
> > > > >
> > > > > On 8/13/07, Igor Vaynberg <ig...@gmail.com> wrote:
> > > > > > the first one is internal to wicket - because the behavior is unique
> > > it
> > > > > gets
> > > > > > an internal unique path in wicket, so you dont need to worry about
> > > it.
> > > > > so
> > > > > > basically your onclick handler for the menuitem has a 1-1 link to
> > > the
> > > > > > onclick handler of the behavior.
> > > > > >
> > > > > > if you want one behavior then you have many menuitems onclicks
> > > linking
> > > > > to a
> > > > > > single behavior onclick. so you need to map somehow - and that is
> > > > > through
> > > > > > javascript on clientside.
> > > > > >
> > > > > > -igor
> > > > > >
> > > > > >
> > > > > > On 8/13/07, Kirk Israel <ki...@kisrael.com> wrote:
> > > > > > >
> > > > > > > I kind of see what you're getting at, but could you give an
> > > example of
> > > > > > > the syntax for the first one? I already have a unique behavior
> > > > > > > instance for each row... do I need to add another one? Or is
> > > there
> > > > > > > some way in the onClick code to read what the path of the behavior
> > > is?
> > > > > > > (Actually I might not be thinking of the right use of "path")
> > > > > > > I guess I'm trying to avoid hacking javascript strings if I can,
> > > since
> > > > > > > the link syntax is pretty arcane...
> > > > > > >
> > > > > > > On 8/13/07, Igor Vaynberg <ig...@gmail.com> wrote:
> > > > > > > > the event is triggered on clientside, so you need to pass back
> > > what
> > > > > item
> > > > > > > was
> > > > > > > > clicked there.
> > > > > > > >
> > > > > > > > you can either do it by adding a unique behavior - which then
> > > has a
> > > > > > > unique
> > > > > > > > path - which is that "id" you are passing back. or you need to
> > > > > append
> > > > > > > some
> > > > > > > > unique id on client side using javascript so it can tell which
> > > row
> > > > > was
> > > > > > > > clicked.
> > > > > > > >
> > > > > > > > -igor
> > > > > > > >
> > > > > > > >
> > > > > > > > On 8/13/07, Kirk Israel <ki...@kisrael.com> wrote:
> > > > > > > > >
> > > > > > > > > I have a Context Menu Object and Behavior... right now I
> > > construct
> > > > > one
> > > > > > > > > Context Menu for the whole Data Table (extends
> > > > > > > > > AjaxFallbackDefaultDataTable) component that links to it...
> > > then
> > > > > on
> > > > > > > > > newRowItem() I add a unique ContextMenuBehavior (extends
> > > > > > > > > AbstractBehavior) to that item before returning.
> > > > > > > > >
> > > > > > > > > My ContextMenuComponent currently constructs AjaxFallbackLink
> > > > > > > > > derivatives to connect to the functions that will actually do
> > > the
> > > > > > > > > work.
> > > > > > > > >
> > > > > > > > > My question is, what's the best way of getting information on
> > > > > which
> > > > > > > > > Table item was actually clicked to the context menu? Obviously
> > > I'd
> > > > > > > > > rather not give each table item its own context menu... is
> > > there
> > > > > > > > > anything in AbstractBehavior that would get triggered when the
> > > > > user
> > > > > > > > > right clicks, and thus let me set a global-ish variable in the
> > > > > parent
> > > > > > > > > component that the contextmenu could then read? Or have we
> > > gone
> > > > > about
> > > > > > > > > that wrong, and it needs to be some other kind of behavior to
> > > > > activate
> > > > > > > > > server-side code when the behavior gets activated?
> > > > > > > > >
> > > > > > > > > I might be still having trouble setting my mind to the
> > > appropriate
> > > > > > > > > Wicket way of thinking about this kind of issue.
> > > > > > > > >
> > > > > > > > > Thanks...
> > > > > > > > >
> > > > > > > > >
> > > > > ---------------------------------------------------------------------
> > > > > > > > > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > > > > > > > > For additional commands, e-mail: users-help@wicket.apache.org
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > ---------------------------------------------------------------------
> > > > > > > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > > > > > > For additional commands, e-mail: users-help@wicket.apache.org
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > > > > For additional commands, e-mail: users-help@wicket.apache.org
> > > > >
> > > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > > For additional commands, e-mail: users-help@wicket.apache.org
> > >
> > >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: sharing a context menu across components
Posted by Igor Vaynberg <ig...@gmail.com>.
what i am suggesting is this:
if you only want to have a single instance of behavior per table, yet have
onclick react per row you need to have some javascript on the clientside
that can tell what row is clicked by appending something meaningful to the
behavior's callback url.
you do not need this when you use an instance of behavior per row - because
wicket already builds the unique name that can identify that row/behavior
for you - which is the component path of the component that contains the
behavior.
-igor
On 8/13/07, Kirk Israel <ki...@kisrael.com> wrote:
>
> I guess I'm not understanding what you're suggesting.
>
> I've added a ContextMenuBehavior to the dataTableComponent row.
> Inside the ContextMenuComponent that is also on the page, there is an
> AjaxLink anonymous inner class. that overrides
> onClick(AjaxRequestTarget pRequestTarget)
>
> But the result of getPath() always has the same "problem", even when I
> do ContextMenuComponent.this.getPath(). The Behavior isn't in the
> path, because it's not part of the nesting hierarchy. It stands
> outside and connects, and as you can see below the path says
> dataTableComponent:campaignContextMenuComponent - the fact that
> behaviors have been added to the dataTableComponent's rows doesn't
> matter to the path, at least in the straight forward way I've made the
> contextMenuComponent.
>
> (Just to make sure I wasn't missing something obvious, I tried adding
> the contextMenuComponent to the Behavior rather than to the
> dataTableComponent, but of course there is no ".add(Component)" for
> behaviors, so the concept didn't make sense.. you can add a behavior
> to a component but not vice versa)
>
> What am I not getting here?
> Is there some other kind of special menu item class I need to use that
> would capture the path of the behavior that invoked it?( Because right
> now it's just a component that happens to be showing up and relocated
> because of the behavior i added to the rowitem.)
> Is there some sort of way of jamming the behavior into the path,
> besides the fact that the behavior is added to the appropriate
> rowitem?
>
>
> On 8/13/07, Igor Vaynberg <ig...@gmail.com> wrote:
> > see component.getpath()
> >
> > -igor
> >
> > On 8/13/07, Kirk Israel <ki...@kisrael.com> wrote:
> > >
> > > Where can I retrieve that path? Each row is generating a unique
> > > behavior object instance, but in the onClick for one of the menu
> > > items, code like
> > > this.getRequest().getPath();
> > > (which, through some documentation surfing and trial and error seemed
> > > the only thing close to what you were talking about) comes back with
> > >
> > >
> 1:campaignManagerViewContainer:dataTableComponent:campaignContextMenuComponent:contextmenuNewLink
> > >
> > > with no mention of the behavior that is connecting dataTableComponent
> > > and campaignContextMenuComponent
> > >
> > > Is there another object that would be carrying more meaningful request
> > > path info, or is my only hope to start hacking in the javascript? I
> > > really hate breaking the abstraction layer Wicket provides by putting
> > > so much in javascript, and the path to even do so isn't clear to me.
> > >
> > >
> > > On 8/13/07, Igor Vaynberg <ig...@gmail.com> wrote:
> > > > the first one is internal to wicket - because the behavior is unique
> it
> > > gets
> > > > an internal unique path in wicket, so you dont need to worry about
> it.
> > > so
> > > > basically your onclick handler for the menuitem has a 1-1 link to
> the
> > > > onclick handler of the behavior.
> > > >
> > > > if you want one behavior then you have many menuitems onclicks
> linking
> > > to a
> > > > single behavior onclick. so you need to map somehow - and that is
> > > through
> > > > javascript on clientside.
> > > >
> > > > -igor
> > > >
> > > >
> > > > On 8/13/07, Kirk Israel <ki...@kisrael.com> wrote:
> > > > >
> > > > > I kind of see what you're getting at, but could you give an
> example of
> > > > > the syntax for the first one? I already have a unique behavior
> > > > > instance for each row... do I need to add another one? Or is
> there
> > > > > some way in the onClick code to read what the path of the behavior
> is?
> > > > > (Actually I might not be thinking of the right use of "path")
> > > > > I guess I'm trying to avoid hacking javascript strings if I can,
> since
> > > > > the link syntax is pretty arcane...
> > > > >
> > > > > On 8/13/07, Igor Vaynberg <ig...@gmail.com> wrote:
> > > > > > the event is triggered on clientside, so you need to pass back
> what
> > > item
> > > > > was
> > > > > > clicked there.
> > > > > >
> > > > > > you can either do it by adding a unique behavior - which then
> has a
> > > > > unique
> > > > > > path - which is that "id" you are passing back. or you need to
> > > append
> > > > > some
> > > > > > unique id on client side using javascript so it can tell which
> row
> > > was
> > > > > > clicked.
> > > > > >
> > > > > > -igor
> > > > > >
> > > > > >
> > > > > > On 8/13/07, Kirk Israel <ki...@kisrael.com> wrote:
> > > > > > >
> > > > > > > I have a Context Menu Object and Behavior... right now I
> construct
> > > one
> > > > > > > Context Menu for the whole Data Table (extends
> > > > > > > AjaxFallbackDefaultDataTable) component that links to it...
> then
> > > on
> > > > > > > newRowItem() I add a unique ContextMenuBehavior (extends
> > > > > > > AbstractBehavior) to that item before returning.
> > > > > > >
> > > > > > > My ContextMenuComponent currently constructs AjaxFallbackLink
> > > > > > > derivatives to connect to the functions that will actually do
> the
> > > > > > > work.
> > > > > > >
> > > > > > > My question is, what's the best way of getting information on
> > > which
> > > > > > > Table item was actually clicked to the context menu? Obviously
> I'd
> > > > > > > rather not give each table item its own context menu... is
> there
> > > > > > > anything in AbstractBehavior that would get triggered when the
> > > user
> > > > > > > right clicks, and thus let me set a global-ish variable in the
> > > parent
> > > > > > > component that the contextmenu could then read? Or have we
> gone
> > > about
> > > > > > > that wrong, and it needs to be some other kind of behavior to
> > > activate
> > > > > > > server-side code when the behavior gets activated?
> > > > > > >
> > > > > > > I might be still having trouble setting my mind to the
> appropriate
> > > > > > > Wicket way of thinking about this kind of issue.
> > > > > > >
> > > > > > > Thanks...
> > > > > > >
> > > > > > >
> > > ---------------------------------------------------------------------
> > > > > > > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > > > > > > For additional commands, e-mail: users-help@wicket.apache.org
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > > > > For additional commands, e-mail: users-help@wicket.apache.org
> > > > >
> > > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > > For additional commands, e-mail: users-help@wicket.apache.org
> > >
> > >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: sharing a context menu across components
Posted by Kirk Israel <ki...@kisrael.com>.
I guess I'm not understanding what you're suggesting.
I've added a ContextMenuBehavior to the dataTableComponent row.
Inside the ContextMenuComponent that is also on the page, there is an
AjaxLink anonymous inner class. that overrides
onClick(AjaxRequestTarget pRequestTarget)
But the result of getPath() always has the same "problem", even when I
do ContextMenuComponent.this.getPath(). The Behavior isn't in the
path, because it's not part of the nesting hierarchy. It stands
outside and connects, and as you can see below the path says
dataTableComponent:campaignContextMenuComponent - the fact that
behaviors have been added to the dataTableComponent's rows doesn't
matter to the path, at least in the straight forward way I've made the
contextMenuComponent.
(Just to make sure I wasn't missing something obvious, I tried adding
the contextMenuComponent to the Behavior rather than to the
dataTableComponent, but of course there is no ".add(Component)" for
behaviors, so the concept didn't make sense.. you can add a behavior
to a component but not vice versa)
What am I not getting here?
Is there some other kind of special menu item class I need to use that
would capture the path of the behavior that invoked it?( Because right
now it's just a component that happens to be showing up and relocated
because of the behavior i added to the rowitem.)
Is there some sort of way of jamming the behavior into the path,
besides the fact that the behavior is added to the appropriate
rowitem?
On 8/13/07, Igor Vaynberg <ig...@gmail.com> wrote:
> see component.getpath()
>
> -igor
>
> On 8/13/07, Kirk Israel <ki...@kisrael.com> wrote:
> >
> > Where can I retrieve that path? Each row is generating a unique
> > behavior object instance, but in the onClick for one of the menu
> > items, code like
> > this.getRequest().getPath();
> > (which, through some documentation surfing and trial and error seemed
> > the only thing close to what you were talking about) comes back with
> >
> > 1:campaignManagerViewContainer:dataTableComponent:campaignContextMenuComponent:contextmenuNewLink
> >
> > with no mention of the behavior that is connecting dataTableComponent
> > and campaignContextMenuComponent
> >
> > Is there another object that would be carrying more meaningful request
> > path info, or is my only hope to start hacking in the javascript? I
> > really hate breaking the abstraction layer Wicket provides by putting
> > so much in javascript, and the path to even do so isn't clear to me.
> >
> >
> > On 8/13/07, Igor Vaynberg <ig...@gmail.com> wrote:
> > > the first one is internal to wicket - because the behavior is unique it
> > gets
> > > an internal unique path in wicket, so you dont need to worry about it.
> > so
> > > basically your onclick handler for the menuitem has a 1-1 link to the
> > > onclick handler of the behavior.
> > >
> > > if you want one behavior then you have many menuitems onclicks linking
> > to a
> > > single behavior onclick. so you need to map somehow - and that is
> > through
> > > javascript on clientside.
> > >
> > > -igor
> > >
> > >
> > > On 8/13/07, Kirk Israel <ki...@kisrael.com> wrote:
> > > >
> > > > I kind of see what you're getting at, but could you give an example of
> > > > the syntax for the first one? I already have a unique behavior
> > > > instance for each row... do I need to add another one? Or is there
> > > > some way in the onClick code to read what the path of the behavior is?
> > > > (Actually I might not be thinking of the right use of "path")
> > > > I guess I'm trying to avoid hacking javascript strings if I can, since
> > > > the link syntax is pretty arcane...
> > > >
> > > > On 8/13/07, Igor Vaynberg <ig...@gmail.com> wrote:
> > > > > the event is triggered on clientside, so you need to pass back what
> > item
> > > > was
> > > > > clicked there.
> > > > >
> > > > > you can either do it by adding a unique behavior - which then has a
> > > > unique
> > > > > path - which is that "id" you are passing back. or you need to
> > append
> > > > some
> > > > > unique id on client side using javascript so it can tell which row
> > was
> > > > > clicked.
> > > > >
> > > > > -igor
> > > > >
> > > > >
> > > > > On 8/13/07, Kirk Israel <ki...@kisrael.com> wrote:
> > > > > >
> > > > > > I have a Context Menu Object and Behavior... right now I construct
> > one
> > > > > > Context Menu for the whole Data Table (extends
> > > > > > AjaxFallbackDefaultDataTable) component that links to it... then
> > on
> > > > > > newRowItem() I add a unique ContextMenuBehavior (extends
> > > > > > AbstractBehavior) to that item before returning.
> > > > > >
> > > > > > My ContextMenuComponent currently constructs AjaxFallbackLink
> > > > > > derivatives to connect to the functions that will actually do the
> > > > > > work.
> > > > > >
> > > > > > My question is, what's the best way of getting information on
> > which
> > > > > > Table item was actually clicked to the context menu? Obviously I'd
> > > > > > rather not give each table item its own context menu... is there
> > > > > > anything in AbstractBehavior that would get triggered when the
> > user
> > > > > > right clicks, and thus let me set a global-ish variable in the
> > parent
> > > > > > component that the contextmenu could then read? Or have we gone
> > about
> > > > > > that wrong, and it needs to be some other kind of behavior to
> > activate
> > > > > > server-side code when the behavior gets activated?
> > > > > >
> > > > > > I might be still having trouble setting my mind to the appropriate
> > > > > > Wicket way of thinking about this kind of issue.
> > > > > >
> > > > > > Thanks...
> > > > > >
> > > > > >
> > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > > > > > For additional commands, e-mail: users-help@wicket.apache.org
> > > > > >
> > > > > >
> > > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > > > For additional commands, e-mail: users-help@wicket.apache.org
> > > >
> > > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: sharing a context menu across components
Posted by Igor Vaynberg <ig...@gmail.com>.
see component.getpath()
-igor
On 8/13/07, Kirk Israel <ki...@kisrael.com> wrote:
>
> Where can I retrieve that path? Each row is generating a unique
> behavior object instance, but in the onClick for one of the menu
> items, code like
> this.getRequest().getPath();
> (which, through some documentation surfing and trial and error seemed
> the only thing close to what you were talking about) comes back with
>
> 1:campaignManagerViewContainer:dataTableComponent:campaignContextMenuComponent:contextmenuNewLink
>
> with no mention of the behavior that is connecting dataTableComponent
> and campaignContextMenuComponent
>
> Is there another object that would be carrying more meaningful request
> path info, or is my only hope to start hacking in the javascript? I
> really hate breaking the abstraction layer Wicket provides by putting
> so much in javascript, and the path to even do so isn't clear to me.
>
>
> On 8/13/07, Igor Vaynberg <ig...@gmail.com> wrote:
> > the first one is internal to wicket - because the behavior is unique it
> gets
> > an internal unique path in wicket, so you dont need to worry about it.
> so
> > basically your onclick handler for the menuitem has a 1-1 link to the
> > onclick handler of the behavior.
> >
> > if you want one behavior then you have many menuitems onclicks linking
> to a
> > single behavior onclick. so you need to map somehow - and that is
> through
> > javascript on clientside.
> >
> > -igor
> >
> >
> > On 8/13/07, Kirk Israel <ki...@kisrael.com> wrote:
> > >
> > > I kind of see what you're getting at, but could you give an example of
> > > the syntax for the first one? I already have a unique behavior
> > > instance for each row... do I need to add another one? Or is there
> > > some way in the onClick code to read what the path of the behavior is?
> > > (Actually I might not be thinking of the right use of "path")
> > > I guess I'm trying to avoid hacking javascript strings if I can, since
> > > the link syntax is pretty arcane...
> > >
> > > On 8/13/07, Igor Vaynberg <ig...@gmail.com> wrote:
> > > > the event is triggered on clientside, so you need to pass back what
> item
> > > was
> > > > clicked there.
> > > >
> > > > you can either do it by adding a unique behavior - which then has a
> > > unique
> > > > path - which is that "id" you are passing back. or you need to
> append
> > > some
> > > > unique id on client side using javascript so it can tell which row
> was
> > > > clicked.
> > > >
> > > > -igor
> > > >
> > > >
> > > > On 8/13/07, Kirk Israel <ki...@kisrael.com> wrote:
> > > > >
> > > > > I have a Context Menu Object and Behavior... right now I construct
> one
> > > > > Context Menu for the whole Data Table (extends
> > > > > AjaxFallbackDefaultDataTable) component that links to it... then
> on
> > > > > newRowItem() I add a unique ContextMenuBehavior (extends
> > > > > AbstractBehavior) to that item before returning.
> > > > >
> > > > > My ContextMenuComponent currently constructs AjaxFallbackLink
> > > > > derivatives to connect to the functions that will actually do the
> > > > > work.
> > > > >
> > > > > My question is, what's the best way of getting information on
> which
> > > > > Table item was actually clicked to the context menu? Obviously I'd
> > > > > rather not give each table item its own context menu... is there
> > > > > anything in AbstractBehavior that would get triggered when the
> user
> > > > > right clicks, and thus let me set a global-ish variable in the
> parent
> > > > > component that the contextmenu could then read? Or have we gone
> about
> > > > > that wrong, and it needs to be some other kind of behavior to
> activate
> > > > > server-side code when the behavior gets activated?
> > > > >
> > > > > I might be still having trouble setting my mind to the appropriate
> > > > > Wicket way of thinking about this kind of issue.
> > > > >
> > > > > Thanks...
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > > > > For additional commands, e-mail: users-help@wicket.apache.org
> > > > >
> > > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > > For additional commands, e-mail: users-help@wicket.apache.org
> > >
> > >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: sharing a context menu across components
Posted by Kirk Israel <ki...@kisrael.com>.
Where can I retrieve that path? Each row is generating a unique
behavior object instance, but in the onClick for one of the menu
items, code like
this.getRequest().getPath();
(which, through some documentation surfing and trial and error seemed
the only thing close to what you were talking about) comes back with
1:campaignManagerViewContainer:dataTableComponent:campaignContextMenuComponent:contextmenuNewLink
with no mention of the behavior that is connecting dataTableComponent
and campaignContextMenuComponent
Is there another object that would be carrying more meaningful request
path info, or is my only hope to start hacking in the javascript? I
really hate breaking the abstraction layer Wicket provides by putting
so much in javascript, and the path to even do so isn't clear to me.
On 8/13/07, Igor Vaynberg <ig...@gmail.com> wrote:
> the first one is internal to wicket - because the behavior is unique it gets
> an internal unique path in wicket, so you dont need to worry about it. so
> basically your onclick handler for the menuitem has a 1-1 link to the
> onclick handler of the behavior.
>
> if you want one behavior then you have many menuitems onclicks linking to a
> single behavior onclick. so you need to map somehow - and that is through
> javascript on clientside.
>
> -igor
>
>
> On 8/13/07, Kirk Israel <ki...@kisrael.com> wrote:
> >
> > I kind of see what you're getting at, but could you give an example of
> > the syntax for the first one? I already have a unique behavior
> > instance for each row... do I need to add another one? Or is there
> > some way in the onClick code to read what the path of the behavior is?
> > (Actually I might not be thinking of the right use of "path")
> > I guess I'm trying to avoid hacking javascript strings if I can, since
> > the link syntax is pretty arcane...
> >
> > On 8/13/07, Igor Vaynberg <ig...@gmail.com> wrote:
> > > the event is triggered on clientside, so you need to pass back what item
> > was
> > > clicked there.
> > >
> > > you can either do it by adding a unique behavior - which then has a
> > unique
> > > path - which is that "id" you are passing back. or you need to append
> > some
> > > unique id on client side using javascript so it can tell which row was
> > > clicked.
> > >
> > > -igor
> > >
> > >
> > > On 8/13/07, Kirk Israel <ki...@kisrael.com> wrote:
> > > >
> > > > I have a Context Menu Object and Behavior... right now I construct one
> > > > Context Menu for the whole Data Table (extends
> > > > AjaxFallbackDefaultDataTable) component that links to it... then on
> > > > newRowItem() I add a unique ContextMenuBehavior (extends
> > > > AbstractBehavior) to that item before returning.
> > > >
> > > > My ContextMenuComponent currently constructs AjaxFallbackLink
> > > > derivatives to connect to the functions that will actually do the
> > > > work.
> > > >
> > > > My question is, what's the best way of getting information on which
> > > > Table item was actually clicked to the context menu? Obviously I'd
> > > > rather not give each table item its own context menu... is there
> > > > anything in AbstractBehavior that would get triggered when the user
> > > > right clicks, and thus let me set a global-ish variable in the parent
> > > > component that the contextmenu could then read? Or have we gone about
> > > > that wrong, and it needs to be some other kind of behavior to activate
> > > > server-side code when the behavior gets activated?
> > > >
> > > > I might be still having trouble setting my mind to the appropriate
> > > > Wicket way of thinking about this kind of issue.
> > > >
> > > > Thanks...
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > > > For additional commands, e-mail: users-help@wicket.apache.org
> > > >
> > > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: sharing a context menu across components
Posted by Igor Vaynberg <ig...@gmail.com>.
the first one is internal to wicket - because the behavior is unique it gets
an internal unique path in wicket, so you dont need to worry about it. so
basically your onclick handler for the menuitem has a 1-1 link to the
onclick handler of the behavior.
if you want one behavior then you have many menuitems onclicks linking to a
single behavior onclick. so you need to map somehow - and that is through
javascript on clientside.
-igor
On 8/13/07, Kirk Israel <ki...@kisrael.com> wrote:
>
> I kind of see what you're getting at, but could you give an example of
> the syntax for the first one? I already have a unique behavior
> instance for each row... do I need to add another one? Or is there
> some way in the onClick code to read what the path of the behavior is?
> (Actually I might not be thinking of the right use of "path")
> I guess I'm trying to avoid hacking javascript strings if I can, since
> the link syntax is pretty arcane...
>
> On 8/13/07, Igor Vaynberg <ig...@gmail.com> wrote:
> > the event is triggered on clientside, so you need to pass back what item
> was
> > clicked there.
> >
> > you can either do it by adding a unique behavior - which then has a
> unique
> > path - which is that "id" you are passing back. or you need to append
> some
> > unique id on client side using javascript so it can tell which row was
> > clicked.
> >
> > -igor
> >
> >
> > On 8/13/07, Kirk Israel <ki...@kisrael.com> wrote:
> > >
> > > I have a Context Menu Object and Behavior... right now I construct one
> > > Context Menu for the whole Data Table (extends
> > > AjaxFallbackDefaultDataTable) component that links to it... then on
> > > newRowItem() I add a unique ContextMenuBehavior (extends
> > > AbstractBehavior) to that item before returning.
> > >
> > > My ContextMenuComponent currently constructs AjaxFallbackLink
> > > derivatives to connect to the functions that will actually do the
> > > work.
> > >
> > > My question is, what's the best way of getting information on which
> > > Table item was actually clicked to the context menu? Obviously I'd
> > > rather not give each table item its own context menu... is there
> > > anything in AbstractBehavior that would get triggered when the user
> > > right clicks, and thus let me set a global-ish variable in the parent
> > > component that the contextmenu could then read? Or have we gone about
> > > that wrong, and it needs to be some other kind of behavior to activate
> > > server-side code when the behavior gets activated?
> > >
> > > I might be still having trouble setting my mind to the appropriate
> > > Wicket way of thinking about this kind of issue.
> > >
> > > Thanks...
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > > For additional commands, e-mail: users-help@wicket.apache.org
> > >
> > >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: sharing a context menu across components
Posted by Kirk Israel <ki...@kisrael.com>.
I kind of see what you're getting at, but could you give an example of
the syntax for the first one? I already have a unique behavior
instance for each row... do I need to add another one? Or is there
some way in the onClick code to read what the path of the behavior is?
(Actually I might not be thinking of the right use of "path")
I guess I'm trying to avoid hacking javascript strings if I can, since
the link syntax is pretty arcane...
On 8/13/07, Igor Vaynberg <ig...@gmail.com> wrote:
> the event is triggered on clientside, so you need to pass back what item was
> clicked there.
>
> you can either do it by adding a unique behavior - which then has a unique
> path - which is that "id" you are passing back. or you need to append some
> unique id on client side using javascript so it can tell which row was
> clicked.
>
> -igor
>
>
> On 8/13/07, Kirk Israel <ki...@kisrael.com> wrote:
> >
> > I have a Context Menu Object and Behavior... right now I construct one
> > Context Menu for the whole Data Table (extends
> > AjaxFallbackDefaultDataTable) component that links to it... then on
> > newRowItem() I add a unique ContextMenuBehavior (extends
> > AbstractBehavior) to that item before returning.
> >
> > My ContextMenuComponent currently constructs AjaxFallbackLink
> > derivatives to connect to the functions that will actually do the
> > work.
> >
> > My question is, what's the best way of getting information on which
> > Table item was actually clicked to the context menu? Obviously I'd
> > rather not give each table item its own context menu... is there
> > anything in AbstractBehavior that would get triggered when the user
> > right clicks, and thus let me set a global-ish variable in the parent
> > component that the contextmenu could then read? Or have we gone about
> > that wrong, and it needs to be some other kind of behavior to activate
> > server-side code when the behavior gets activated?
> >
> > I might be still having trouble setting my mind to the appropriate
> > Wicket way of thinking about this kind of issue.
> >
> > Thanks...
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: sharing a context menu across components
Posted by Igor Vaynberg <ig...@gmail.com>.
the event is triggered on clientside, so you need to pass back what item was
clicked there.
you can either do it by adding a unique behavior - which then has a unique
path - which is that "id" you are passing back. or you need to append some
unique id on client side using javascript so it can tell which row was
clicked.
-igor
On 8/13/07, Kirk Israel <ki...@kisrael.com> wrote:
>
> I have a Context Menu Object and Behavior... right now I construct one
> Context Menu for the whole Data Table (extends
> AjaxFallbackDefaultDataTable) component that links to it... then on
> newRowItem() I add a unique ContextMenuBehavior (extends
> AbstractBehavior) to that item before returning.
>
> My ContextMenuComponent currently constructs AjaxFallbackLink
> derivatives to connect to the functions that will actually do the
> work.
>
> My question is, what's the best way of getting information on which
> Table item was actually clicked to the context menu? Obviously I'd
> rather not give each table item its own context menu... is there
> anything in AbstractBehavior that would get triggered when the user
> right clicks, and thus let me set a global-ish variable in the parent
> component that the contextmenu could then read? Or have we gone about
> that wrong, and it needs to be some other kind of behavior to activate
> server-side code when the behavior gets activated?
>
> I might be still having trouble setting my mind to the appropriate
> Wicket way of thinking about this kind of issue.
>
> Thanks...
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>