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:34:45 GMT
@Jacob: my proposed treewalker (or tree visitor) would be a solution
to many problems, and could even help here, yes. It would be the only
possibility to visit and access all components without having to be in
a special phase of the component lifecycle

(if you are in a phase, the problem is always that you have the API
restricting you in everything you can do. Of course, you can get out
of the API like ADF Faces is doing, but I don't think it is a good
option to create new component hierarchies _totally_ outside of the
API along the way. Why has the API been created in the first place?)

The more I think about it, the more this visitor stuff grows in
importance for me.



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