You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@myfaces.apache.org by Rich Schramm <ri...@supplydynamics.com> on 2007/07/26 17:05:04 UTC

server side commandLink component problems

Hello,

 

I am trying to build a set of links from a configuration file.  I don't
know what is going to be in the file until run time.  Therefore, I am
using server side code to create a panelGrid and dynamically add links
to the grid.  The problem I am having is the commandLink component only
takes a methodBinding as a parameter for the setAction method.  Since
this list is going to be dynamic, I can't create methods in the backing
bean to handle each link.  Here is what I have tried:  

 

-          Create a method binding to a non-el string "home" as opposed
to "#{backingbean.home}" but that throws an exception at run time.

-          Create and use a "switchboard" method, but because an action=
uses a method that does not take an ActionEvent as a parameter, I have
no way of knowing which link fired the event.

-          Add an ActionListener to the link with the switchboard
method, but for some reason that I don't get, when I add an action event
listener to the command link, it throws an exception at runtime saying
it can't resolve the method binding, even though it is correct and I
have tested it on the JSP page with the <t:commandLink
actionListener="#{backingbean.linkAEL}"/> and it works fine from there.
I thought I could get the action event from the listener and save it in
the bean for the action handler to access, but can't get this to work.

-          Use just an ActionListener and do a forward on the server
side.  Same problem as above - runtime evaluation error.

 

I know at run time what nav rule outcome I want to send for each link.
It would be great if I could just send a string for the action instead
of an expression like you can use in JSP where action="foo" (foo being a
nav rule outcome).

 

Any help with this would be much appreciated - I have basically run out
of ideas.

 

Thanks,

 

Rich