On Sat, 12 Mar 2005 16:11:04 +0100, Matthias Wessendorf
<[EMAIL PROTECTED]> wrote:
> Hi,
>
> I am just starting to play with Shale framework by
> building some simple JSF/Shale web apps.
>
> The ViewController interfaces is very nice and the its default
> implemention (both in *core* framework) also!
The primary reason for a default implementation in the core framework
is to protect users from evolution of the interface (for example,
adding new methods later would normally break all implementations of
that interface). For those that subclass the default implementation,
we can provide default behaviors that mirror the previous version, and
make maintaining backwards compatibility easier.
You see this kind of thing a lot in JavaBeans event related designs
... an interface describing the available events, and an "adapter"
class that provides default implementations. If you extend the
latter, you gain the benefit of only overriding methods where you want
something non-default, but also protection from future changes in the
interface.
>
> I looked at BaseViewController that is super clazz for all backing
> beans inside the usecases app. However, I think the getBean(String name)
> and its getFacesContext() from BaseViewController are very useful generell.
>
> So why are that not included into the interface?
> Any idea?
>
There are several reasons for this.
One of the knocks against a framework like Struts 1.x is that it is
relatively difficult to construct unit tests for an Action, because
you have to set up a tremendous amount of infrastructure to make it
work. I want ViewController implementations to have the simplest
possible interface, to minimize the amount of setup work you need to
do for these things. (The importance of this argument is lessened
because Shale has a test framework available as well, with all the
gory details taken care of, but the principle still applies).
Another reason relates to the Hollywood Principle ("don't call us,
we'll call you") that is the basis for most IoC container designs
today. Thinking of the ViewController methods as callbacks means you
are focused on responding to events that are occurring, where the
underlying framework takes responsibility of notifying you when
something interesting happens. Utility methods like getBean() and
getFacesContext() are things that the ViewController implementation
itself would call, rather than things the framework would call, so
they don't seem to mix very well.
Finally, it is definitely feasible to implement a ViewController that
doesn't require access to these methods. Why should *every*
implementation be forced to implement them, even if they are not going
to be used? On the other hand, if you need them, just subclass the
default implementation.
> Thanks,
> Matthias
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
