On 4/27/06, Mario Ivankovits <[EMAIL PROTECTED]> wrote: > Hi! > > The way I've implemented this sort of thing - getting request > > parameters onto URLs pointing to JSF URLs - is by > > hooking ViewHandler.getActionURL(). Would this > > work for this scenario? > > > Good point, sure this might work too for the current scenario. > > But then, in case of forms, they are put into the url like get > parameters - which is mostly not wanted.
I don't see that as a major problem, but it's simple to fix if it is. Just parse the URL in the FormRenderer and extract query parameters in it into hidden values. I wrote some code a few years ago that did just that. > And - once rendered the values are fixed, putting them on the > link/button level allows the provider to return different values for > different actions (once we extended the provider to tell him which > component requires the values) IMO, that's a very unsatisfying approach. Different actions should not get different URL parameters - that information should be left in the component tree. Why do you need this? > You are right, with the component dependency problem, but I tend to make > my life easier - thus - tomahawk extensions work only with tomahawk > components. That's a mindset that we have to get away from! JSF functionality should work with all JSF components; otherwise, we're back to a lock-in scenario, which discards the whole advantage of having a standard like JSF. -- Adam > In the current case the user still can use the h:* components as their > renderers are replaced by tomahawk. > > Ciao, > Mario > >
