myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Marinschek" <martin.marinsc...@gmail.com>
Subject Re: Renderer and encodeChildren
Date Wed, 24 Oct 2007 18:23:43 GMT
Ok, poooh,

I had fixed the source into the wrong direction - now it should work
and is inline with the spec. encodeChildren in Renderer.java needed to
have an else, in which it encodes the children one by one.

regards,

Martin

On 10/24/07, Simon Kitching <simon.kitching@chello.at> wrote:
>
> ---- "Sochor Zdeněk" <zdenek.sochor@ataco.cz> schrieb:
> > Hi Simon,
> >   comments inside.
>
> Thanks. When you do that, please also remove the irrelevant bits from the
> email (as has been done here)..
>
> > >> But what do i wonder more is why page's component tree contains ALL
> > >> previously rendered/encoded components.
> > >> Wouldn't it make sense to remove non-rendered components from it?
> > >> I came across this issue when discussing topic: "TabbedPane does not
> > >> validate non-selected tabs in server side tab switching mode (Relaed to
> > >> TOMAHAWK-1012 <https://issues.apache.org/jira/browse/TOMAHAWK-1012>)."
>
> > > Non-rendered components can still have state configured into them by
> java code. Setters can be called on those components to set properties, and
> each component has an arbitrary Attributes map that can hold data.
> Discarding the non-rendered component would discard that data.
> > >
> > >
> > Doesn't this approach lead to two iteration of component tree?
> > 1.
> > on the first access to page create the whole tree regardless of rendered
> > attribute (so that all componentss could be interacted with) and
> > encoding them to view
> >     A little note - i can't find checks
> >         if (!isRendered()) return;
> >     found in many methods of UIComponentBase class from MyFaces  in
> > respective RI class.
> > on all subsequent acesses to page call decode on the whole tree (to
> > refresh all potential changes both from page input AND code)
> >
> > 2. render only components with rendered attribute=true
>
> I don't understand what you mean here.
>
> Yes, on createView all the components are created. And yes on render,
> components with rendered=false are not rendered.
> But all components have their state stored so they can be completely
> restored on postback (of course there are a number
> of possible optimisations here so that irrelevant data isn't saved).
>
> What is meant by "refresh all potential changes.."?
>
> >
> >
> > > I think another reason is that when re-rendering a page it is quite
> tricky to match up component declarations in the "template" file with
> existing components in the tree. When every component in the template file
> has an explicit id there is no trouble, but that is not usually the case.
> The only solution when a tag in the template file is found without an id is
> to assume it corresponds to the next anonymous component in the existing
> view tree. This "guessing" approach doesn't work well if components get
> removed from the tree just because they are not rendered. But the thought of
> absolutely requiring an id on every h:outputText and h:outputLabel in the
> template file is not tempting.
> > >
> > >
> > This wouldn't be an issue if whole tree was encoded (it would have
> > always same structure).
>
> Certainly with JSP, the plain text in a page is not present in the JSF tree.
> Saving that would not be at all efficient. So when rendering it is not
> sufficient to walk the component tree; instead the JSP-generated servlet
> must be executed. It outputs text, runs non-JSF tags, and runs JSF tags in
> the order specified in the JSP file. Those tags are stateless, so whenever
> one is executed by the servlet it has to "find" the right (pre-existing) JSF
> component to call. And that "find" step depends on the fact that the
> component-tree structure matches the jsp-page structure. Changing one but
> not the other will cause the "find" to return the wrong component.
>
> This is one reason why c:if and c:for are such a bad idea with JSF1.1. The
> view is restored correctly, but when the JSP-generated servlet is run, it
> tries to "find" components that weren't there last time (or not "find"
> components that were there), and so the "find" process gets out of sync if
> there are components without explicit ids.
>
> Some day I must figure out how JSF1.2 improves on this...
>
> I'm not sure how other ViewHandlers (eg Facelets) deal with this.
>
> Regards,
>
> Simon
>


-- 

http://www.irian.at

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

Professional Support for Apache MyFaces
Mime
View raw message