myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Marinschek" <>
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 needed to
have an else, in which it encodes the children one by one.



On 10/24/07, Simon Kitching <> wrote:
> ---- "Sochor Zdeněk" <> 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 <>)."
> > > 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


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

Professional Support for Apache MyFaces
View raw message