myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Renzo Tomaselli <renzo.tomase...@tecnotp.it>
Subject Re: [Myfaces] cloned beans
Date Sat, 03 Mar 2007 18:02:02 GMT
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Werner Punz wrote:
<blockquote cite="midesbqb9$qh7$1@sea.gmane.org" type="cite">
  <pre wrap="">Renzo Tomaselli schrieb:
  </pre>
  <blockquote type="cite">
    <pre wrap="">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 &lt;ui:component&gt; and included in a page from
request to request by means of&lt;ui:include&gt; 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 &lt;ui:param&gt;.
Thanks for any suggestion -- Renzo


    </pre>
  </blockquote>
  <pre wrap=""><!---->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
  </pre>
</blockquote>
I guess managed beans are there to simplify java class instantiation
through symbols. One symbol, one instance.<br>
If I want more instances, either I forget about symbols, or I introduce
segmented symbols, e.i. introducing UI component roles.<br>
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.<br>
Actually I retrieve all dynamic beans by means of a centralized action
such as
"context.getApplication().getVariableResolver().resolveVariable(fc,
name);",<br>
after a matching internal navigation rule says "go to that bean name".<br>
I could even forget about the bean name. Assuming bean name/java class
equivalency, I can create beans manually like this:<br>
<br>
java.lang.Class cl = java.lang.Class.forName(beanClassName);<br>
MyBean bean = (MyBean)cl.getConstructor().newInstance();<br>
<br>
e.g. dealing with non-managed beans.<br>
The only problem with this approach is that I must forget about managed
properties.<br>
Btw, any pointer about writing a custom variable resolver ?<br>
<br>
-- Renzo<br>
<br>
<br>
</body>
</html>

Mime
View raw message