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
