Quoting Frank Seaton Taylor <[EMAIL PROTECTED]>: > Good day all, > > I'm a three month old web developer and have been trying to figure out > how to do something described below. I've read a bunch of documentation > and searched mailing lists and the web for answers, but fear that my > inexperience is hampering me in that my tenuous grasp of this new > vocabulary might mislead me when what I'm reading contains the answer I > seek, but I don't comprehend it. Here's a stab at describing my goal: > > In our struts-config.xml we have a number of actions which have roles > attributes. I would like to produce a table of links that initiate > those actions, but with some restrictions. It should only be actions > whose path has a certain form. (Specifically, I need to produce a list > of actions whose paths begin with a certain string.) In addition, only > those actions whose roles are valid with the current user should be > included. The fact that we use a custom > RequestProcessor.processRoles(...) may complicate matters, but I hope > that it doesn't. > > My naive plan of attack is that since struts-config.xml is parsed and > stored somewhere that I ought to be able to access it's information, > loop through the actions and easily restrict that list to those whose > path matches a certain form. I'll less clear on weeding out the actions > whose roles apply, (What arguments would I need to > RequestProcessor.processRoles(...)?) but that might be clearer if I > knew the data structures that store struts-config.xml. > > Is this a reasonable approach? If not, how about some other ideas? If > so, could someone point me to the data structures that store > struts-config.xml? >
Your supposition that Struts stores the metadata it reads from struts-config.xml files is indeed correct. The configuration beans are all in the org.apache.struts.config package, and the "root" bean in the hierarchy is a ModuleConfig. If you have a single-module application, the ModuleConfig object is a servlet context attribute stored under the key specified by the Globals.MODULE_KEY manifest constant. ModuleConfig beans for other modules (in a multi-module application) are stored in servet context attributes that are composed of this key plus the module prefix. In both single-module and multi-module applications, Struts will also copy the ModuleConfig for the *current* module to a request attribute under the same key (Globals.MODULE_KEY), before the request processor is invoked. Thus, you're probably easier to deal with. It might also be worth skimming through the Javadocs on all the manifest constants in org.apache.struts.Globals to see what other standard places Struts stores the configuration and application objects that it deas with. > Thanks for your consideration, > ---Frank Craig McClanahan --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
