Hi! > 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. So we still have a renderer replacement? Than the advantage of your solution is lost. We have our own renderer, and if someone else replaces the form renderer the functionality will be lost too.
And - I my life it WAS a major problem for some customers. We ended with an servletFilter which encrypts all links on an page. I dont want to happen this situation again. >> 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? > In the end it should be possible to do stuff like auto_scroll using this approach. Currently I need it to get something simmilar to seams conversationId into the request parameters. >> 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. > While I am with you, some deeper functions need compromises. The problem is, that it is not possible to decorate the renderer, is it? Some next JSF release should introduce this abillity and also define the methods a renderer has to provide. Eg. a clear specification what a form renderer (in fact - all h: standard renderer) has to do and the naming of the methods. I do not talk about encodeBegin etc, but something like encodeFormStart, encodeFormParameters, encodeFormParameter, encodeFormStart (all protected methods) That way the above solution could work with any other JSF implementation too and makes the renderer more reusable. Ciao, Mario
