I agree with the fact the "traditional" way of doing things is hard ot get rid of, I agree with Pete too, but if I may, I'd say it's often hard or impossible to avoid some "view bean".<br><br>You can, when you only want to display stuff that doesn't need any 'UI' reformatting.<br>
<br>Otoh, take a canonical CRUD: the submit button requires an action method you don't have in your business layer. So it must go on a bean standing behind the view.<br><br>Another example: feed a table on the screen. If the objects fetched from the business layer can be displayed as-is, you can directly call the EJB. But many developers will be reluctant to annotate it @Named. So you have to wire your business methods through a view bean which is known to EL. Now, if the elements on the table require any manipulation/action, you have to encapsulate them and there's no other way but to get the cooking done on some view bean.<br>
<br>And as development teams are required to work in a "normalized" way no matter what's going to be on the screen, you end up having complete web applications wiring all the biz methods through view beans.<br>
<br>After all I see no probmem with that, with CDI everyone can work the way he wants. In my application I get all the db/xml configs via producer methods, and I did a custom scope/context to refresh them without restarting anything. So no matter whether you want to do simple of sophisticated things, CDI has a solution in store.<br>
<br>fm.<br>
<br>
<br><br><br><div class="gmail_quote">On Thu, Dec 22, 2011 at 2:06 PM, Peter Muir <span dir="ltr"><<a href="mailto:pmuir@redhat.com">pmuir@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF"><div>IMO both approaches are valid in different situations, and it entirely depends on the app. If I have multiple view layers (eg jsf and jax rs I will likely want some sort of controller bean betweeny business layer and jsf, so as to not let jsf concerns leak. Otoh if it was just a web app with a jsf front end only, maybe I would dispose of this layer.<br>
<br>--<div>Pete Muir</div><div><a href="http://in.relation.to/Bloggers/Pete" target="_blank">http://in.relation.to/Bloggers/Pete</a></div></div><div><div class="h5"><div><br>On 22 Dec 2011, at 11:36, "John D. Ament" <<a href="mailto:john.d.ament@gmail.com" target="_blank">john.d.ament@gmail.com</a>> wrote:<br>
<br></div><div></div><blockquote type="cite"><div>I tried this a few times recently. the main issue that pops up is that the EJB timeouts and WEB timeouts in the platform do not sync up. so if you're idle on a page for 5 minutes, your stateful EJB disappears, unless you have someone change container config.<br>
<br><div class="gmail_quote">On Thu, Dec 22, 2011 at 5:49 AM, José Rodolfo Freitas <span dir="ltr"><<a href="mailto:joserodolfo.freitas@gmail.com" target="_blank">joserodolfo.freitas@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
CDI created the possibility to reach any bean in the container from a JSF view, encouraging a closer approach between ejb and jsf (or any cdi bean and jsf), which can potentially lead to a simpler application design. I think that is great!<div>
<br></div><div>However, I'm observing that this new programming model has been experimenting user resistance. The "traditional" way of doing things, using a "ViewBean" accessing a Stateless Service seems to be the </div>
<div>more legit.</div><div><br></div><div>What do you think about this? I'd like to discuss best practices around it as I see it's on the core of almost every web application design. </div><div><br></div><div><br>
</div><div><br></div><div><div><br></div></div>
<br>_______________________________________________<br>
seam-dev mailing list<br>
<a href="mailto:seam-dev@lists.jboss.org" target="_blank">seam-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/seam-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/seam-dev</a><br>
<br></blockquote></div><br>
</div></blockquote></div></div><blockquote type="cite"><div><span>_______________________________________________</span><br><span>cdi-dev mailing list</span><br><span><a href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.org</a></span><br>
<span><a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a></span><br></div></blockquote></div><br>_______________________________________________<br>
cdi-dev mailing list<br>
<a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br><a href="http://www.suntriprecords.com">http://www.suntriprecords.com</a><br><br>