myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Neil Pitman" <neil.pit...@mahjongmania.com>
Subject RE: Session context was RE: Question about FacesContext
Date Wed, 21 Nov 2007 15:53:54 GMT
Remember that if this appears to introduce coupling, it is EXPLICIT
coupling that was implicit in the session.getAttribute(xx) approach
before.  And if seeing that scares you then you should have been doubly
scared before!  At least now, you can start to reduce it.

I should remember that this is a JSF list and not a
let's-write-bloated-JSP list.  Simon is very right.  Managed beans are
the way to go.  If you find that there is too much user state, the class
has too many unrelated variables then you can always partition it into
several concise objects, like ConnectionState, FinancialState,
SecurityState...

Session attributes are exactly like global variables.  They can be very
useful, but in a large system, the can "just change" and you have no
idea why.  The JSF managed beans or Spring beans solve that by
controlling access.  They become "the place" to go to understand how
they are created, referenced, updated and destroyed.

Neil

p.s. Simon reminds me of a place where some attributes were sometimes
String and sometimes String[].  Arrrrrgh.  Strong typing is good.


-----Original Message-----
From: Simon Kitching [mailto:simon.kitching@chello.at] 
Sent: November 21, 2007 10:28 AM
To: MyFaces Discussion
Subject: Re: Session context was RE: Question about FacesContext

Data in the session can be stored into a single class rather than
scattered:

public class UserState {
  private boolean isBlueMonday;
  private String someOtherDataItem;

  public boolean isBlueMonday() {
    return isBlueMonday;
  }

  public String getSomeOtherDataItem() {
    return someOtherDataItem;
  }
}

Of course that can create unnecessary coupling between different parts
of your app, so there is some tradeoff there.

But this bean can be declared as a managed-bean, and then injected into
other beans that need this info:
<managed-bean>
  <managed-bean-name>userState</managed-bean-name>
  <managed-bean-class>example.UserState</managed-bean-class>
  <managed-bean-scope>session</managed-bean-scope>
</managed-bean>

<managed-bean>
  <managed-bean-name>someBean</managed-bean-name>
  <managed-bean-class>example.SomeBean</managed-bean-class>
  <managed-bean-scope>request</managed-bean-scope>
  <managed-property>
    <property-name>userState</property-name>
    <value>#{userState}</value>
  </managed-property>
</managed-bean>

The someBean object now has access to the user state from the session
without having to know about the HttpSession object at all. And in a
typesafe manner.

Regards,

Simon

---- NABA <naba.nabou@gmx.net> schrieb:
> Hi Neil..
> You wrote:
> 
> The question is whether every class should know exactly how they are
> stored. And have to fetch them itself.
> 
> 
> How can a class fetch them istself to the other classes!
> Or is there an other method to get the objects.
> I m using now:
> 
> session.getAttribute("isBlueMonday");
> 
> However, this is a very good idea/approach to centrelize the access to

> the session to get objects!
> naba
> 
> Neil Pitman schrieb:
> > Hi Naba,
> >
> > The Session object and JSF are both part of the web layer.  For all
> > intents and purposes they are tightly bound together in webapps.  I
> > think that both should be unknown to EJBs or other model/data
layers.
> > The boundary between webapps and appservers should allow simple
domain
> > objects, but no technology decisions on either side; it becomes a
real
> > pain when you want to change a web technology, but the server has
become
> > dependent on it.
> >
> > My comment regarding HTTPSessions was more a question of clutter.
> > Obviously you need essential objects, like user key, and objects
related
> > to the interaction or user preferences, since they are costly to
obtain,
> > and should be near at hand for every subsequent request.
> >
> > The question is whether every class should know exactly how they are
> > stored. And have to fetch them itself.
> >
> > I would prefer a SessionWrapper class that has specific get/set
methods
> > with strong typing rather than a free-for-all of hardcoded session
> > queries like: session.getAttribute("isBlueMonday");
> >
> > The session object tends to get bloated, because everyone puts in,
but
> > no one dares clean it.  You need to pass the session around in every
> > call; it would be better to use a managed bean or a spring bean.
This
> > bean can certainly use the session for holding data.  But, it is the
> > only one holding the keys, literally.  Other classes do not need to
find
> > the key or make sure that it's correctly initialized, or decide
whether
> > the whole object is stored or just the keys.  And best of all, if
some
> > session attribute is getting corrupted, you can breakpoint the
> > SessionWrapper access to it.
> >
> > Right now, I have a reasonably complex JSF system.  I only keep the
some
> > keys related to the principle there.  Again, for performance and
> > clustering reasons, an essential (only the essential) session object
is
> > much better.  (let's not even talk about programmer sanity!)
> >
> > Neil
> >
> > -----Original Message-----
> > From: NABA [mailto:naba.nabou@gmx.net] 
> > Sent: November 21, 2007 3:18 AM
> > To: MyFaces Discussion
> > Subject: Re: Question about FacesContext
> >
> > Hi Neil!!
> > Is it a bad thing too, to access the session in JSF??
> > I do it all the time to get some beans from the session!!
> > Or do you answerd only the question from pdt! the access to a
session 
> > >from the ejb?
> >
> > naba
> >
> >
> >
> >
> > Neil Pitman schrieb:
> >   
> >> Hi Pdt,
> >>
> >> Whoa! That does not sound like a very good thing.  JSF is
definitely a
> >> web-layer/presentation thing.  While it might work in JBoss,
accessing
> >> the HTTP Sessions or HTTP Requests or JSF objects are a really bad
> >>     
> > idea.
> >   
> >> Here is a short and incomplete list of bad things that could
happen:
> >>
> >> 1) Web objects are not necessarily serializable, and if they are,
then
> >> modifications made in an EJB may be lost if the serialization is
one
> >>     
> > way
> >   
> >> 2) Even if it works, these are big objects with complex graphs of
> >> subobjects or sister objects, the performance hit could be large
> >>
> >> 3) JBoss is outside the EJB spec when it allows collocated web apps
> >>     
> > and
> >   
> >> enterprise apps to see each others' class loader.  Migration to
other
> >> app servers will be problematic
> >>
> >> 4) The dependencies become nightmarish
> >>
> >> 5) The appserver now depends on the JSF (again, an inversion of
> >> dependencies) so that a webservice might need to simulate JSF
> >>
> >> 6) kiss goodbye to any hope of decoupling the webserver from the
> >> appserver for performance reasons.
> >>
> >> If there is data that you need from the context, like domain keys,
> >>     
> > then
> >   
> >> these should be passed in explicitly as parameters to the session
> >>     
> > beans.
> >   
> >> These can be fundamental types like Strings, or your own value
> >>     
> > objects.
> >   
> >> I have spent the last 2 months trying to understand a webapp with
> >>     
> > every
> >   
> >> kind of data item, control flag and return code in their
HTTPSession
> >> object keyed with hardcoded strings.  Use simple serializable value
> >> objects; life is easier that way.
> >>
> >> Neil
> >>
> >>
> >> -----Original Message-----
> >> From: pdt_p [mailto:pinlie@gmail.com] 
> >> Sent: November 21, 2007 12:33 AM
> >> To: users@myfaces.apache.org
> >> Subject: Question about FacesContext
> >>
> >>
> >> Hi...
> >>
> >> I have 1 JSF ear, and 1 ejb ear deployed in a Jboss.
> >>
> >> normally, we execute FacesContext.getCurrentInstance() in order to
get
> >> current facescontext. But this method will return null when you
> >>     
> > execute
> >   
> >> it
> >> in one of the ejb class.
> >>
> >> is that possible to get JSF faces context from one of ejb class?
> >> if it's possible, how to do it?
> >>
> >> any idea
> >>
> >> thanks
> >>
> >>
> >> Pdt
> >>   
> >>     
> >
> >   
> 


Mime
View raw message