Re: sharing a context menu across components

2007-08-14 Thread Kirk Israel
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [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 

Re: sharing a context menu across components

2007-08-13 Thread Igor Vaynberg
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