Re: [Myfaces] cloned beans

[Renzo Tomaselli]

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