I'll take a crack at some of these from my perspective.
On 7/10/06, stephan opitz <[EMAIL PROTECTED]> wrote:
shale was concipied as the next struts, but built on jsf (logic -> the
standard).
my questions:
1. why it was so long a underproject -> i see really less commons
(because built on jsf)
There was a hope on my part that the other Struts developers would see the
merit of that argument ... focusing on value adds instead of redundancies
would be more beneficial. That seems unlikely to happen, for at least a
couple of reasons (the model 2-ish stuff already exists in Struts and WW,
and removing it would be problematic for backwards compatibility; plus, the
Struts developers believe in the quality of their approach -- and I
certainly won't argue with them; Struts 2 is a very elegant approach to an
action oriented controller.
2. clay as view - model and controller (where is the direct
boarderline? - was more easier to see in struts)
Where the controller lives is one of the key differentiators for JSF as a
whole, not just Clay. JSF likes the idea of a "page controller" (pretty
much an implementation of the View Helper pattern) in addition to an
application level controller like action frameworks. The basic idea is that
you can easily combine *all* the UI event handling for a single view into a
single corresponding backing bean (with Shale, typically it's also a view
controller), instead of having to spread the functionality across multiple
interceptors, filters, or actions as you would in an action oriented
framework.
There are ways in JSF to decorate the standard invocation of an application
action, similar to building a custom XWork interceptor chain in WW2. Making
that easy is a future enhancement goal for Shale ... but in the mean time
you can do it yourself by replacing the default ActionListener.
3. as i reviewed clay -> it supports 2 really modes -> the jsf mode
and the tapestry (all other like xml are extras)
So, do you like it? What would you improve about it?
4. :-( there is no remoting docs on the side -> everyone talks about
ajax support
Yah, I know :-(. Documentation for this is high on my priority list.
5. the tiger support will be implemented in such a way
import org.apache.shale.tiger.managed.Bean;
import org.apache.shale.tiger.managed.Scope;
import org.apache.shale.tiger.managed.Value;
// Define a managed bean named "mybean" to be put in session scope
@Bean(name="mybean" scope=Scope.SESSION)
what are the really advantages of using tiger support?
There are two basic advantages:
* For those who dislike XML configuration files in general,
this means you don't have to configure managed beans
in a faces-config.xml file at all.
* For certain decisions that affect how you code your
managed beans, combining the configuration into the
source of the class reduces the chances for mismatch.
To me, the second is a lot more important than the first. In particular,
which scope a managed bean goes into affects things like whether you need to
worry about thread safety or not ... and this means you are coding to a
particular assumption about what scope your bean will be placed in. Hoping
that the application developer who is using your bean remembers to get this
right is no longer necessary.
Personally, I don't see annotation based configuration as the solution to
*all* problems. In a web app framework, in particular, I don't believe in
using annotations for configuring navigation -- that should be up to the
person assembling the app, not the person(s) writing the individual managed
beans. However, using @Bean to configure your managed beans can cut the
amount of XML configuration for a typical app in half, plus guarantee you
won't mess up on scoping. That's a pretty good deal.
6. what are the advantages of using the dialog manager -> couldn't it
also realized by using faces-config.xml?
You can deal with the general navigation issues that the Dialog Manager
deals with strictly using faces-config.xml, as long as you exercise care in
guaranteeing that all your outcomes are unique enough to be matched
correctly by navigation rules (in a big app, this can be pretty difficult to
verify). However, the other key problem that the Dialog Manager addresses
is what to do with state information that needs to last longer than a single
request, but shorter than an HTTP session. The typical answer is to just
stuff this kind of thing into the session, where it remains until the user
logs off. Far better would be to get rid of the state for a particular
conversation when that conversation has been completed -- and that's what
Dialog Manager does for you.
Fair warning, though ... there are currently some limitations in the dialog
functionality, and it's likely to be revised somewhat before a GA release of
Shale.
answers will be great to understand the whole relation
stephan
Craig
