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 <[EMAIL PROTECTED]> 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 <[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] > >
