Wouldn't this solvable by including Martin's visitor example for JSF 2.0 as a phase listener instead of explicitying writing hooks everywhere?
>On 4/27/06, Mario Ivankovits <[EMAIL PROTECTED]> wrote: >> 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. > >No, it's not lost: first up, I think that could be done right in >FormRendererBase >without any portability. Even if you didn't do that, one tweak to >form is far, far >better han asking everyone writing components to call a custom API. > >> We have our own renderer, and if someone else replaces the form renderer >> the functionality will be lost too. > >No, they'd still get the functionality, because they'd still call >ViewHandler.getActionURL(). As opposed to your proposed >solution, actually, where a replaced form renderer *would* >lose the functionality. > >> 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. > >I've said how you can solve the problem. Do you disagree >that the form renderer can handle this for you? > >> >> 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. > >I don't understand why that would ever be *per*-component. > >> Currently I need it to get something simmilar to seams conversationId >> into the request parameters. > >Yes, but that's not per-component, right? > >> >> 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? > >No, not usefully. > >> 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) > >I'd disagree; I don't think specific Renderer APIs should ever be further >specified - in fact, we should be moving away from any specific requirement >that there even *be* a Form component in any specific tree. > >If the spec were going to address this, I think this should be handled via >APIs >akin to ViewHandler and ExternalContext, registered at a RenderKit-level. > >BTW, I do agree that it's useful to have a RequestParameterProvider. >I just strongly disagree with the idea that FormRenderer should be calling >it; >it should be called by a ViewHandler decorator. > >Regards, >Adam
