Oops...I previously posted this using a misleading subject. This one should
give a better idea of what the post is about.
========
Hi. I have a couple of questions/suggestions for ye architects of Struts. I
haven't yet built anything with struts yet, but have been looking it over
and
following the dev list for a few months now. This seems like the right
formum
for bringing this up, so here it goes :-)
Oh, and please forgive the goofy formatting...this was done partially in
notepad and
pasted in.
Has the use of something like Turbine's DynamicURI been considered for
Struts?
Its an approach that allows URI structure and content to change.
Some possible variables for link creation are:
* Format of the query string (normal query string or inclusion into
the extra path info such as "name1/value1/name2/value2".
* Protocol of the connection...http vs https.
* Servername and port. If protocol switching is required, absolute
URIs need to be generated to perform the switch. It is
possible that the secure servername may be different than the
http servername. Even if they're just virtual hosts, there
are issues with sharing certificates across multiple virtual hosts.
One approach to isolating code from these variables is to use a
DynamicURI as a strategy for link creation. All links pointing back
to the servlet are created by instances of this class. Using a factory
to obtain these instances gives developers a straightforward way to
modify this behavior.
A simple version of a DynamicURI interface might be
public interface DynamicURI
{
/** Add a parameter to the link to be generated */
public void addPathInfo(String name, String value);
/** Invoked by the factory, this gives the implementation
* access to the request context...and maybe the servlet
* context as well. If protocol switching is required,
it
* may need other context info to determine the
appropriate
* protocol
*/
public void init(HttpServletRequest req);
// The following methods may throw remote if the
// implementations need to perform a query to find the
// appropriate hostname (cached lookup...)
/** Returns the appropriate URI. */
public String getURI() throws RemoteException;
/** Returns an absulute URI */
public String getFullURI() throws RemoteException;
}
JSP developers should be shielded from this change since the tags would
be the main users of this class. The difference would be that the format
and behavior of the links created by the JSPs could be changed without
changing the JSPs themselves (or the tags for that matter). The form tag
would also probably use this class to generate the action, although the
parameters would come across as hidden fields.
Of course if the URI behavior is changed to use extra path info, the
Action classes that retrieve parameters from the Request would break.
There would need to be a Parameters utility that was used by the Actions
instead of using the request directly. ...or maybe a wrapped Request
could make this seamless (haven't tried this one...what do you think?).
...Which brings me to another design question: Has use of a Parameter
Object been considered for the Action classes? Here again I think
Turbine has an interesting approach. A RunData object is initialized for
each request, and passed to all controller helper classes. It is
essentially a request-scope object, and provides access to the request,
response and any other request-scope info that framework folks would
want to make available.
If factories are used for creation of DynamicURI and RunData, they
provide convenient 'hooks' into the framework for developers to change
its behavior if required.
By the way, I'm not a Turbine user. But these elements have been useful for
me
on previous projects with squirly requirements, and I wonder if other Struts
developers might find them useful.
Best regards,
Stu
