After looking at the various projects for delivering dynamic content over
the Web, I set out to develop my own MVC/Model 2-based dynamic content
engine. Well, after a few months of part time work and refactoring the
design, the engine is working.
The architecture is similar in concept to Struts, so it seemed logical to me
to make the system compatible with struts. Looking at the architecture, I
don't envision any issues in adding a Struts compatibility layer to my
engine. In fact, it looks like I'll only have to build 3 adapter classes to
get the code in a compatible state--to wrap the model, view, and controller
beans of struts to be compatible with my own. I also plan to write an XSL
file for converting Struts configuration files to those for my own engine.
Of course, when this functionality is complete, I I can also get some
realistic comparisons in terms of performance, as well.
You may be wondering where I'm taking this. Well, looking at the to-do list
for Struts, I see a couple of areas that I have already completed.
Additionally, there are a couple of things mine does that Struts does not
even attempt.
Struts To-Do Items:
1) ActionForms with dynamic properties. If I understand what is required
here, I believe my engine already has this functionality.
2) Workflow processing. My system supports workflow processing, where
multiple actions (or the equivalent in my architecture) can be chained
together, with workflows specified by the result of the previous action.
3) Role-based action execution. The controller can be configured to execute
separate workflows depending upon system state. System state can be user
roles, IP addresses, or any other item that is set on the session.
Additional Features:
a) Workflows can be attached to "realms" rather than individual URL
requests. This allows the view to be a template .jsp file, with the content
being set depending upon the incoming request. This template functionality
does not require the use of a proprietary templating language, simplifying
template creation considerably beyond that of Velocity.
b) Dynamic page caching. Using the workflow concept, dynamic pages can
generate HTML & saved to disk. Depending upon the cache settings, future
requests can be simply forwarded to the static HTML pages, improving
performance considerably.
c) Dynamic content caching. Dynamic content can be cached for rapid
inclusion in a template JSP. This provides the ability to create
Jetspeed-like functionality for news portal content. I intend to build
Model classes that retrieve dynamic RSS-based content. This content can
then be wrapped by a caching object. The resulting content can be included
into a template, as mentioned in a).
Now, I feel that I have something significant here. I'm strongly
considering releasing it open source, and was wondering what the Struts
developers' reaction would be to it. In particular, I'd like to incorporate
the concepts, if not the code, into the Struts code base.
Assuming I can make the controller completely compatible with the Struts
controller, it would seem logical that my controller code live side-by-side
(in a contrib directory, no doubt) with the Struts controller. Over time,
functionality can be moved over between the two, creating a hybrid of
sorts--taking the best from each. Any opinions on this?
Strong attention would be paid at making my portal reverse-compatible with
Struts actions, allowing developers to utilize existing beans designed for
Struts with a different controller. The tag libraries, too, will remain
100% compatible with this controller.
If interest is sufficient, I can also outline a sample configuration file
for this controller, which should provide more information about how I think
the two can work together. I just want to get a little developer reaction
before I put my head on the chopping block.
Thanks for your time. I look forward to reading your feedback on this.
-dan
--
Dan Kirkpatrick, Software Architect
Blue Lotus Software +44 (0) 1224 575 985
[EMAIL PROTECTED]
http://www.bluelotussoftware.com
