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 <[EMAIL PROTECTED]> wrote: > see component.getpath() > > -igor > > On 8/13/07, Kirk Israel <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > > > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
