Adam Winer schrieb: >> 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. > If I do this in FormRendererBase it will no longer work with the RI. This is why we decided to move Tomahawk extensions to their own renderers. I know, we didnt reach this point as the specification about the encode methods a renderer has to provide (and the decorator pattern) is missing. If its there such enhancements works with any implementation.
Looks like a matter of taste. At least as how our "shared" currently is I dont want to put this stuff in the FormRendererBase. I have to put the provider stuff to shared too, and the we again have the namespace problem. This is why we moved the DummyForm stuff from shared to tomahawk and spent it its own renderers. Also putting this in FormRendererBase will NOT solve problems with usage in "non tomahawk only" environments. If one replaces the renderer he is not required to extend from our base class. At all I dont want to deal with the shared stuff as it is currently. >> 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. > It turns out that ActionURL indeed is the correct place. Some tomahawk components render a form outside of h:form. I'll loose my request parameter if I do NOT add them to getActionURL. Thanks for pointing this out :-) >> 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? > Yes, but I dont want to pack the values into an url string and unpack it again into hidden fields later. For now I'll go with getActionURL() - even if I am not fully happy. >> The problem is, that it is not possible to decorate the renderer, is it? >> > > No, not usefully. > > 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. > Its not that the specification should say that there MUST be a form, ist more that if there is a form the renderer has a specific behaviour. > 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. > Hmmm ... I dont get how this API would look like. > 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. > Yes, I think we will do so. Ciao, Mario
