myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Marinschek" <>
Subject Re: enhancements to form and command* components
Date Fri, 28 Apr 2006 06:37:30 GMT
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?



On 4/27/06, Mario Ivankovits <> 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


Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

View raw message