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 <[EMAIL PROTECTED]>:

On 9/18/06, numpsy beelzebub <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>:
> >
> > On 9/18/06, numpsy beelzebub <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>:
> > > >
> > > > On 9/17/06, numpsy beelzebub <[EMAIL PROTECTED]> 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
> > > >
> > > >
> > >
> > >
> >
>
>


Reply via email to