Can you base a web framework on another web framework?
It looks like the Struts guys are going to base Struts 2.0 on JSF (detailed proposal, wiki). It should be interesting to see a web framework developed on top of another web framework. Of course, it's been done before. The two things I really like in this proposal are 1) a built-in IoC container and 2) the security stuff (remember me, user registration). Here's the details from the proposal:
3.5 Service Provisioning APIs
Inversion of Control (IoC) containers (the techniques are also referred
to as Dependency Injection) are becoming a popular mechanism for assembling
the required services and logic of an application. If Struts included such
a framework, it would provide a solid basis for building maintainable apps,
as well as allowing the framework to configure itself using the same
capabilities.
Rather than building such a container ourselves, we should seek to
incorporate an existing one that is license-compatible and which can
be integrated into the JSF managed beans facilities (so that value binding
and method binding expressions can leverage the facilities of this
container transparently). From my research so far, I like Spring's
capabilities in this area the best, but am open to other suggestions.
3.6 Authentication and Authorization APIs
In order to support reasonably complete solutions for applications that
wish to provide their own authentication and authorization services (as well
as interact with container managed security), we need APIs available for
performing user registration, implementing "remember me" features, and
represent the results via a wrapped request (so that apps depending on
getRemoteUser(), getUserPrincipal(), and isUserInRole() will still work).
Using JDK 1.4 as a base platform would allow us to integrate mechanisms
like JAAS. Other alternatives include plugins like SecurityFilter.
I added the emphsis on Spring. I'm all for this because 1) I'm on the JSF Expert Group (as of last week) and 2) it'd be nice to see JSF stretched, poked and prodded. IMO, JSF needs more "real-world" usage and the popularity of Struts will give it that. By "real-world" usage - I mean it needs to be used by developers that aren't cooped up in some cube with a fancy IDE. I also like the proposal because there's tons of Struts apps out there - and many of them might want to "upgrade". This means more (potential) work for me. Of course, I also plan on spending more time with Tapestry so I can offer client's an "educated" suggestion. BTW, the reason I joined the JSF EG is to be the "developer's voice" among the IDE Vendors. So if you'd like your voice to be heard - send me your suggestions, I'm all ears.
The question is - when will Shale be released? Of course, since it's open-source, the answer is "when it's ready". My guess is 1 year from today. I'm thinking of making AppFuse 2.0 use this new stuff. Of course, it'll have Tapestry and JSF options long before that.
If nothing else, the Shale proposal should motivate other web framework developers to highlight their roadmaps and what's new and cool on their horizons.
Posted by Keith on November 08, 2004 at 10:32 AM MST #
.V
ps: Somone said that your framework extension may not be thread safe since there are properties in action, just fyi.
Posted by Vic on November 08, 2004 at 12:26 PM MST #
Posted by Matt Raible on November 08, 2004 at 01:10 PM MST #
Posted by Howard Lewis Ship on November 08, 2004 at 01:52 PM MST #
nnooooooooo! firstly, they need to drop actions completely (look at crazy bob's delegate for a better approach) and then change the form loading mechanism so that *any* IoC container can be used. Including another framework within a framework is the second worst design decision CM has made (The first is splitting forms and actions ;)). the biiggest mistake the webwork2 guys made was including xwork. i don't want to maintain 2 IoC frameworks, i'd ratther use the one i prefer (spring in my case).
Some day soon, someone will come up with the perfect marriage of request/response (like struts delegate & webwork1) & event handling (jsf, wicket), until then, we are stuck with a bunch of frameworks that only do small, focussed tasks well. If only I can't straigthen the idea in my head ;)
Posted by analogueboy on November 08, 2004 at 02:26 PM MST #
Posted by Michael Jouravlev on November 08, 2004 at 02:56 PM MST #
Posted by Jason Carreira on November 09, 2004 at 09:12 PM MST #
I did indeed speak with Howard about using HiveMind -- which is now legally viable because all that stuff has been dealt with. I'm sure HiveMind would work, but I confess to a preference for the fundamental bean lookup API that Spring allows:
<code>MyBean bean = (MyBean) beanFactory.get("foo");</code>
versus what HiveMind requires (and this is typical of most of the other IoC frameworks too):
<code>MyBean bean = (MyBean) registry.getService("foo", MyBean.class);</code>
It's somewhat an aesthetics issue, but why should I have to redundantly specify MyBean.class when I have to cast the result anyway?
Of course, an IoC services architecture isn't the only thing Spring has to offer either.
Posted by Craig McClanahan on November 10, 2004 at 11:55 PM MST #
Posted by David Hay on December 03, 2004 at 05:10 PM MST #
Posted by Matt Raible on December 03, 2004 at 06:42 PM MST #