Hi Mario, just for me to clarify this for myself - if we trod down the path proposed by Adam, how do we get out of a conversation again?
regards, Martin On 4/27/06, Mario Ivankovits <[EMAIL PROTECTED]> wrote: > 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 > > -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
