Don
Joe Germuska wrote:
At 1:46 PM -0700 4/11/05, Don Brown wrote:
I started down this path and quickly became confused. What I intended to do was create a AppContext, similar to the ActionConext, but where ActionContext provided request and session services, AppContext provided servlet level services. Unfortunately, I quickly discovered there aren't any outside servlet mapping information. ConfigHelper has mostly request and session helper functions, which probably would go into ActionContext. ModuleConfig provides methods for the specific module however it isn't easily accessible (through a threadlocal for example).
I guess what I'm trying to say was, giving the current environment with ModuleConfig and ActionContext, what exactly does everyone see going into a Struts API bean?
I think you're pretty much right -- there's not much global to Struts which isn't really partitioned down to the Module level. But the ModuleConfig object is a bit dumb -- that is, it's just a config container. I haven't looked at the API in a while to see what its lacking.
Rather than what I "want in a Struts API bean," I'd say that the gain I think we'd get from a Struts API bean (or possibly just smarter ModuleConfig type beans) would be more sophisticated assembly of application collaborators.
If Struts' parts were put together by an assembler a little smarter than commons-digester, there might not be much need for any Struts API bean, because any relevant collaborators would be introduced to each other by the assembler. As much as I have had successes with Digester in the past, this is where it really starts to break down, especially once you get the taste for that kind of wiring.
Then we really start getting into some bigger refactorings -- but then, if that's on the horizon, it may make pursuing a monolithic API bean less attractive.
Joe
Don
Craig McClanahan wrote:
Not so much an "anything else" comment, but you might want to take a look at a similar bean I built in the struts-faces library so that you could use value binding expressions to access Struts configutation stuff. If you check out the "current" pseudo-directory, the source code is at:
faces/core-library/src/java/org/apache/struts/faces/util/StrutsContext.java
There are some JSF-specific things here that wouldn't fit the general case, but it might serve as a starting point.
Craig
On Mon, 28 Mar 2005 15:57:23 -0800, Don Brown <[EMAIL PROTECTED]> wrote:
I'm looking at bug 9088 and my solution would involve saving all
discovered servlet mappings into probably a ServletMappingHelper which
would provide methods that allowed retrieval of mappings and matching of
existing servlet paths to mappings for the purpose of generating a URL.
Anyways, an object such as that needs to made available somehow, which
gets back to the Struts API bean discussion. If I'm going to address
this bug, I might as well code up the API bean and do it right. My
thoughts is this would be an object, patterned after
o.a.s.config.ConfigHelper, which would exist once per Struts instance in
the servlet context. Additionally, it would be available through a
ThreadLocal variable to allow it to be accessed at any point in the
application (this feature is perhaps debatable).
My goals in designing this bean:
1. Capture all application-level configuration information 2. Replace instances where Struts application-level objects are pulled out of the servlet context 3. Initially, of course, the application-level objects would still be available in the servlet context, but hopefully, this could be phased out by 1.5 perhaps.
Anything else?
Don
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
