4:49 a.m.
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!
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
more legit.
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.
5:36 a.m.
New subject: [seam-dev] Stafeful services directly from the JSF VS "ViewBean" + stateless service
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.
On Thu, Dec 22, 2011 at 5:49 AM, José Rodolfo Freitas <
joserodolfo.freitas(a)gmail.com> wrote:
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!
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
more legit.
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.
_______________________________________________
seam-dev mailing list
seam-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev
7:06 a.m.
New subject: [seam-dev] Stafeful services directly from the JSF VS "ViewBean" + stateless service
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.
--
Pete Muir
http://in.relation.to/Bloggers/Pete
On 22 Dec 2011, at 11:36, "John D. Ament" <john.d.ament(a)gmail.com>
wrote:
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.
On Thu, Dec 22, 2011 at 5:49 AM, José Rodolfo Freitas
<joserodolfo.freitas(a)gmail.com> wrote:
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!
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
more legit.
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.
_______________________________________________
seam-dev mailing list
seam-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev
_______________________________________________
cdi-dev mailing list
cdi-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev
8:41 a.m.
New subject: [seam-dev] Stafeful services directly from the JSF VS "ViewBean" + stateless service
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".
You can, when you only want to display stuff that doesn't need any 'UI'
reformatting.
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.
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.
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.
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.
fm.
On Thu, Dec 22, 2011 at 2:06 PM, Peter Muir <pmuir(a)redhat.com> wrote:
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.
--
Pete Muir
http://in.relation.to/Bloggers/Pete
On 22 Dec 2011, at 11:36, "John D. Ament" <john.d.ament(a)gmail.com>
wrote:
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.
On Thu, Dec 22, 2011 at 5:49 AM, José Rodolfo Freitas <
joserodolfo.freitas(a)gmail.com> wrote:
> 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!
>
> 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
> more legit.
>
> 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.
>
>
>
>
>
> _______________________________________________
> seam-dev mailing list
> seam-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/seam-dev
>
>
_______________________________________________
cdi-dev mailing list
cdi-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev
_______________________________________________
cdi-dev mailing list
cdi-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev
--
http://www.suntriprecords.com
6:29 p.m.
On Thu, Dec 22, 2011 at 05:49, José Rodolfo Freitas <
joserodolfo.freitas(a)gmail.com> wrote:
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!
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
more legit.
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.
The way I've always looked at this is that the initiative to flatten the
tiers in the Java EE platform was always focused on making the platform
more approachable. When you read tutorials that require many technical
steps that doesn't seem to add any value, the perception is that the
platform is overkill. Why create two beans when one will do?
I think that once an application matures, many of your UI interactions will
go through a controller layer that mediates between the view and the
services. If you're an experienced developer, this maturation may occur as
early as the design stage, in which case you never even write any code that
uses the flattened architecture. But it's critical for tutorials &
prototypes.
Another way to say this is that there is no reason to enforce a middleman.
Why can't the UI just invoke any service you expose directly? There will be
plenty of cases when that's reasonable. If there is a reason it shouldn't,
that should be a restriction you impose, not one that the platform imposes.
So I advise you to not feel shy about creating a view controller if it
feels right. You should only observe yourself creating a bean that does
nothing but delegate to another bean and ask why you are doing that.
-Dan
--
Dan Allen
Principal Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://google.com/profiles/dan.j.allen
http://mojavelinux.com
http://mojavelinux.com/seaminaction
4516
days inactive
4518
days old
4 comments
5 participants
participants (5)
-
Dan Allen -
Fabien Marsaud -
John D. Ament -
José Rodolfo Freitas -
Peter Muir