You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Hubert Rabago <hr...@gmail.com> on 2005/02/22 16:07:18 UTC
struts-config extends
I tried this over the weekend, starting with form beans.
Here's what my sample app had:
<!-- the form I extend -->
<form-bean name="baseForm"
type="o.a.s.a.DynaActionForm">
<form-property name="firstName" type="java.lang.String"/>
<form-property name="lastName" type="java.lang.String"/>
<form-property name="score" type="java.lang.String"/>
</form-bean>
<!-- this is the form my actions used -->
<form-bean name="basicForm"
extends="baseForm">
<form-property name="score" initial="100"/>
<form-property name="attempts" type="java.lang.String"/>
</form-bean>
The idea is that basicForm will end up with:
<form-bean name="basicForm"
type="o.a.s.a.DynaActionForm">
<form-property name="firstName" type="java.lang.String"/>
<form-property name="lastName" type="java.lang.String"/>
<form-property name="score" type="java.lang.String" initial="100"/>
<form-property name="attempts" type="java.lang.String"/>
</form-bean>
The following values would be inherited:
FormBeanConfig.type
...and for each property:
FormPropertyConfig class
FormPropertyConfig.name
FormPropertyConfig.type
FormPropertyConfig.initial
FormPropertyConfig.size
...unless a "subform" overrides it.
So in the example above, if basicForm included an entry
stating the "score" field should use "java.lang.Integer", that's
what the end result would have. It would still inherit "initial"
and "size" if the "superform" specified it.
For something like this, I had to remove the "type"
requirement for the <form-bean> and <form-property> elements.
The extension gets realized before the loop which creates and
registers the DynaActionFormClass instances. This code is still
in the ActionServlet.initModuleConfig() method, so I've extracted
this into its own method. Simple checks for circular inheritance
can be easily done by FormBeanConfig, but more complex checking
should probably be done by a separate method in ActionServlet, or
maybe in a util class, such as ModuleUtils.
Comments, please.
I can start working on some unit tests next.
I may have some time tomorrow night.
On Mon, 14 Feb 2005 17:39:34 -0600, Joe Germuska <Jo...@germuska.com> wrote:
> One thing which has been talked about in a few places, and which
> would be valuable, but which no one has done any work on is
> implementing "extends" in as many places in struts-config.xml as it
> would be useful, to eliminate repeated chunks of XML. For
> Validation, this would really be an enhancement to commons-validator,
> but perhaps the same general strategy could be applied. I haven't
> even looked at what would be involved in trying to implement it.
Which other places would this make sense to do?
Exception handlers, forwards, and action mappings?
I haven't taken a look at these yet.
For exception handlers and forwards, should action-specific config be
allowed to extend global config? Hmm... I'm thinking yes; I haven't thought
of a reason not to, yet.
As for Validator, 1.2 already supports extensions. I'm not that familiar
with Validator, so I don't know what issues are preventing that version's
release, nor if the extends feature can be applied to the 1.1.x versions.
Hubert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: struts-config extends
Posted by Hubert Rabago <hr...@gmail.com>.
The answer could be simpler than I originally thought, and it revealed
itself in the code. Since a custom config object would have to extend
the original, say FormBeanConfig, it would be up to the subclass to
override the inheritFrom() method which is what actually copies config
properties from another FormBeanConfig. Any subconfig could implement
their own code to inherit their own custom props. The code that
executes before inheritFrom() would have the responsibility of making
sure that config object is of the right (sub)class.
On Tue, 22 Feb 2005 17:15:14 -0000, Niall Pemberton
<ni...@blueyonder.co.uk> wrote:
> Thanks for putting the effort into a solution for this Hubert, it will be a
> good addition to Struts. I have a couple of comments....
>
> I'm wondering whether as well as what you suggest we should also inherit the
> actual FormBeanConfig as well? This would make it far more complex to
> implement because of any custom properties that the user might have set
> using the <set-property> element. Its probably not a big deal for form
> beans - but when it comes to implementing this kind of inheritance for
> action mappings and forwards I think its an issue we would need to deal with
> and my gut feel is that this feature needs to work consistently for all the
> elements of the struts-config and not one way for action forms and another
> for action mappings.
>
> Secondly, what about modules? Should we allow inheritance from other modules
> and/or if a form bean doesn't exist in the current module - then check the
> deault one?
>
> Niall
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: struts-config extends
Posted by Hubert Rabago <hr...@gmail.com>.
Good catch.
I inherited the form property config class, but not its properties,
and I was thinking that the FormBeanConfig instance would already be
using the custom class, if any. Now I'm seeing that's not necessarily
the case.
When the extensions are being realized, what we'll have on hand is
what Digester'll give us, and that's what's explicitly specified in
struts-config. In order to inherit the FormBeanConfig subclass, we
can either
(1) recreate it and re-register it using the inherited subclass, or
(2) let the custom digester rule handle it.
(1) is doable, but with (2), I'm beginning to hear the words slippery
slope again. (Wasn't that phrase was uttered here just recently?)
For the subclass' properties, I'm not sure how to access those yet. A
straight copyProperties could override props we want to retain. I
don't want to support this unless it can be done properly, and to me
that means inheriting only values that were specified in the config,
not properties that could've been set by other means.
Perhaps this "extends 1.0" could concentrate on the form bean being
configured, as opposed to the object used to configure it? I agree it
would be a bigger issue for mappings and forwards. I'll continue to
look into a clean way to accomplish this. Suggestions would be great.
As for modules, my inclination is to limit inheritance within the
module. IIRC, this would match the way global-forward and
global-exception works. Feels cleaner, too. I'm not sure which
config elements are shared across modules, or by the default to the
sub modules. However, it won't be that difficult to inherit
individual elements from the default module. That might lead users to
asking for the entire <action-mappings> or <form-beans> to be
inherited! :)
Hubert
On Tue, 22 Feb 2005 17:15:14 -0000, Niall Pemberton
<ni...@blueyonder.co.uk> wrote:
> Thanks for putting the effort into a solution for this Hubert, it will be a
> good addition to Struts. I have a couple of comments....
>
> I'm wondering whether as well as what you suggest we should also inherit the
> actual FormBeanConfig as well? This would make it far more complex to
> implement because of any custom properties that the user might have set
> using the <set-property> element. Its probably not a big deal for form
> beans - but when it comes to implementing this kind of inheritance for
> action mappings and forwards I think its an issue we would need to deal with
> and my gut feel is that this feature needs to work consistently for all the
> elements of the struts-config and not one way for action forms and another
> for action mappings.
>
> Secondly, what about modules? Should we allow inheritance from other modules
> and/or if a form bean doesn't exist in the current module - then check the
> deault one?
>
> Niall
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: struts-config extends
Posted by Hubert Rabago <hr...@gmail.com>.
If we pull off extends for individual config elements, maybe extending
a base-config.xml would be as simple as referring to it in each of the
modules' <init-param> in web.xml.
- Hubert
On Tue, 22 Feb 2005 09:27:27 -0800, Don Brown <mr...@twdata.org> wrote:
> I don't know about extending modules, but it would be nice to extend
> other Struts config files. Define a base-config.xml that isn't used
> directly then inherit it in several modules.
>
> Don
>
> Niall Pemberton wrote:
> > Thanks for putting the effort into a solution for this Hubert, it will be a
> > good addition to Struts. I have a couple of comments....
> >
> > I'm wondering whether as well as what you suggest we should also inherit the
> > actual FormBeanConfig as well? This would make it far more complex to
> > implement because of any custom properties that the user might have set
> > using the <set-property> element. Its probably not a big deal for form
> > beans - but when it comes to implementing this kind of inheritance for
> > action mappings and forwards I think its an issue we would need to deal with
> > and my gut feel is that this feature needs to work consistently for all the
> > elements of the struts-config and not one way for action forms and another
> > for action mappings.
> >
> > Secondly, what about modules? Should we allow inheritance from other modules
> > and/or if a form bean doesn't exist in the current module - then check the
> > deault one?
> >
> > Niall
> >
> > ----- Original Message -----
> > To: "Struts Developers List" <de...@struts.apache.org>
> > Sent: Tuesday, February 22, 2005 3:07 PM
> >
> >
> >
> >>I tried this over the weekend, starting with form beans.
> >>Here's what my sample app had:
> >>
> >><!-- the form I extend -->
> >><form-bean name="baseForm"
> >> type="o.a.s.a.DynaActionForm">
> >> <form-property name="firstName" type="java.lang.String"/>
> >> <form-property name="lastName" type="java.lang.String"/>
> >> <form-property name="score" type="java.lang.String"/>
> >></form-bean>
> >>
> >><!-- this is the form my actions used -->
> >><form-bean name="basicForm"
> >> extends="baseForm">
> >> <form-property name="score" initial="100"/>
> >> <form-property name="attempts" type="java.lang.String"/>
> >></form-bean>
> >>
> >>
> >>The idea is that basicForm will end up with:
> >><form-bean name="basicForm"
> >> type="o.a.s.a.DynaActionForm">
> >> <form-property name="firstName" type="java.lang.String"/>
> >> <form-property name="lastName" type="java.lang.String"/>
> >> <form-property name="score" type="java.lang.String" initial="100"/>
> >> <form-property name="attempts" type="java.lang.String"/>
> >></form-bean>
> >>
> >>The following values would be inherited:
> >>FormBeanConfig.type
> >>
> >>...and for each property:
> >>FormPropertyConfig class
> >>FormPropertyConfig.name
> >>FormPropertyConfig.type
> >>FormPropertyConfig.initial
> >>FormPropertyConfig.size
> >>
> >>...unless a "subform" overrides it.
> >>So in the example above, if basicForm included an entry
> >>stating the "score" field should use "java.lang.Integer", that's
> >>what the end result would have. It would still inherit "initial"
> >>and "size" if the "superform" specified it.
> >>
> >>For something like this, I had to remove the "type"
> >>requirement for the <form-bean> and <form-property> elements.
> >>
> >>The extension gets realized before the loop which creates and
> >>registers the DynaActionFormClass instances. This code is still
> >>in the ActionServlet.initModuleConfig() method, so I've extracted
> >>this into its own method. Simple checks for circular inheritance
> >>can be easily done by FormBeanConfig, but more complex checking
> >>should probably be done by a separate method in ActionServlet, or
> >>maybe in a util class, such as ModuleUtils.
> >>
> >>Comments, please.
> >>
> >>I can start working on some unit tests next.
> >>I may have some time tomorrow night.
> >>
> >>
> >>On Mon, 14 Feb 2005 17:39:34 -0600, Joe Germuska <Jo...@germuska.com> wrote:
> >>
> >>>One thing which has been talked about in a few places, and which
> >>>would be valuable, but which no one has done any work on is
> >>>implementing "extends" in as many places in struts-config.xml as it
> >>>would be useful, to eliminate repeated chunks of XML. For
> >>>Validation, this would really be an enhancement to commons-validator,
> >>>but perhaps the same general strategy could be applied. I haven't
> >>>even looked at what would be involved in trying to implement it.
> >>
> >>Which other places would this make sense to do?
> >>Exception handlers, forwards, and action mappings?
> >>I haven't taken a look at these yet.
> >>For exception handlers and forwards, should action-specific config be
> >>allowed to extend global config? Hmm... I'm thinking yes; I haven't
> >
> > thought
> >
> >>of a reason not to, yet.
> >>
> >>As for Validator, 1.2 already supports extensions. I'm not that familiar
> >>with Validator, so I don't know what issues are preventing that version's
> >>release, nor if the extends feature can be applied to the 1.1.x versions.
> >>
> >>Hubert
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: struts-config extends
Posted by Don Brown <mr...@twdata.org>.
I don't know about extending modules, but it would be nice to extend
other Struts config files. Define a base-config.xml that isn't used
directly then inherit it in several modules.
Don
Niall Pemberton wrote:
> Thanks for putting the effort into a solution for this Hubert, it will be a
> good addition to Struts. I have a couple of comments....
>
> I'm wondering whether as well as what you suggest we should also inherit the
> actual FormBeanConfig as well? This would make it far more complex to
> implement because of any custom properties that the user might have set
> using the <set-property> element. Its probably not a big deal for form
> beans - but when it comes to implementing this kind of inheritance for
> action mappings and forwards I think its an issue we would need to deal with
> and my gut feel is that this feature needs to work consistently for all the
> elements of the struts-config and not one way for action forms and another
> for action mappings.
>
> Secondly, what about modules? Should we allow inheritance from other modules
> and/or if a form bean doesn't exist in the current module - then check the
> deault one?
>
> Niall
>
> ----- Original Message -----
> To: "Struts Developers List" <de...@struts.apache.org>
> Sent: Tuesday, February 22, 2005 3:07 PM
>
>
>
>>I tried this over the weekend, starting with form beans.
>>Here's what my sample app had:
>>
>><!-- the form I extend -->
>><form-bean name="baseForm"
>> type="o.a.s.a.DynaActionForm">
>> <form-property name="firstName" type="java.lang.String"/>
>> <form-property name="lastName" type="java.lang.String"/>
>> <form-property name="score" type="java.lang.String"/>
>></form-bean>
>>
>><!-- this is the form my actions used -->
>><form-bean name="basicForm"
>> extends="baseForm">
>> <form-property name="score" initial="100"/>
>> <form-property name="attempts" type="java.lang.String"/>
>></form-bean>
>>
>>
>>The idea is that basicForm will end up with:
>><form-bean name="basicForm"
>> type="o.a.s.a.DynaActionForm">
>> <form-property name="firstName" type="java.lang.String"/>
>> <form-property name="lastName" type="java.lang.String"/>
>> <form-property name="score" type="java.lang.String" initial="100"/>
>> <form-property name="attempts" type="java.lang.String"/>
>></form-bean>
>>
>>The following values would be inherited:
>>FormBeanConfig.type
>>
>>...and for each property:
>>FormPropertyConfig class
>>FormPropertyConfig.name
>>FormPropertyConfig.type
>>FormPropertyConfig.initial
>>FormPropertyConfig.size
>>
>>...unless a "subform" overrides it.
>>So in the example above, if basicForm included an entry
>>stating the "score" field should use "java.lang.Integer", that's
>>what the end result would have. It would still inherit "initial"
>>and "size" if the "superform" specified it.
>>
>>For something like this, I had to remove the "type"
>>requirement for the <form-bean> and <form-property> elements.
>>
>>The extension gets realized before the loop which creates and
>>registers the DynaActionFormClass instances. This code is still
>>in the ActionServlet.initModuleConfig() method, so I've extracted
>>this into its own method. Simple checks for circular inheritance
>>can be easily done by FormBeanConfig, but more complex checking
>>should probably be done by a separate method in ActionServlet, or
>>maybe in a util class, such as ModuleUtils.
>>
>>Comments, please.
>>
>>I can start working on some unit tests next.
>>I may have some time tomorrow night.
>>
>>
>>On Mon, 14 Feb 2005 17:39:34 -0600, Joe Germuska <Jo...@germuska.com> wrote:
>>
>>>One thing which has been talked about in a few places, and which
>>>would be valuable, but which no one has done any work on is
>>>implementing "extends" in as many places in struts-config.xml as it
>>>would be useful, to eliminate repeated chunks of XML. For
>>>Validation, this would really be an enhancement to commons-validator,
>>>but perhaps the same general strategy could be applied. I haven't
>>>even looked at what would be involved in trying to implement it.
>>
>>Which other places would this make sense to do?
>>Exception handlers, forwards, and action mappings?
>>I haven't taken a look at these yet.
>>For exception handlers and forwards, should action-specific config be
>>allowed to extend global config? Hmm... I'm thinking yes; I haven't
>
> thought
>
>>of a reason not to, yet.
>>
>>As for Validator, 1.2 already supports extensions. I'm not that familiar
>>with Validator, so I don't know what issues are preventing that version's
>>release, nor if the extends feature can be applied to the 1.1.x versions.
>>
>>Hubert
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: struts-config extends
Posted by Niall Pemberton <ni...@blueyonder.co.uk>.
Thanks for putting the effort into a solution for this Hubert, it will be a
good addition to Struts. I have a couple of comments....
I'm wondering whether as well as what you suggest we should also inherit the
actual FormBeanConfig as well? This would make it far more complex to
implement because of any custom properties that the user might have set
using the <set-property> element. Its probably not a big deal for form
beans - but when it comes to implementing this kind of inheritance for
action mappings and forwards I think its an issue we would need to deal with
and my gut feel is that this feature needs to work consistently for all the
elements of the struts-config and not one way for action forms and another
for action mappings.
Secondly, what about modules? Should we allow inheritance from other modules
and/or if a form bean doesn't exist in the current module - then check the
deault one?
Niall
----- Original Message -----
To: "Struts Developers List" <de...@struts.apache.org>
Sent: Tuesday, February 22, 2005 3:07 PM
> I tried this over the weekend, starting with form beans.
> Here's what my sample app had:
>
> <!-- the form I extend -->
> <form-bean name="baseForm"
> type="o.a.s.a.DynaActionForm">
> <form-property name="firstName" type="java.lang.String"/>
> <form-property name="lastName" type="java.lang.String"/>
> <form-property name="score" type="java.lang.String"/>
> </form-bean>
>
> <!-- this is the form my actions used -->
> <form-bean name="basicForm"
> extends="baseForm">
> <form-property name="score" initial="100"/>
> <form-property name="attempts" type="java.lang.String"/>
> </form-bean>
>
>
> The idea is that basicForm will end up with:
> <form-bean name="basicForm"
> type="o.a.s.a.DynaActionForm">
> <form-property name="firstName" type="java.lang.String"/>
> <form-property name="lastName" type="java.lang.String"/>
> <form-property name="score" type="java.lang.String" initial="100"/>
> <form-property name="attempts" type="java.lang.String"/>
> </form-bean>
>
> The following values would be inherited:
> FormBeanConfig.type
>
> ...and for each property:
> FormPropertyConfig class
> FormPropertyConfig.name
> FormPropertyConfig.type
> FormPropertyConfig.initial
> FormPropertyConfig.size
>
> ...unless a "subform" overrides it.
> So in the example above, if basicForm included an entry
> stating the "score" field should use "java.lang.Integer", that's
> what the end result would have. It would still inherit "initial"
> and "size" if the "superform" specified it.
>
> For something like this, I had to remove the "type"
> requirement for the <form-bean> and <form-property> elements.
>
> The extension gets realized before the loop which creates and
> registers the DynaActionFormClass instances. This code is still
> in the ActionServlet.initModuleConfig() method, so I've extracted
> this into its own method. Simple checks for circular inheritance
> can be easily done by FormBeanConfig, but more complex checking
> should probably be done by a separate method in ActionServlet, or
> maybe in a util class, such as ModuleUtils.
>
> Comments, please.
>
> I can start working on some unit tests next.
> I may have some time tomorrow night.
>
>
> On Mon, 14 Feb 2005 17:39:34 -0600, Joe Germuska <Jo...@germuska.com> wrote:
> > One thing which has been talked about in a few places, and which
> > would be valuable, but which no one has done any work on is
> > implementing "extends" in as many places in struts-config.xml as it
> > would be useful, to eliminate repeated chunks of XML. For
> > Validation, this would really be an enhancement to commons-validator,
> > but perhaps the same general strategy could be applied. I haven't
> > even looked at what would be involved in trying to implement it.
>
> Which other places would this make sense to do?
> Exception handlers, forwards, and action mappings?
> I haven't taken a look at these yet.
> For exception handlers and forwards, should action-specific config be
> allowed to extend global config? Hmm... I'm thinking yes; I haven't
thought
> of a reason not to, yet.
>
> As for Validator, 1.2 already supports extensions. I'm not that familiar
> with Validator, so I don't know what issues are preventing that version's
> release, nor if the extends feature can be applied to the 1.1.x versions.
>
> Hubert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: struts-config extends
Posted by Hubert Rabago <hr...@gmail.com>.
On Tue, 22 Feb 2005 08:10:03 -0800, Don Brown <mr...@twdata.org> wrote:
>
> I have yet to take a look at the implementation, but regarding timing, I
> think it is perfect and am very grateful to you for taking this on. If
> I remember correctly, this is the last major feature we wanted to put in
> 1.3. After this gets in, we can stabilize the code, figure out what the
> release should look like with all these subprojects, and get 1.3 out the
> door. Thanks again for looking into this!
>
> Don
>
I'll proceed, then. I'll finish up form beans, submit a patch for
that, before starting
with action mappings.
Like I mentioned earlier, I changed some attributes from required to implied,
particularly the "type" attribute. Do we want a simple loop before the config
is frozen (and after the extensions are realized) to check for these
required values?
Hubert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: struts-config extends
Posted by Ted Husted <hu...@apache.org>.
On Tue, 22 Feb 2005 08:10:03 -0800, Don Brown wrote:
> I have yet to take a look at the implementation, but regarding
> timing, I think it is perfect and am very grateful to you for
> taking this on. If I remember correctly, this is the last major
> feature we wanted to put in 1.3. After this gets in, we can
> stabilize the code, figure out what the release should look like
> with all these subprojects, and get 1.3 out the door. Thanks again
> for looking into this!
+1
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: struts-config extends
Posted by Don Brown <mr...@twdata.org>.
Hubert Rabago wrote:
> Well, I extracted the form bean initialization into an
> initModuleFormBeans(moduleConfig) method which matches other methods
> like it. Here's a snippet from ActionServlet.init():
>
> initModuleConfigFactory();
> // Initialize modules as needed
> ModuleConfig moduleConfig = initModuleConfig("", config);
> initModuleMessageResources(moduleConfig);
> initModuleDataSources(moduleConfig);
> initModulePlugIns(moduleConfig);
> moduleConfig.freeze();
>
> With other config elements being extended, the method
> could be called processModuleExtensions(moduleConfig)
> and be called along with these methods.
>
> These methods look like they can be moved elsewhere, but
> that's another thread. :)
>
> Any comment on the extends implementation? Should I proceed,
> or is the timing not right what with everybody working on the
> chain implementation and repo reorg?
I have yet to take a look at the implementation, but regarding timing, I
think it is perfect and am very grateful to you for taking this on. If
I remember correctly, this is the last major feature we wanted to put in
1.3. After this gets in, we can stabilize the code, figure out what the
release should look like with all these subprojects, and get 1.3 out the
door. Thanks again for looking into this!
Don
>
> - Hubert
>
>
> On Tue, 22 Feb 2005 09:39:54 -0600, Joe Germuska <Jo...@germuska.com> wrote:
>
>>At 9:07 AM -0600 2/22/05, Hubert Rabago wrote:
>>
>>>I tried this over the weekend, starting with form beans.
>>>Here's what my sample app had:
>>
>>Hubert: the description of intent for the XML is right-on.
>>
>>
>>>The extension gets realized before the loop which creates and
>>>registers the DynaActionFormClass instances. This code is still
>>>in the ActionServlet.initModuleConfig() method, so I've extracted
>>>this into its own method. Simple checks for circular inheritance
>>>can be easily done by FormBeanConfig, but more complex checking
>>>should probably be done by a separate method in ActionServlet, or
>>>maybe in a util class, such as ModuleUtils.
>>>
>>>Comments, please.
>>
>>Now may not be the time, but my long-term preference would be to
>>extract as much as possible out of the ActionServlet, so that it
>>simply becomes a choreographer. I think this is a good pre-cursor to
>>having more flexible options for how to configure Struts (as well as
>>forcing us to be more deliberate about where we permit dependencies
>>on the Servlet API). From a purely conceptual standpoint, I almost
>>think that everything inside initModuleConfig() should be moved into
>>the ModuleConfigFactory.
>>
>>But in the meantime, I think putting it in ModuleUtils is probably
>>better than having it in the ActionServlet itself.
>>
>>I don't know if other people share my opinions about this.
>>
>>Joe
>>
>>--
>>Joe Germuska
>>Joe@Germuska.com
>>http://blog.germuska.com
>>"Narrow minds are weapons made for mass destruction" -The Ex
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: struts-config extends
Posted by Hubert Rabago <hr...@gmail.com>.
Well, I extracted the form bean initialization into an
initModuleFormBeans(moduleConfig) method which matches other methods
like it. Here's a snippet from ActionServlet.init():
initModuleConfigFactory();
// Initialize modules as needed
ModuleConfig moduleConfig = initModuleConfig("", config);
initModuleMessageResources(moduleConfig);
initModuleDataSources(moduleConfig);
initModulePlugIns(moduleConfig);
moduleConfig.freeze();
With other config elements being extended, the method
could be called processModuleExtensions(moduleConfig)
and be called along with these methods.
These methods look like they can be moved elsewhere, but
that's another thread. :)
Any comment on the extends implementation? Should I proceed,
or is the timing not right what with everybody working on the
chain implementation and repo reorg?
- Hubert
On Tue, 22 Feb 2005 09:39:54 -0600, Joe Germuska <Jo...@germuska.com> wrote:
> At 9:07 AM -0600 2/22/05, Hubert Rabago wrote:
> >I tried this over the weekend, starting with form beans.
> >Here's what my sample app had:
>
> Hubert: the description of intent for the XML is right-on.
>
> >The extension gets realized before the loop which creates and
> >registers the DynaActionFormClass instances. This code is still
> >in the ActionServlet.initModuleConfig() method, so I've extracted
> >this into its own method. Simple checks for circular inheritance
> >can be easily done by FormBeanConfig, but more complex checking
> >should probably be done by a separate method in ActionServlet, or
> >maybe in a util class, such as ModuleUtils.
> >
> >Comments, please.
>
> Now may not be the time, but my long-term preference would be to
> extract as much as possible out of the ActionServlet, so that it
> simply becomes a choreographer. I think this is a good pre-cursor to
> having more flexible options for how to configure Struts (as well as
> forcing us to be more deliberate about where we permit dependencies
> on the Servlet API). From a purely conceptual standpoint, I almost
> think that everything inside initModuleConfig() should be moved into
> the ModuleConfigFactory.
>
> But in the meantime, I think putting it in ModuleUtils is probably
> better than having it in the ActionServlet itself.
>
> I don't know if other people share my opinions about this.
>
> Joe
>
> --
> Joe Germuska
> Joe@Germuska.com
> http://blog.germuska.com
> "Narrow minds are weapons made for mass destruction" -The Ex
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: struts-config extends
Posted by Joe Germuska <Jo...@Germuska.com>.
At 9:07 AM -0600 2/22/05, Hubert Rabago wrote:
>I tried this over the weekend, starting with form beans.
>Here's what my sample app had:
Hubert: the description of intent for the XML is right-on.
>The extension gets realized before the loop which creates and
>registers the DynaActionFormClass instances. This code is still
>in the ActionServlet.initModuleConfig() method, so I've extracted
>this into its own method. Simple checks for circular inheritance
>can be easily done by FormBeanConfig, but more complex checking
>should probably be done by a separate method in ActionServlet, or
>maybe in a util class, such as ModuleUtils.
>
>Comments, please.
Now may not be the time, but my long-term preference would be to
extract as much as possible out of the ActionServlet, so that it
simply becomes a choreographer. I think this is a good pre-cursor to
having more flexible options for how to configure Struts (as well as
forcing us to be more deliberate about where we permit dependencies
on the Servlet API). From a purely conceptual standpoint, I almost
think that everything inside initModuleConfig() should be moved into
the ModuleConfigFactory.
But in the meantime, I think putting it in ModuleUtils is probably
better than having it in the ActionServlet itself.
I don't know if other people share my opinions about this.
Joe
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction" -The Ex
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org