myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Kienenberger" <>
Subject Re: [Myfaces] cloned beans
Date Sat, 03 Mar 2007 18:05:10 GMT
What about something like bean[0], bean[1], bean[2]?

You can do this without changing JSF code -- you just need to define
your own custom bean and beaninfo class.

On 3/3/07, Renzo Tomaselli <> wrote:
>  Werner Punz wrote:
>  Renzo Tomaselli schrieb:
>  Hi, I apologize for this topic non being strictly Myfaces-bound, but I
> think this mailgroup is very active on JSF in general, thus maybe
> someone can help.
> I use a very dynamic component-oriented architecture, from a mixup of
> Facelets, Tomahawk and Trinidad.
> Components are defined as <ui:component> and included in a page from
> request to request by means of<ui:include> tags (a placeholder).
> An internal navigation system leads from component to component within
> the *same* page. Rules can be user defined at runtime.
> An unpleasant side effect comes from the chance that the same component
> might appear multiple times on the same page, but unfortunately the
> associated managed bean (always request scoped) can exist only once,
> since it's a one-to-one association between a bean name and a java
> instance.
> Is anybody able to suggest alternative ways to the obvious solution of
> statically cloning the same bean by naming it multiple times in a
> faces-config like file ?
> Or is there any way to clone beans at runtime, giving them a dynamic
> name but still getting managed properties loaded ?
> In my case component bean names are never statically included in
> facelets, since they always appear there as "bean", where actual bean is
> achieved from another bean property and passed through <ui:param>.
> Thanks for any suggestion -- Renzo
>  You can write your own variable resolver which does the cloning for you
> if you need it, with that you can break the existing name 1:1 bean
> mapping to your needs.
> Although I must say, rethink your usecases, you might run into a mess
> if you break it, it is there for a reason
>  I guess managed beans are there to simplify java class instantiation
> through symbols. One symbol, one instance.
>  If I want more instances, either I forget about symbols, or I introduce
> segmented symbols, e.i. introducing UI component roles.
>  In the latter case, I would avoid to forecast all ways a bean might enter a
> page layout, if this layout is left in user hands.
>  Actually I retrieve all dynamic beans by means of a centralized action such
> as
> "context.getApplication().getVariableResolver().resolveVariable(fc,
> name);",
>  after a matching internal navigation rule says "go to that bean name".
>  I could even forget about the bean name. Assuming bean name/java class
> equivalency, I can create beans manually like this:
>  java.lang.Class cl = java.lang.Class.forName(beanClassName);
>  MyBean bean = (MyBean)cl.getConstructor().newInstance();
>  e.g. dealing with non-managed beans.
>  The only problem with this approach is that I must forget about managed
> properties.
>  Btw, any pointer about writing a custom variable resolver ?
>  -- Renzo

View raw message