BTW, as far as the Trinidad components go, it's sufficient to simply say "getRendererType() == null"... but that doesn't account for self-rendered components. So, we might also do the converse: say that getRendererType() == null is what we use as a test, and if someone really needs a self-rendered component to be a target, they can add a marker interface to that component.
So in theory, we could do this without any API additions. The worst-case scenario is that a few self-rendered components PPR their parents instead of themselves. -- Adam On 9/15/06, Adam Winer <[EMAIL PROTECTED]> wrote:
I like this too. A JIRA issue would be fine, but we should pick the name for the marker interface here. In addition to Arjuna's ideas, maybe: NoMarkupComponent, LogicOnlyComponent? -- Adam On 9/14/06, Matthias Wessendorf <[EMAIL PROTECTED]> wrote: > > Arjuna, > > I like the idea of having a marker for those non-rendering-components > and enhancing RequestContext's addPartialTarget() logic for the tree > walk. > > Can you nail this issue / improvement to jira, that it doesn't get lost? > > > -Matthias > > > On 9/15/06, Arjuna Wijeyekoon <[EMAIL PROTECTED]> wrote: > > Hi,. > > > > Some components, like switcher and iterator, do not (or need not) > render any > > content themselves. > > This causes problems when you try to add that component as a partial > target, > > eg: > > > > RequestScope.getCurrentInstance().addPartialTarget(switcher); > > > > It would be nice if the addPartialTarget method could detect that the > > component does not render any content, walk up the tree and find the > closest > > ancestor that does render content and add that component as the > partial > > target. > > > > In order to do that, there should be a way for a component to identify > > > itself as being a no-chrome component. This way, switcher and iterator > and > > other 3rd party components can be added as partialTargets and things > will > > just magically work. > > > > This new interface could be called NonRenderingComponent, > > NoChromeComponent, NoContentComponent. > > (Alternatively, rather than use an interface, we could use a class > > annotation; although I am not sure of any particular advantage of > > annotations over interfaces. I will read up on that.) > > > > > > Additionally, the framework could enforce that a component marked with > such > > an interface does infact render nothing. > > > > thoughts? > > > > --Arjuna > > > > > > > -- > Matthias Wessendorf > > further stuff: > blog: http://jroller.com/page/mwessendorf > mail: mwessendorf-at-gmail-dot-com >
