Dan - Blue Lotus Software wrote:
>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.
Are you referencing a particular GoF design pattern or something they wrote
in general in the '95 book?
-- Stoehr
-----Original Message-----
From: Dan - Blue Lotus Software [mailto:[EMAIL PROTECTED]]
Sent: Friday, April 13, 2001 08:09 AM
To: [EMAIL PROTECTED]
Subject: RE: A struts-compatible controller
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
