I think I need to understand the problem a little better before I am
emphatic about my controller's capabilities for dynamic properties.
Basically, however, I have a "variable" interface...think of it as a model
class. I will build an adapter for Struts model action classes will adapt
the Struts classes to my variable interface. It should be fairly
straightforward.
The variable class receives the HTTP request object as its argument in its
doAction() method (the main method for the interface). State information
can be retrieved from the request object, so that the dynamic property can
be retrieved/created/whatever. The variable is then set as an attribute on
the request. The view (the .jsp page) can then retrieve the attribute to
use as it desires. The variable can also be set on the
application/session/request/page context, if desired. I think if this thing
is to go into production, I should actually create marker [GoF '95]
interfaces to indicate what type of variable it is. Then, perhaps the
portal configuration will be able to specify what variable type is allowed
for that particular HTTP request. I haven't done this part, yet, but that
seems to make sense to me.
In order to get template functionality, I have created the concept of
"realms" (similar to Tomcat's realms), where multiple URLs are mapped to a
single workflow. The configuration for the workflow looks like:
<realm>
<match>
<uri>/portal/</uri>
</match>
<attribute name="content">
<variable type="RequestURI">
<parameter type="Strip">/portal</parameter>
</variable>
<variable type="QueryString" />
</attribute>
<attribute name="menu">
<variable type="StaticVariable">/portal_content/menu.html</variable>
</attribute>
<forward>/portal_content/template.jsp</forward>
</realm>
The <match> rule simply matches all requests to "/portal/*" to this realm.
The attributes "content" and "menu" then get set. You'll notice "content"
is a compound attribute, with multiple variables. For this case, the
toString() method is called on each variable, concatenating the resulting
strings into a single String object, which is set on the attribute. You'll
see with the "RequestURI" variable, there is a parameter "Strip" that strips
off part of the string in the RequestURI. This is used to map whatever
content page the user requests, minus the string "/portal", for inclusion by
the resulting .jsp view page. The query string is appended to the end (the
RequestURI variable type does not include the query string).
Each variable type, indicated by the "type" attribute on <variable>, is
registered in an earlier part of the configuration, allowing developers to
create their own variable types. These variable types might, for instance,
retrieve values from a database or an EJB or something.
The match rule must have an <url> to match. It may also contain other match
rules. The match rules might, for instance, perform regular expression
pattern matching on the URL (I have a very simple URL matching on the <url>
parameter that is optimised for speed), or it might match things like the
remote user's IP address or state information in the
application/session/request/page contexts. Concrete implementations of the
Rule interface are registered in the same area as the variable types,
allowing developers to create their own configuration types..
For this particular realm, the workflow is completely brain-dead--it simply
forwards the request to "template.jsp". I could have tested, for instance,
a session variable on the request, forwarding the user to one of many
template .jsp pages. This would provide the ability for users to select
"themes" for websites, with each theme having a radically different
look-and-feel (I'm not just talking about changing colours and fonts--I mean
changing locations of menus and such).
One process that I've developed is a reconfigure process. This reads the
configuration file on-the-fly, reconfiguring the controller upon success.
This allows hot-reconfiguration of the controller.
At any rate, that's getting a little far from the topic of dynamic
properties. I'll discuss more about my workflow and things later.
Cheers!
-dan
-----Original Message-----
From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED].
org]On Behalf Of Niall Pemberton
Sent: Thursday, April 12, 2001 11:34 PM
To: [EMAIL PROTECTED]
Subject: RE: A struts-compatible controller
I am in the processing of customising Struts controller to do dynamic
properties and would like to hear how you handled this.
Niall
> -----Original Message-----
> From: Dan - Blue Lotus Software [mailto:[EMAIL PROTECTED]]
> Sent: 12 April 2001 17:51
> To: Jakarta Struts
> Subject: A struts-compatible controller
>
>
> 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
>
>
