DO NOT REPLY [Bug 16388] - documentation of the currentPlugInConfigObject

[bu...@apache.org]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=16388>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=16388

documentation of the currentPlugInConfigObject

martinc@apache.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |WONTFIX



------- Additional Comments From martinc@apache.org  2004-04-07 07:02 -------
I am not inclined to document this at all. It is a hack created specifically 
for the Tiles plugin, and one that I would like to get rid of as soon as 
possible.

The normal way for a plugin to obtain its configured properties is for it to 
have corresponding property getters and setters. The setters will be called 
prior to init() being called, so the plugin will be configured before it is 
initialised.

There may be situations in which the particular config properties are not known 
ahead of time, which I believe is probably the case with the Tiles plugin. In 
such situations, it is obviously desirable for the plugin to have access to its 
configuration data. The current mechanism, however, is not the right way to do 
this.

Better would be to pass a PlugInConfig instance to the init() method, or add a 
setConfig() method to the PlugIn interface. These options, however, require 
interface changes, so cannot be put into place any earlier than a Struts 2.0 
release.

There is another option that would work, as long as a given plugin class is not 
used more than once in any given module. That would be to provide a method for 
a plugin to obtain its config from its module and itself. For example:

  PlugInConfig pic = SomeUtilClass.getPlugInConfig(ModuleConfig mc, PlugIn p);

This can obtain the appropriate PlugInConfig instance based on the class of the 
plugin itself. However, this doesn't seem much less hacky than the current 
approach, other than that the method is more easily, and more obviously, 
deprecated.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org