You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@shale.apache.org by numpsy beelzebub <nu...@gmail.com> on 2006/09/17 21:18:27 UTC
getbean method question
with getbean method i have the possibility to access managed beans
where is this feature from... is see therefore bean has to extends to
AbstractViewController or AbstractApplicationController
i never used jsf but was this a feature in the past...
i "googled" and found a relationalship to spring - so i looked on apache
shale web site (spring integration)
is this feature from spring integration?
Re: getbean method question
Posted by stephan opitz <st...@gmail.com>.
* Use standard JavaBeans for the JSF backing beans,
and put the business logic into an EJB session bean
(most likely using annotations to inject this)
the problem if in backing bean -> how to manage the presentations preparing
logic... with ejbs - should i all "first" prepare and then to "hand down"
in the ejb - not so useful... and whats with shale "special funcition"
which can not use in deep ejbs
yeah would you prefer to fill the backing beans within ejbs (give
reference to backing bean into ejb to fill there) or not
2006/9/19, numpsy beelzebub <nu...@gmail.com>:
> great explanations, but few more questions:
>
> * Embed the business logic in the event handlers
> (roughly corresponding to embedding business
> logic in an Action.execute() method in Struts.
>
> so i know if i push a button i can first call an event handlers and
> afterwards the specific action - so wouldn't be in both business logic?
> dont seee the advantage at all
>
> * Use standard JavaBeans for the JSF backing beans,
> and put the business in other pure JavaBeans.
>
> clear - or in the backing bean itself!
>
> * Use standard JavaBeans for the JSF backing beans,
> and put the business logic into an EJB session bean
> (most likely using annotations to inject this)
>
> the problem if in backing bean -> how to manage the presentations preparing
> logic... with ejbs - should i all "first" prepare and then to "hand down"
> in the ejb - not so useful... and whats with shale "special funcition"
> which can not use in deep ejbs
>
> * Dispense with using a standard JavaBean, and make
> the EJB session bean be *both* the backing bean
> and the business logic (this is the approach that
> JBoss Seam uses, for example).
>
> the best solution - access to all features of the framework and ejb at same
> time
>
> ###############################################################
>
> are there more overlaps than:
> livecycle annotations - jsf 1.2
> client- and serverside validators - jsf 2.0
>
> thx
>
>
> 2006/9/19, Craig McClanahan <cr...@apache.org>:
> >
> > On 9/18/06, numpsy beelzebub <nu...@gmail.com> wrote:
> > >
> > > my questions for used / important / generally functions has as context
> > the
> > > see on the architecture!
> > > i'm excited "fan" of clay and its features given to developer - and
> > shale
> > > other features. so the presentation part of application is clear.
> > >
> > > but the business logic is the fact...
> > >
> > > i mean especially the gap between ejb 3.0 and shale models
> > >
> > > >It encompasses the kinds of patterns that I would
> > > >recommend for building new apps today.
> > >
> > > 1. i followed your thinking about the example an the port from struts
> > and
> > > thats right, but lets talk about you last statement. your experience is
> > > more
> > > great than my - so maybe underline your statement!
> > >
> > > 2. as i asked in another mail - all talk about ejb 3.0 and the jpa is
> > > built
> > > upon ejb 3.0.
> > > so if already use ejb 3.0 for persistence or jpa - whats your opinion
> > > about
> > > mix or share business code in the shale model objects and in
> > > stateful/stateless ejbs.
> >
> >
> > Just to clarify terminology a bit ... "jpa is built upon ejb 3.0" is not
> > technically correct. The JPA specification was built by the same group
> > that
> > did the EJB3 specification, but the technologies are independent of each
> > other. Informally, you can think of JPA as being the replacement for
> > entity beans in EJB 2.1, while EJB3 contains just session beans (stateless
> > and stateful) and message driven beans.
> >
> > Given that, there are really four general approaches to the business logic
> > of a JSF based application (and they apply pretty much the same with or
> > without Shale).
> >
> > * Embed the business logic in the event handlers
> > (roughly corresponding to embedding business
> > logic in an Action.execute() method in Struts.
> >
> > * Use standard JavaBeans for the JSF backing beans,
> > and put the business in other pure JavaBeans.
> >
> > * Use standard JavaBeans for the JSF backing beans,
> > and put the business logic into an EJB session bean
> > (most likely using annotations to inject this)
> >
> > * Dispense with using a standard JavaBean, and make
> > the EJB session bean be *both* the backing bean
> > and the business logic (this is the approach that
> > JBoss Seam uses, for example).
> >
> > I think we'll see all four approaches get used. The first will tend to
> > get
> > used by programmers not as familiar with O-O techniques, or in cases where
> > you're primarily interested in rapid development (such as a
> > prototype). The
> > second and third approaches will be a natural choice if you already have
> > your business logic encapsulated -- for instance, the second method works
> > great if you're already using Spring for instantiating your business logic
> > beans. The third (EJB session beans) is nice if you need the
> > transactional
> > behavior or statefulness you can get with EJBs without the extra setup it
> > takes to get that out of Spring.
> >
> > The fourth approach (Seam) sounds a bit odd, but it's really pretty much
> > equivalent to the first. Besides being useful in the cases described
> > there,
> > it can make sense when the "business logic" you are talking about is so
> > tied
> > to the particular application you are doing that you'd get no reuse
> > benefit
> > out of abstracting it into a separate class. The fourth approach
> > (compared
> > to the first) gives you transactionality and statefulness if you need
> > them.
> >
> > Which is best? There's no one right answer. It's going to get driven a
> > lot
> > by your particular application use cases, whether you have previously
> > abstracted your business logic (versus you have to write it from scratch),
> > and your own preferences for object oriented development and splitting
> > this
> > kind of stuff.
> >
> > 3. what do you think about the basic approaches of shale and struts - i
> > know
> > > you leaded both - so would you built an framework like struts again,
> > with
> > > the knowledge of what shale can perform.
> >
> >
> > If I still liked the Struts approach, I wouldn't have built Shale in the
> > first place :-).
> >
> > If you like an action oriented framework, Struts 2.x is going to be
> > *substantially* better than Struts 1.x. However, IMHO, both of them
> > present
> > you with lots of power, but require you to understand more complexity than
> > you should really need to understand, for the 80% of applications that
> > don't
> > need that kind of power.
> >
> > The simplicity that comes with being able to handle all the interesting
> > server side events for a particular page, in a single Java class, is
> > pretty
> > compelling. (You can accomplish this with Struts 2.x with some
> > sophisticated configuration; for Struts 1.x you can't really accomplish
> > this
> > gracefully for all the use cases that Shale supports).
> >
> >
> > 4. is shale an addon to jsf or the next jsf? ;-) and how will be handled
> > > overlaps between shale and jsf 1.2 (i think for @PostConstruct in
> > > comparing
> > > to shale livecycle) - because you told shale is independent for all jsf
> > ri
> > > and you will test with 1.2 which is part of java ee from 11.05.06
> >
> >
> > The contents of "the next JSF" is totally up to the next JSF expert group,
> > and what they elect to include. There are certainly some ideas from Shale
> > that I would like to see put in the standard, but what actually happens
> > remains to be seen.
> >
> > In the mean time, anyone who elects to depend on Shale is going to
> > *expect*
> > Shale to continue to support its own annotations, even if they are (in
> > some
> > sense) superceded by standard ones. And that is a perfectly feasible
> > thing
> > to continue doing.
> >
> > In the particular case of @PostConstruct and @PreDestroy, that's something
> > Shale might look at optionally supporting for the case where you're using
> > JDK 1.5 to compile your app, but you're running it on a J2EE 1.4 level
> > server that doesn't support them natively.
> >
> > thx
> >
> >
> > Craig
> >
> >
> > 2006/9/18, Craig McClanahan <cr...@apache.org>:
> > > >
> > > > On 9/18/06, numpsy beelzebub <nu...@gmail.com> wrote:
> > > > >
> > > > > thx.
> > > > >
> > > > > but whats in your opinion the most used / important / generally
> > > > functions,
> > > > > that used in modell objects:
> > > > > i suppose
> > > > > 1. the facesmessage - maybe generating some fault or info message
> > > stuff
> > > > > 2. getbean - maybe get access to managed beans - change them etc
> > > > > 3. getParameter - to looks for requested values
> > > > >
> > > > > but what else?
> > > >
> > > >
> > > > To me, trying to pick the most important *methods* is a little bit too
> > > > fine
> > > > grained to be useful, because different applications have widely
> > varying
> > > > needs. Instead, I would tend to focus first on the architectural
> > > patterns
> > > > that a particular framework enables, and then see if that matches up
> > to
> > > > your
> > > > application requirements.
> > > >
> > > > In the case of Shale, I would suggest looking at the
> > > > "shale-mailreader-jpa"
> > > > example application. Functionally, it is the same as the good old
> > > Struts
> > > > example app that has been around for almost six years now. But, this
> > > > implementation uses JavaServer Faces and Shale for the view tier, and
> > > Java
> > > > Persistence Architecture (JPA) for the model tier (although you could
> > > > easily
> > > > substitute Hibernate). It encompasses the kinds of patterns that I
> > > would
> > > > recommend for building new apps today.
> > > >
> > > > Craig
> > > >
> > > >
> > > > :-)
> > > > >
> > > > >
> > > > >
> > > > > 2006/9/18, Craig McClanahan <cr...@apache.org>:
> > > > > >
> > > > > > On 9/18/06, numpsy beelzebub <nu...@gmail.com> wrote:
> > > > > > > thx,
> > > > > > >
> > > > > > > once more i wnat to know what are the most important / generally
> > > > > > functions
> > > > > > > in shale, that used in modell objects:
> > > > > > > 1. the facesmessage - maybe generating some stuff
> > > > > > > 2. getbean - maybe get acces to managed beans - change them etc
> > > > > > > ...
> > > > > > > ...
> > > > > > >
> > > > > > > shale is a framework built on the base to have features, which
> > can
> > > > be
> > > > > > > replaced and als which don't have to used - in fact a user if he
> > > is
> > > > > only
> > > > > > a
> > > > > > > jsf fan he don't use shale features - but he can...
> > > > > > > clay is genial... and other parts too - so on should
> > > > > > >
> > > > > > > would it possible to use mybe shale clay on every other jsf
> > > > framework
> > > > > or
> > > > > > > references it to myfaces sources?
> > > > > >
> > > > > > The shale-clay library itself depends on shale-core, but that does
> > > not
> > > > > > mean your application needs to use any other Shale features if you
> > > do
> > > > > > not wish to. There is no reason to reference sources from the
> > > MyFaces
> > > > > > JSF implementation (or the reference implementation), because
> > Shale
> > > > > > utilizes only the standard extension APIs that JSF provides.
> > > > > >
> > > > > > Craig
> > > > > >
> > > > > > >
> > > > > > > what more...
> > > > > > >
> > > > > > > stephan
> > > > > > >
> > > > > > >
> > > > > > > 2006/9/18, Craig McClanahan <cr...@apache.org>:
> > > > > > > >
> > > > > > > > On 9/17/06, numpsy beelzebub <nu...@gmail.com> wrote:
> > > > > > > > >
> > > > > > > > > with getbean method i have the possibility to access
> > managed
> > > > > beans
> > > > > > > > >
> > > > > > > > > where is this feature from... is see therefore bean has to
> > > > extends
> > > > > > to
> > > > > > > > > AbstractViewController or AbstractApplicationController
> > > > > > > > >
> > > > > > > > > i never used jsf but was this a feature in the past...
> > > > > > > >
> > > > > > > >
> > > > > > > > If you look at the source code for AbstractViewController
> > > itself,
> > > > > you
> > > > > > will
> > > > > > > > see that it extends AbstractFaceBean, which in turn contains
> > the
> > > > > > defiition
> > > > > > > > for getBean(). Then, if you look at that method, you will see
> > > > that
> > > > > it
> > > > > > > > simply uses standard features of the JavaServer Faces API that
> > > let
> > > > > you
> > > > > > > > interact with the standard JSF "Variable Resolver" -- the part
> > > of
> > > > > JSF
> > > > > > that
> > > > > > > > actually implements managed beans:
> > > > > > > >
> > > > > > > > protected Object getBean(String name) {
> > > > > > > > FacesContext context = getFacesContext(); //
> > > > > > > > FacesContext.getCurrentInstance()
> > > > > > > > return context.getApplication().getVariableResolver().
> > > > > > > > resolveVariable(context, name);
> > > > > > > > }
> > > > > > > >
> > > > > > > > A similar convenience method lets you evaluate any value
> > binding
> > > > > > > > expression
> > > > > > > > (such as "#{foo.bar}") from within an application, again using
> > > > > > standard
> > > > > > > > JSF
> > > > > > > > APIs:
> > > > > > > >
> > > > > > > > protected Object getValue(String expr) {
> > > > > > > > ValueBinding vb =
> > > > getApplication().createValueBinding(expr);
> > > > > > > > return vb.getValue(getFacesContext());
> > > > > > > > }
> > > > > > > >
> > > > > > > > i "googled" and found a relationalship to spring - so i looked
> > > on
> > > > > > apache
> > > > > > > > > shale web site (spring integration)
> > > > > > > > >
> > > > > > > > > is this feature from spring integration?
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > > No, this particular feature was inspired by similar features
> > in
> > > > the
> > > > > > > > application model that Sun Java Studio Creator uses for the
> > > > > > applications
> > > > > > > > it
> > > > > > > > builds. The part of Shale most directly influenced by Spring
> > is
> > > > the
> > > > > > > > DIalog
> > > > > > > > feature, which has conceptual similarities to Spring Web Flow
> > --
> > > > in
> > > > > > > > particular, the idea of modelling a dialog as a state machine
> > > with
> > > > > > action
> > > > > > > > states and view states (among others).
> > > > > > > >
> > > > > > > > Craig
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
Re: getbean method question
Posted by numpsy beelzebub <nu...@gmail.com>.
great explanations, but few more questions:
* Embed the business logic in the event handlers
(roughly corresponding to embedding business
logic in an Action.execute() method in Struts.
so i know if i push a button i can first call an event handlers and
afterwards the specific action - so wouldn't be in both business logic?
dont seee the advantage at all
* Use standard JavaBeans for the JSF backing beans,
and put the business in other pure JavaBeans.
clear - or in the backing bean itself!
* Use standard JavaBeans for the JSF backing beans,
and put the business logic into an EJB session bean
(most likely using annotations to inject this)
the problem if in backing bean -> how to manage the presentations preparing
logic... with ejbs - should i all "first" prepare and then to "hand down"
in the ejb - not so useful... and whats with shale "special funcition"
which can not use in deep ejbs
* Dispense with using a standard JavaBean, and make
the EJB session bean be *both* the backing bean
and the business logic (this is the approach that
JBoss Seam uses, for example).
the best solution - access to all features of the framework and ejb at same
time
###############################################################
are there more overlaps than:
livecycle annotations - jsf 1.2
client- and serverside validators - jsf 2.0
thx
2006/9/19, Craig McClanahan <cr...@apache.org>:
>
> On 9/18/06, numpsy beelzebub <nu...@gmail.com> wrote:
> >
> > my questions for used / important / generally functions has as context
> the
> > see on the architecture!
> > i'm excited "fan" of clay and its features given to developer - and
> shale
> > other features. so the presentation part of application is clear.
> >
> > but the business logic is the fact...
> >
> > i mean especially the gap between ejb 3.0 and shale models
> >
> > >It encompasses the kinds of patterns that I would
> > >recommend for building new apps today.
> >
> > 1. i followed your thinking about the example an the port from struts
> and
> > thats right, but lets talk about you last statement. your experience is
> > more
> > great than my - so maybe underline your statement!
> >
> > 2. as i asked in another mail - all talk about ejb 3.0 and the jpa is
> > built
> > upon ejb 3.0.
> > so if already use ejb 3.0 for persistence or jpa - whats your opinion
> > about
> > mix or share business code in the shale model objects and in
> > stateful/stateless ejbs.
>
>
> Just to clarify terminology a bit ... "jpa is built upon ejb 3.0" is not
> technically correct. The JPA specification was built by the same group
> that
> did the EJB3 specification, but the technologies are independent of each
> other. Informally, you can think of JPA as being the replacement for
> entity beans in EJB 2.1, while EJB3 contains just session beans (stateless
> and stateful) and message driven beans.
>
> Given that, there are really four general approaches to the business logic
> of a JSF based application (and they apply pretty much the same with or
> without Shale).
>
> * Embed the business logic in the event handlers
> (roughly corresponding to embedding business
> logic in an Action.execute() method in Struts.
>
> * Use standard JavaBeans for the JSF backing beans,
> and put the business in other pure JavaBeans.
>
> * Use standard JavaBeans for the JSF backing beans,
> and put the business logic into an EJB session bean
> (most likely using annotations to inject this)
>
> * Dispense with using a standard JavaBean, and make
> the EJB session bean be *both* the backing bean
> and the business logic (this is the approach that
> JBoss Seam uses, for example).
>
> I think we'll see all four approaches get used. The first will tend to
> get
> used by programmers not as familiar with O-O techniques, or in cases where
> you're primarily interested in rapid development (such as a
> prototype). The
> second and third approaches will be a natural choice if you already have
> your business logic encapsulated -- for instance, the second method works
> great if you're already using Spring for instantiating your business logic
> beans. The third (EJB session beans) is nice if you need the
> transactional
> behavior or statefulness you can get with EJBs without the extra setup it
> takes to get that out of Spring.
>
> The fourth approach (Seam) sounds a bit odd, but it's really pretty much
> equivalent to the first. Besides being useful in the cases described
> there,
> it can make sense when the "business logic" you are talking about is so
> tied
> to the particular application you are doing that you'd get no reuse
> benefit
> out of abstracting it into a separate class. The fourth approach
> (compared
> to the first) gives you transactionality and statefulness if you need
> them.
>
> Which is best? There's no one right answer. It's going to get driven a
> lot
> by your particular application use cases, whether you have previously
> abstracted your business logic (versus you have to write it from scratch),
> and your own preferences for object oriented development and splitting
> this
> kind of stuff.
>
> 3. what do you think about the basic approaches of shale and struts - i
> know
> > you leaded both - so would you built an framework like struts again,
> with
> > the knowledge of what shale can perform.
>
>
> If I still liked the Struts approach, I wouldn't have built Shale in the
> first place :-).
>
> If you like an action oriented framework, Struts 2.x is going to be
> *substantially* better than Struts 1.x. However, IMHO, both of them
> present
> you with lots of power, but require you to understand more complexity than
> you should really need to understand, for the 80% of applications that
> don't
> need that kind of power.
>
> The simplicity that comes with being able to handle all the interesting
> server side events for a particular page, in a single Java class, is
> pretty
> compelling. (You can accomplish this with Struts 2.x with some
> sophisticated configuration; for Struts 1.x you can't really accomplish
> this
> gracefully for all the use cases that Shale supports).
>
>
> 4. is shale an addon to jsf or the next jsf? ;-) and how will be handled
> > overlaps between shale and jsf 1.2 (i think for @PostConstruct in
> > comparing
> > to shale livecycle) - because you told shale is independent for all jsf
> ri
> > and you will test with 1.2 which is part of java ee from 11.05.06
>
>
> The contents of "the next JSF" is totally up to the next JSF expert group,
> and what they elect to include. There are certainly some ideas from Shale
> that I would like to see put in the standard, but what actually happens
> remains to be seen.
>
> In the mean time, anyone who elects to depend on Shale is going to
> *expect*
> Shale to continue to support its own annotations, even if they are (in
> some
> sense) superceded by standard ones. And that is a perfectly feasible
> thing
> to continue doing.
>
> In the particular case of @PostConstruct and @PreDestroy, that's something
> Shale might look at optionally supporting for the case where you're using
> JDK 1.5 to compile your app, but you're running it on a J2EE 1.4 level
> server that doesn't support them natively.
>
> thx
>
>
> Craig
>
>
> 2006/9/18, Craig McClanahan <cr...@apache.org>:
> > >
> > > On 9/18/06, numpsy beelzebub <nu...@gmail.com> wrote:
> > > >
> > > > thx.
> > > >
> > > > but whats in your opinion the most used / important / generally
> > > functions,
> > > > that used in modell objects:
> > > > i suppose
> > > > 1. the facesmessage - maybe generating some fault or info message
> > stuff
> > > > 2. getbean - maybe get access to managed beans - change them etc
> > > > 3. getParameter - to looks for requested values
> > > >
> > > > but what else?
> > >
> > >
> > > To me, trying to pick the most important *methods* is a little bit too
> > > fine
> > > grained to be useful, because different applications have widely
> varying
> > > needs. Instead, I would tend to focus first on the architectural
> > patterns
> > > that a particular framework enables, and then see if that matches up
> to
> > > your
> > > application requirements.
> > >
> > > In the case of Shale, I would suggest looking at the
> > > "shale-mailreader-jpa"
> > > example application. Functionally, it is the same as the good old
> > Struts
> > > example app that has been around for almost six years now. But, this
> > > implementation uses JavaServer Faces and Shale for the view tier, and
> > Java
> > > Persistence Architecture (JPA) for the model tier (although you could
> > > easily
> > > substitute Hibernate). It encompasses the kinds of patterns that I
> > would
> > > recommend for building new apps today.
> > >
> > > Craig
> > >
> > >
> > > :-)
> > > >
> > > >
> > > >
> > > > 2006/9/18, Craig McClanahan <cr...@apache.org>:
> > > > >
> > > > > On 9/18/06, numpsy beelzebub <nu...@gmail.com> wrote:
> > > > > > thx,
> > > > > >
> > > > > > once more i wnat to know what are the most important / generally
> > > > > functions
> > > > > > in shale, that used in modell objects:
> > > > > > 1. the facesmessage - maybe generating some stuff
> > > > > > 2. getbean - maybe get acces to managed beans - change them etc
> > > > > > ...
> > > > > > ...
> > > > > >
> > > > > > shale is a framework built on the base to have features, which
> can
> > > be
> > > > > > replaced and als which don't have to used - in fact a user if he
> > is
> > > > only
> > > > > a
> > > > > > jsf fan he don't use shale features - but he can...
> > > > > > clay is genial... and other parts too - so on should
> > > > > >
> > > > > > would it possible to use mybe shale clay on every other jsf
> > > framework
> > > > or
> > > > > > references it to myfaces sources?
> > > > >
> > > > > The shale-clay library itself depends on shale-core, but that does
> > not
> > > > > mean your application needs to use any other Shale features if you
> > do
> > > > > not wish to. There is no reason to reference sources from the
> > MyFaces
> > > > > JSF implementation (or the reference implementation), because
> Shale
> > > > > utilizes only the standard extension APIs that JSF provides.
> > > > >
> > > > > Craig
> > > > >
> > > > > >
> > > > > > what more...
> > > > > >
> > > > > > stephan
> > > > > >
> > > > > >
> > > > > > 2006/9/18, Craig McClanahan <cr...@apache.org>:
> > > > > > >
> > > > > > > On 9/17/06, numpsy beelzebub <nu...@gmail.com> wrote:
> > > > > > > >
> > > > > > > > with getbean method i have the possibility to access
> managed
> > > > beans
> > > > > > > >
> > > > > > > > where is this feature from... is see therefore bean has to
> > > extends
> > > > > to
> > > > > > > > AbstractViewController or AbstractApplicationController
> > > > > > > >
> > > > > > > > i never used jsf but was this a feature in the past...
> > > > > > >
> > > > > > >
> > > > > > > If you look at the source code for AbstractViewController
> > itself,
> > > > you
> > > > > will
> > > > > > > see that it extends AbstractFaceBean, which in turn contains
> the
> > > > > defiition
> > > > > > > for getBean(). Then, if you look at that method, you will see
> > > that
> > > > it
> > > > > > > simply uses standard features of the JavaServer Faces API that
> > let
> > > > you
> > > > > > > interact with the standard JSF "Variable Resolver" -- the part
> > of
> > > > JSF
> > > > > that
> > > > > > > actually implements managed beans:
> > > > > > >
> > > > > > > protected Object getBean(String name) {
> > > > > > > FacesContext context = getFacesContext(); //
> > > > > > > FacesContext.getCurrentInstance()
> > > > > > > return context.getApplication().getVariableResolver().
> > > > > > > resolveVariable(context, name);
> > > > > > > }
> > > > > > >
> > > > > > > A similar convenience method lets you evaluate any value
> binding
> > > > > > > expression
> > > > > > > (such as "#{foo.bar}") from within an application, again using
> > > > > standard
> > > > > > > JSF
> > > > > > > APIs:
> > > > > > >
> > > > > > > protected Object getValue(String expr) {
> > > > > > > ValueBinding vb =
> > > getApplication().createValueBinding(expr);
> > > > > > > return vb.getValue(getFacesContext());
> > > > > > > }
> > > > > > >
> > > > > > > i "googled" and found a relationalship to spring - so i looked
> > on
> > > > > apache
> > > > > > > > shale web site (spring integration)
> > > > > > > >
> > > > > > > > is this feature from spring integration?
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > No, this particular feature was inspired by similar features
> in
> > > the
> > > > > > > application model that Sun Java Studio Creator uses for the
> > > > > applications
> > > > > > > it
> > > > > > > builds. The part of Shale most directly influenced by Spring
> is
> > > the
> > > > > > > DIalog
> > > > > > > feature, which has conceptual similarities to Spring Web Flow
> --
> > > in
> > > > > > > particular, the idea of modelling a dialog as a state machine
> > with
> > > > > action
> > > > > > > states and view states (among others).
> > > > > > >
> > > > > > > Craig
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
Re: getbean method question
Posted by Craig McClanahan <cr...@apache.org>.
On 9/18/06, numpsy beelzebub <nu...@gmail.com> wrote:
>
> my questions for used / important / generally functions has as context the
> see on the architecture!
> i'm excited "fan" of clay and its features given to developer - and shale
> other features. so the presentation part of application is clear.
>
> but the business logic is the fact...
>
> i mean especially the gap between ejb 3.0 and shale models
>
> >It encompasses the kinds of patterns that I would
> >recommend for building new apps today.
>
> 1. i followed your thinking about the example an the port from struts and
> thats right, but lets talk about you last statement. your experience is
> more
> great than my - so maybe underline your statement!
>
> 2. as i asked in another mail - all talk about ejb 3.0 and the jpa is
> built
> upon ejb 3.0.
> so if already use ejb 3.0 for persistence or jpa - whats your opinion
> about
> mix or share business code in the shale model objects and in
> stateful/stateless ejbs.
Just to clarify terminology a bit ... "jpa is built upon ejb 3.0" is not
technically correct. The JPA specification was built by the same group that
did the EJB3 specification, but the technologies are independent of each
other. Informally, you can think of JPA as being the replacement for
entity beans in EJB 2.1, while EJB3 contains just session beans (stateless
and stateful) and message driven beans.
Given that, there are really four general approaches to the business logic
of a JSF based application (and they apply pretty much the same with or
without Shale).
* Embed the business logic in the event handlers
(roughly corresponding to embedding business
logic in an Action.execute() method in Struts.
* Use standard JavaBeans for the JSF backing beans,
and put the business in other pure JavaBeans.
* Use standard JavaBeans for the JSF backing beans,
and put the business logic into an EJB session bean
(most likely using annotations to inject this)
* Dispense with using a standard JavaBean, and make
the EJB session bean be *both* the backing bean
and the business logic (this is the approach that
JBoss Seam uses, for example).
I think we'll see all four approaches get used. The first will tend to get
used by programmers not as familiar with O-O techniques, or in cases where
you're primarily interested in rapid development (such as a prototype). The
second and third approaches will be a natural choice if you already have
your business logic encapsulated -- for instance, the second method works
great if you're already using Spring for instantiating your business logic
beans. The third (EJB session beans) is nice if you need the transactional
behavior or statefulness you can get with EJBs without the extra setup it
takes to get that out of Spring.
The fourth approach (Seam) sounds a bit odd, but it's really pretty much
equivalent to the first. Besides being useful in the cases described there,
it can make sense when the "business logic" you are talking about is so tied
to the particular application you are doing that you'd get no reuse benefit
out of abstracting it into a separate class. The fourth approach (compared
to the first) gives you transactionality and statefulness if you need them.
Which is best? There's no one right answer. It's going to get driven a lot
by your particular application use cases, whether you have previously
abstracted your business logic (versus you have to write it from scratch),
and your own preferences for object oriented development and splitting this
kind of stuff.
3. what do you think about the basic approaches of shale and struts - i know
> you leaded both - so would you built an framework like struts again, with
> the knowledge of what shale can perform.
If I still liked the Struts approach, I wouldn't have built Shale in the
first place :-).
If you like an action oriented framework, Struts 2.x is going to be
*substantially* better than Struts 1.x. However, IMHO, both of them present
you with lots of power, but require you to understand more complexity than
you should really need to understand, for the 80% of applications that don't
need that kind of power.
The simplicity that comes with being able to handle all the interesting
server side events for a particular page, in a single Java class, is pretty
compelling. (You can accomplish this with Struts 2.x with some
sophisticated configuration; for Struts 1.x you can't really accomplish this
gracefully for all the use cases that Shale supports).
4. is shale an addon to jsf or the next jsf? ;-) and how will be handled
> overlaps between shale and jsf 1.2 (i think for @PostConstruct in
> comparing
> to shale livecycle) - because you told shale is independent for all jsf ri
> and you will test with 1.2 which is part of java ee from 11.05.06
The contents of "the next JSF" is totally up to the next JSF expert group,
and what they elect to include. There are certainly some ideas from Shale
that I would like to see put in the standard, but what actually happens
remains to be seen.
In the mean time, anyone who elects to depend on Shale is going to *expect*
Shale to continue to support its own annotations, even if they are (in some
sense) superceded by standard ones. And that is a perfectly feasible thing
to continue doing.
In the particular case of @PostConstruct and @PreDestroy, that's something
Shale might look at optionally supporting for the case where you're using
JDK 1.5 to compile your app, but you're running it on a J2EE 1.4 level
server that doesn't support them natively.
thx
Craig
2006/9/18, Craig McClanahan <cr...@apache.org>:
> >
> > On 9/18/06, numpsy beelzebub <nu...@gmail.com> wrote:
> > >
> > > thx.
> > >
> > > but whats in your opinion the most used / important / generally
> > functions,
> > > that used in modell objects:
> > > i suppose
> > > 1. the facesmessage - maybe generating some fault or info message
> stuff
> > > 2. getbean - maybe get access to managed beans - change them etc
> > > 3. getParameter - to looks for requested values
> > >
> > > but what else?
> >
> >
> > To me, trying to pick the most important *methods* is a little bit too
> > fine
> > grained to be useful, because different applications have widely varying
> > needs. Instead, I would tend to focus first on the architectural
> patterns
> > that a particular framework enables, and then see if that matches up to
> > your
> > application requirements.
> >
> > In the case of Shale, I would suggest looking at the
> > "shale-mailreader-jpa"
> > example application. Functionally, it is the same as the good old
> Struts
> > example app that has been around for almost six years now. But, this
> > implementation uses JavaServer Faces and Shale for the view tier, and
> Java
> > Persistence Architecture (JPA) for the model tier (although you could
> > easily
> > substitute Hibernate). It encompasses the kinds of patterns that I
> would
> > recommend for building new apps today.
> >
> > Craig
> >
> >
> > :-)
> > >
> > >
> > >
> > > 2006/9/18, Craig McClanahan <cr...@apache.org>:
> > > >
> > > > On 9/18/06, numpsy beelzebub <nu...@gmail.com> wrote:
> > > > > thx,
> > > > >
> > > > > once more i wnat to know what are the most important / generally
> > > > functions
> > > > > in shale, that used in modell objects:
> > > > > 1. the facesmessage - maybe generating some stuff
> > > > > 2. getbean - maybe get acces to managed beans - change them etc
> > > > > ...
> > > > > ...
> > > > >
> > > > > shale is a framework built on the base to have features, which can
> > be
> > > > > replaced and als which don't have to used - in fact a user if he
> is
> > > only
> > > > a
> > > > > jsf fan he don't use shale features - but he can...
> > > > > clay is genial... and other parts too - so on should
> > > > >
> > > > > would it possible to use mybe shale clay on every other jsf
> > framework
> > > or
> > > > > references it to myfaces sources?
> > > >
> > > > The shale-clay library itself depends on shale-core, but that does
> not
> > > > mean your application needs to use any other Shale features if you
> do
> > > > not wish to. There is no reason to reference sources from the
> MyFaces
> > > > JSF implementation (or the reference implementation), because Shale
> > > > utilizes only the standard extension APIs that JSF provides.
> > > >
> > > > Craig
> > > >
> > > > >
> > > > > what more...
> > > > >
> > > > > stephan
> > > > >
> > > > >
> > > > > 2006/9/18, Craig McClanahan <cr...@apache.org>:
> > > > > >
> > > > > > On 9/17/06, numpsy beelzebub <nu...@gmail.com> wrote:
> > > > > > >
> > > > > > > with getbean method i have the possibility to access managed
> > > beans
> > > > > > >
> > > > > > > where is this feature from... is see therefore bean has to
> > extends
> > > > to
> > > > > > > AbstractViewController or AbstractApplicationController
> > > > > > >
> > > > > > > i never used jsf but was this a feature in the past...
> > > > > >
> > > > > >
> > > > > > If you look at the source code for AbstractViewController
> itself,
> > > you
> > > > will
> > > > > > see that it extends AbstractFaceBean, which in turn contains the
> > > > defiition
> > > > > > for getBean(). Then, if you look at that method, you will see
> > that
> > > it
> > > > > > simply uses standard features of the JavaServer Faces API that
> let
> > > you
> > > > > > interact with the standard JSF "Variable Resolver" -- the part
> of
> > > JSF
> > > > that
> > > > > > actually implements managed beans:
> > > > > >
> > > > > > protected Object getBean(String name) {
> > > > > > FacesContext context = getFacesContext(); //
> > > > > > FacesContext.getCurrentInstance()
> > > > > > return context.getApplication().getVariableResolver().
> > > > > > resolveVariable(context, name);
> > > > > > }
> > > > > >
> > > > > > A similar convenience method lets you evaluate any value binding
> > > > > > expression
> > > > > > (such as "#{foo.bar}") from within an application, again using
> > > > standard
> > > > > > JSF
> > > > > > APIs:
> > > > > >
> > > > > > protected Object getValue(String expr) {
> > > > > > ValueBinding vb =
> > getApplication().createValueBinding(expr);
> > > > > > return vb.getValue(getFacesContext());
> > > > > > }
> > > > > >
> > > > > > i "googled" and found a relationalship to spring - so i looked
> on
> > > > apache
> > > > > > > shale web site (spring integration)
> > > > > > >
> > > > > > > is this feature from spring integration?
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > No, this particular feature was inspired by similar features in
> > the
> > > > > > application model that Sun Java Studio Creator uses for the
> > > > applications
> > > > > > it
> > > > > > builds. The part of Shale most directly influenced by Spring is
> > the
> > > > > > DIalog
> > > > > > feature, which has conceptual similarities to Spring Web Flow --
> > in
> > > > > > particular, the idea of modelling a dialog as a state machine
> with
> > > > action
> > > > > > states and view states (among others).
> > > > > >
> > > > > > Craig
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > >
> > >
> >
> >
>
>
Re: getbean method question
Posted by numpsy beelzebub <nu...@gmail.com>.
my questions for used / important / generally functions has as context the
see on the architecture!
i'm excited "fan" of clay and its features given to developer - and shale
other features. so the presentation part of application is clear.
but the business logic is the fact...
i mean especially the gap between ejb 3.0 and shale models
>It encompasses the kinds of patterns that I would
>recommend for building new apps today.
1. i followed your thinking about the example an the port from struts and
thats right, but lets talk about you last statement. your experience is more
great than my - so maybe underline your statement!
2. as i asked in another mail - all talk about ejb 3.0 and the jpa is built
upon ejb 3.0.
so if already use ejb 3.0 for persistence or jpa - whats your opinion about
mix or share business code in the shale model objects and in
stateful/stateless ejbs.
3. what do you think about the basic approaches of shale and struts - i know
you leaded both - so would you built an framework like struts again, with
the knowledge of what shale can perform.
4. is shale an addon to jsf or the next jsf? ;-) and how will be handled
overlaps between shale and jsf 1.2 (i think for @PostConstruct in comparing
to shale livecycle) - because you told shale is independent for all jsf ri
and you will test with 1.2 which is part of java ee from 11.05.06
thx
2006/9/18, Craig McClanahan <cr...@apache.org>:
>
> On 9/18/06, numpsy beelzebub <nu...@gmail.com> wrote:
> >
> > thx.
> >
> > but whats in your opinion the most used / important / generally
> functions,
> > that used in modell objects:
> > i suppose
> > 1. the facesmessage - maybe generating some fault or info message stuff
> > 2. getbean - maybe get access to managed beans - change them etc
> > 3. getParameter - to looks for requested values
> >
> > but what else?
>
>
> To me, trying to pick the most important *methods* is a little bit too
> fine
> grained to be useful, because different applications have widely varying
> needs. Instead, I would tend to focus first on the architectural patterns
> that a particular framework enables, and then see if that matches up to
> your
> application requirements.
>
> In the case of Shale, I would suggest looking at the
> "shale-mailreader-jpa"
> example application. Functionally, it is the same as the good old Struts
> example app that has been around for almost six years now. But, this
> implementation uses JavaServer Faces and Shale for the view tier, and Java
> Persistence Architecture (JPA) for the model tier (although you could
> easily
> substitute Hibernate). It encompasses the kinds of patterns that I would
> recommend for building new apps today.
>
> Craig
>
>
> :-)
> >
> >
> >
> > 2006/9/18, Craig McClanahan <cr...@apache.org>:
> > >
> > > On 9/18/06, numpsy beelzebub <nu...@gmail.com> wrote:
> > > > thx,
> > > >
> > > > once more i wnat to know what are the most important / generally
> > > functions
> > > > in shale, that used in modell objects:
> > > > 1. the facesmessage - maybe generating some stuff
> > > > 2. getbean - maybe get acces to managed beans - change them etc
> > > > ...
> > > > ...
> > > >
> > > > shale is a framework built on the base to have features, which can
> be
> > > > replaced and als which don't have to used - in fact a user if he is
> > only
> > > a
> > > > jsf fan he don't use shale features - but he can...
> > > > clay is genial... and other parts too - so on should
> > > >
> > > > would it possible to use mybe shale clay on every other jsf
> framework
> > or
> > > > references it to myfaces sources?
> > >
> > > The shale-clay library itself depends on shale-core, but that does not
> > > mean your application needs to use any other Shale features if you do
> > > not wish to. There is no reason to reference sources from the MyFaces
> > > JSF implementation (or the reference implementation), because Shale
> > > utilizes only the standard extension APIs that JSF provides.
> > >
> > > Craig
> > >
> > > >
> > > > what more...
> > > >
> > > > stephan
> > > >
> > > >
> > > > 2006/9/18, Craig McClanahan <cr...@apache.org>:
> > > > >
> > > > > On 9/17/06, numpsy beelzebub <nu...@gmail.com> wrote:
> > > > > >
> > > > > > with getbean method i have the possibility to access managed
> > beans
> > > > > >
> > > > > > where is this feature from... is see therefore bean has to
> extends
> > > to
> > > > > > AbstractViewController or AbstractApplicationController
> > > > > >
> > > > > > i never used jsf but was this a feature in the past...
> > > > >
> > > > >
> > > > > If you look at the source code for AbstractViewController itself,
> > you
> > > will
> > > > > see that it extends AbstractFaceBean, which in turn contains the
> > > defiition
> > > > > for getBean(). Then, if you look at that method, you will see
> that
> > it
> > > > > simply uses standard features of the JavaServer Faces API that let
> > you
> > > > > interact with the standard JSF "Variable Resolver" -- the part of
> > JSF
> > > that
> > > > > actually implements managed beans:
> > > > >
> > > > > protected Object getBean(String name) {
> > > > > FacesContext context = getFacesContext(); //
> > > > > FacesContext.getCurrentInstance()
> > > > > return context.getApplication().getVariableResolver().
> > > > > resolveVariable(context, name);
> > > > > }
> > > > >
> > > > > A similar convenience method lets you evaluate any value binding
> > > > > expression
> > > > > (such as "#{foo.bar}") from within an application, again using
> > > standard
> > > > > JSF
> > > > > APIs:
> > > > >
> > > > > protected Object getValue(String expr) {
> > > > > ValueBinding vb =
> getApplication().createValueBinding(expr);
> > > > > return vb.getValue(getFacesContext());
> > > > > }
> > > > >
> > > > > i "googled" and found a relationalship to spring - so i looked on
> > > apache
> > > > > > shale web site (spring integration)
> > > > > >
> > > > > > is this feature from spring integration?
> > > > > >
> > > > > >
> > > > >
> > > > > No, this particular feature was inspired by similar features in
> the
> > > > > application model that Sun Java Studio Creator uses for the
> > > applications
> > > > > it
> > > > > builds. The part of Shale most directly influenced by Spring is
> the
> > > > > DIalog
> > > > > feature, which has conceptual similarities to Spring Web Flow --
> in
> > > > > particular, the idea of modelling a dialog as a state machine with
> > > action
> > > > > states and view states (among others).
> > > > >
> > > > > Craig
> > > > >
> > > > >
> > > >
> > > >
> > >
> >
> >
>
>
Re: getbean method question
Posted by Craig McClanahan <cr...@apache.org>.
On 9/18/06, numpsy beelzebub <nu...@gmail.com> wrote:
>
> thx.
>
> but whats in your opinion the most used / important / generally functions,
> that used in modell objects:
> i suppose
> 1. the facesmessage - maybe generating some fault or info message stuff
> 2. getbean - maybe get access to managed beans - change them etc
> 3. getParameter - to looks for requested values
>
> but what else?
To me, trying to pick the most important *methods* is a little bit too fine
grained to be useful, because different applications have widely varying
needs. Instead, I would tend to focus first on the architectural patterns
that a particular framework enables, and then see if that matches up to your
application requirements.
In the case of Shale, I would suggest looking at the "shale-mailreader-jpa"
example application. Functionally, it is the same as the good old Struts
example app that has been around for almost six years now. But, this
implementation uses JavaServer Faces and Shale for the view tier, and Java
Persistence Architecture (JPA) for the model tier (although you could easily
substitute Hibernate). It encompasses the kinds of patterns that I would
recommend for building new apps today.
Craig
:-)
>
>
>
> 2006/9/18, Craig McClanahan <cr...@apache.org>:
> >
> > On 9/18/06, numpsy beelzebub <nu...@gmail.com> wrote:
> > > thx,
> > >
> > > once more i wnat to know what are the most important / generally
> > functions
> > > in shale, that used in modell objects:
> > > 1. the facesmessage - maybe generating some stuff
> > > 2. getbean - maybe get acces to managed beans - change them etc
> > > ...
> > > ...
> > >
> > > shale is a framework built on the base to have features, which can be
> > > replaced and als which don't have to used - in fact a user if he is
> only
> > a
> > > jsf fan he don't use shale features - but he can...
> > > clay is genial... and other parts too - so on should
> > >
> > > would it possible to use mybe shale clay on every other jsf framework
> or
> > > references it to myfaces sources?
> >
> > The shale-clay library itself depends on shale-core, but that does not
> > mean your application needs to use any other Shale features if you do
> > not wish to. There is no reason to reference sources from the MyFaces
> > JSF implementation (or the reference implementation), because Shale
> > utilizes only the standard extension APIs that JSF provides.
> >
> > Craig
> >
> > >
> > > what more...
> > >
> > > stephan
> > >
> > >
> > > 2006/9/18, Craig McClanahan <cr...@apache.org>:
> > > >
> > > > On 9/17/06, numpsy beelzebub <nu...@gmail.com> wrote:
> > > > >
> > > > > with getbean method i have the possibility to access managed
> beans
> > > > >
> > > > > where is this feature from... is see therefore bean has to extends
> > to
> > > > > AbstractViewController or AbstractApplicationController
> > > > >
> > > > > i never used jsf but was this a feature in the past...
> > > >
> > > >
> > > > If you look at the source code for AbstractViewController itself,
> you
> > will
> > > > see that it extends AbstractFaceBean, which in turn contains the
> > defiition
> > > > for getBean(). Then, if you look at that method, you will see that
> it
> > > > simply uses standard features of the JavaServer Faces API that let
> you
> > > > interact with the standard JSF "Variable Resolver" -- the part of
> JSF
> > that
> > > > actually implements managed beans:
> > > >
> > > > protected Object getBean(String name) {
> > > > FacesContext context = getFacesContext(); //
> > > > FacesContext.getCurrentInstance()
> > > > return context.getApplication().getVariableResolver().
> > > > resolveVariable(context, name);
> > > > }
> > > >
> > > > A similar convenience method lets you evaluate any value binding
> > > > expression
> > > > (such as "#{foo.bar}") from within an application, again using
> > standard
> > > > JSF
> > > > APIs:
> > > >
> > > > protected Object getValue(String expr) {
> > > > ValueBinding vb = getApplication().createValueBinding(expr);
> > > > return vb.getValue(getFacesContext());
> > > > }
> > > >
> > > > i "googled" and found a relationalship to spring - so i looked on
> > apache
> > > > > shale web site (spring integration)
> > > > >
> > > > > is this feature from spring integration?
> > > > >
> > > > >
> > > >
> > > > No, this particular feature was inspired by similar features in the
> > > > application model that Sun Java Studio Creator uses for the
> > applications
> > > > it
> > > > builds. The part of Shale most directly influenced by Spring is the
> > > > DIalog
> > > > feature, which has conceptual similarities to Spring Web Flow -- in
> > > > particular, the idea of modelling a dialog as a state machine with
> > action
> > > > states and view states (among others).
> > > >
> > > > Craig
> > > >
> > > >
> > >
> > >
> >
>
>
Re: getbean method question
Posted by numpsy beelzebub <nu...@gmail.com>.
thx.
but whats in your opinion the most used / important / generally functions,
that used in modell objects:
i suppose
1. the facesmessage - maybe generating some fault or info message stuff
2. getbean - maybe get access to managed beans - change them etc
3. getParameter - to looks for requested values
but what else?
:-)
2006/9/18, Craig McClanahan <cr...@apache.org>:
>
> On 9/18/06, numpsy beelzebub <nu...@gmail.com> wrote:
> > thx,
> >
> > once more i wnat to know what are the most important / generally
> functions
> > in shale, that used in modell objects:
> > 1. the facesmessage - maybe generating some stuff
> > 2. getbean - maybe get acces to managed beans - change them etc
> > ...
> > ...
> >
> > shale is a framework built on the base to have features, which can be
> > replaced and als which don't have to used - in fact a user if he is only
> a
> > jsf fan he don't use shale features - but he can...
> > clay is genial... and other parts too - so on should
> >
> > would it possible to use mybe shale clay on every other jsf framework or
> > references it to myfaces sources?
>
> The shale-clay library itself depends on shale-core, but that does not
> mean your application needs to use any other Shale features if you do
> not wish to. There is no reason to reference sources from the MyFaces
> JSF implementation (or the reference implementation), because Shale
> utilizes only the standard extension APIs that JSF provides.
>
> Craig
>
> >
> > what more...
> >
> > stephan
> >
> >
> > 2006/9/18, Craig McClanahan <cr...@apache.org>:
> > >
> > > On 9/17/06, numpsy beelzebub <nu...@gmail.com> wrote:
> > > >
> > > > with getbean method i have the possibility to access managed beans
> > > >
> > > > where is this feature from... is see therefore bean has to extends
> to
> > > > AbstractViewController or AbstractApplicationController
> > > >
> > > > i never used jsf but was this a feature in the past...
> > >
> > >
> > > If you look at the source code for AbstractViewController itself, you
> will
> > > see that it extends AbstractFaceBean, which in turn contains the
> defiition
> > > for getBean(). Then, if you look at that method, you will see that it
> > > simply uses standard features of the JavaServer Faces API that let you
> > > interact with the standard JSF "Variable Resolver" -- the part of JSF
> that
> > > actually implements managed beans:
> > >
> > > protected Object getBean(String name) {
> > > FacesContext context = getFacesContext(); //
> > > FacesContext.getCurrentInstance()
> > > return context.getApplication().getVariableResolver().
> > > resolveVariable(context, name);
> > > }
> > >
> > > A similar convenience method lets you evaluate any value binding
> > > expression
> > > (such as "#{foo.bar}") from within an application, again using
> standard
> > > JSF
> > > APIs:
> > >
> > > protected Object getValue(String expr) {
> > > ValueBinding vb = getApplication().createValueBinding(expr);
> > > return vb.getValue(getFacesContext());
> > > }
> > >
> > > i "googled" and found a relationalship to spring - so i looked on
> apache
> > > > shale web site (spring integration)
> > > >
> > > > is this feature from spring integration?
> > > >
> > > >
> > >
> > > No, this particular feature was inspired by similar features in the
> > > application model that Sun Java Studio Creator uses for the
> applications
> > > it
> > > builds. The part of Shale most directly influenced by Spring is the
> > > DIalog
> > > feature, which has conceptual similarities to Spring Web Flow -- in
> > > particular, the idea of modelling a dialog as a state machine with
> action
> > > states and view states (among others).
> > >
> > > Craig
> > >
> > >
> >
> >
>
Re: getbean method question
Posted by Craig McClanahan <cr...@apache.org>.
On 9/18/06, numpsy beelzebub <nu...@gmail.com> wrote:
> thx,
>
> once more i wnat to know what are the most important / generally functions
> in shale, that used in modell objects:
> 1. the facesmessage - maybe generating some stuff
> 2. getbean - maybe get acces to managed beans - change them etc
> ...
> ...
>
> shale is a framework built on the base to have features, which can be
> replaced and als which don't have to used - in fact a user if he is only a
> jsf fan he don't use shale features - but he can...
> clay is genial... and other parts too - so on should
>
> would it possible to use mybe shale clay on every other jsf framework or
> references it to myfaces sources?
The shale-clay library itself depends on shale-core, but that does not
mean your application needs to use any other Shale features if you do
not wish to. There is no reason to reference sources from the MyFaces
JSF implementation (or the reference implementation), because Shale
utilizes only the standard extension APIs that JSF provides.
Craig
>
> what more...
>
> stephan
>
>
> 2006/9/18, Craig McClanahan <cr...@apache.org>:
> >
> > On 9/17/06, numpsy beelzebub <nu...@gmail.com> wrote:
> > >
> > > with getbean method i have the possibility to access managed beans
> > >
> > > where is this feature from... is see therefore bean has to extends to
> > > AbstractViewController or AbstractApplicationController
> > >
> > > i never used jsf but was this a feature in the past...
> >
> >
> > If you look at the source code for AbstractViewController itself, you will
> > see that it extends AbstractFaceBean, which in turn contains the defiition
> > for getBean(). Then, if you look at that method, you will see that it
> > simply uses standard features of the JavaServer Faces API that let you
> > interact with the standard JSF "Variable Resolver" -- the part of JSF that
> > actually implements managed beans:
> >
> > protected Object getBean(String name) {
> > FacesContext context = getFacesContext(); //
> > FacesContext.getCurrentInstance()
> > return context.getApplication().getVariableResolver().
> > resolveVariable(context, name);
> > }
> >
> > A similar convenience method lets you evaluate any value binding
> > expression
> > (such as "#{foo.bar}") from within an application, again using standard
> > JSF
> > APIs:
> >
> > protected Object getValue(String expr) {
> > ValueBinding vb = getApplication().createValueBinding(expr);
> > return vb.getValue(getFacesContext());
> > }
> >
> > i "googled" and found a relationalship to spring - so i looked on apache
> > > shale web site (spring integration)
> > >
> > > is this feature from spring integration?
> > >
> > >
> >
> > No, this particular feature was inspired by similar features in the
> > application model that Sun Java Studio Creator uses for the applications
> > it
> > builds. The part of Shale most directly influenced by Spring is the
> > DIalog
> > feature, which has conceptual similarities to Spring Web Flow -- in
> > particular, the idea of modelling a dialog as a state machine with action
> > states and view states (among others).
> >
> > Craig
> >
> >
>
>
Re: getbean method question
Posted by numpsy beelzebub <nu...@gmail.com>.
thx,
once more i wnat to know what are the most important / generally functions
in shale, that used in modell objects:
1. the facesmessage - maybe generating some stuff
2. getbean - maybe get acces to managed beans - change them etc
...
...
shale is a framework built on the base to have features, which can be
replaced and als which don't have to used - in fact a user if he is only a
jsf fan he don't use shale features - but he can...
clay is genial... and other parts too - so on should
would it possible to use mybe shale clay on every other jsf framework or
references it to myfaces sources?
what more...
stephan
2006/9/18, Craig McClanahan <cr...@apache.org>:
>
> On 9/17/06, numpsy beelzebub <nu...@gmail.com> wrote:
> >
> > with getbean method i have the possibility to access managed beans
> >
> > where is this feature from... is see therefore bean has to extends to
> > AbstractViewController or AbstractApplicationController
> >
> > i never used jsf but was this a feature in the past...
>
>
> If you look at the source code for AbstractViewController itself, you will
> see that it extends AbstractFaceBean, which in turn contains the defiition
> for getBean(). Then, if you look at that method, you will see that it
> simply uses standard features of the JavaServer Faces API that let you
> interact with the standard JSF "Variable Resolver" -- the part of JSF that
> actually implements managed beans:
>
> protected Object getBean(String name) {
> FacesContext context = getFacesContext(); //
> FacesContext.getCurrentInstance()
> return context.getApplication().getVariableResolver().
> resolveVariable(context, name);
> }
>
> A similar convenience method lets you evaluate any value binding
> expression
> (such as "#{foo.bar}") from within an application, again using standard
> JSF
> APIs:
>
> protected Object getValue(String expr) {
> ValueBinding vb = getApplication().createValueBinding(expr);
> return vb.getValue(getFacesContext());
> }
>
> i "googled" and found a relationalship to spring - so i looked on apache
> > shale web site (spring integration)
> >
> > is this feature from spring integration?
> >
> >
>
> No, this particular feature was inspired by similar features in the
> application model that Sun Java Studio Creator uses for the applications
> it
> builds. The part of Shale most directly influenced by Spring is the
> DIalog
> feature, which has conceptual similarities to Spring Web Flow -- in
> particular, the idea of modelling a dialog as a state machine with action
> states and view states (among others).
>
> Craig
>
>
Re: getbean method question
Posted by Craig McClanahan <cr...@apache.org>.
On 9/17/06, numpsy beelzebub <nu...@gmail.com> wrote:
>
> with getbean method i have the possibility to access managed beans
>
> where is this feature from... is see therefore bean has to extends to
> AbstractViewController or AbstractApplicationController
>
> i never used jsf but was this a feature in the past...
If you look at the source code for AbstractViewController itself, you will
see that it extends AbstractFaceBean, which in turn contains the defiition
for getBean(). Then, if you look at that method, you will see that it
simply uses standard features of the JavaServer Faces API that let you
interact with the standard JSF "Variable Resolver" -- the part of JSF that
actually implements managed beans:
protected Object getBean(String name) {
FacesContext context = getFacesContext(); //
FacesContext.getCurrentInstance()
return context.getApplication().getVariableResolver().
resolveVariable(context, name);
}
A similar convenience method lets you evaluate any value binding expression
(such as "#{foo.bar}") from within an application, again using standard JSF
APIs:
protected Object getValue(String expr) {
ValueBinding vb = getApplication().createValueBinding(expr);
return vb.getValue(getFacesContext());
}
i "googled" and found a relationalship to spring - so i looked on apache
> shale web site (spring integration)
>
> is this feature from spring integration?
>
>
No, this particular feature was inspired by similar features in the
application model that Sun Java Studio Creator uses for the applications it
builds. The part of Shale most directly influenced by Spring is the DIalog
feature, which has conceptual similarities to Spring Web Flow -- in
particular, the idea of modelling a dialog as a state machine with action
states and view states (among others).
Craig