This post on Why are people so down on Struts probably deserves an immediate rebuttle, but I'm too tired and have better things to do. The best reason I can say that I like it - it's paying the bills. Show me a better framework and a contract that wants to use it, and I'll be all over it like a monkey f**in' a football. ;-)
So you ask, what "better things" do you have to do. Well, there are many things better than pounding on this keyboard (i.e. playing with Abbie, loving my wife), however, I'm a sad sob and I'll be here all night. I'm planning on digging into struts-menu and 1) upgrading it to CoolMenus4 and 2) configuring it to allow lists for DHTML menus. Then I have to make sure both methods allow for permission checking, since I want to use struts-menu to display url-hiding security in my chapter. Wish me luck - and feel free to help if you want to get your hands dirty!
Jeff Duska has a post tonight on how he handles app-specific configuration settings. His method sounds pretty neat, and hopefully we can combine our methods to come up with a better solution. Here's how I've been doing it.
- I have a StartupServlet that reads in an XML file and, using Castor, populates a JavaBean with the XML file's values. Sidenote - I recommend having a StartupServlet in webapps to populate drop-down choices from the database and stuff ArrayLists (of beans) into the ServletContext - works real slick in Struts using the LabelValueBean.
- Stuff the JavaBean into the servlet context and get values as needed while running the app.
Jeff's method seems make it easier to retrieve the values, but not to set them. I have a getConfiguration() method in my BaseAction class that I use to get my configuration data:
/**
* Get the Configuration object from the servlet context
*/
public Configuration getConfiguration(){
return (Configuration) servlet.getServletContext().getAttribute(
Constants.CONFIGURATION);
}
The obvious problem with this is that only subclasses of BaseAction can get the configuration information - therefore, I like Jeff's idea better. However, I'm curious to know how he populates his Registry class. Castor makes it pretty damn easy. Here's the method I use in StartupServlet, where obj is my JavaBean, and xmlFilePath is configured as "/WEB-INF/app-config.xml" in one of StartupServlet's init-parameters.
/**
* Load our application configuration XML file.
*
* @exception Exception if any problem occurs while loading
*/
private synchronized Object loadConfig
(
Object obj,
String xmlFilePath
)
throws Exception {
// attempt to extract the filename, using system file separator
int index = xmlFilePath.lastIndexOf(Constants.FILE_SEP);
// no system file separator found in configuration setting
if (index == -1) {
// check traditional file separator as used in web app URI's
index = xmlFilePath.lastIndexOf("/");
// still no separator, maybe they're just specifying the filename
if (index == -1) {
index = 0;
}
}
String xmlFileName =
xmlFilePath.substring(index + 1, xmlFilePath.length());
if (logger.isDebugEnabled()) {
logger.debug("Looking for '" + xmlFileName + "' in "
+ Constants.USER_HOME);
}
// Acquire an input stream to our configuration file
InputStream is = null;
try {
is = new FileInputStream(Constants.USER_HOME + xmlFileName);
} catch (FileNotFoundException fnf) {
// No file found in user.home
if (logger.isDebugEnabled()) {
logger.debug("File not found at " + Constants.USER_HOME
+ xmlFileName + " - looking at specified path in web.xml.");
}
// Look for config.xml in WEB-INF
is = getServletContext().getResourceAsStream(xmlFilePath);
if (is == null) {
throw new Exception("Configuration file '"
+ xmlFileName + "' not found in '"
+ Constants.USER_HOME + "', nor at '" + xmlFilePath + "'");
}
}
InputStreamReader reader = new InputStreamReader(is);
// Marshal the configuration object
obj = Unmarshaller.unmarshal(obj.getClass(), reader);
// close the InputStream, and the reader
is.close();
reader.close();
return obj;
}
I like this method because it can load multiple configuration files, and I already have it written - so the hard part is over ;-) It also makes it easy to configure your app outside of WEB-INF, and changes won't be overwritten when a user upgrades their WAR file or whatnot. I suppose I could use Jeff's method and make my JavaBean into a Singleton and not store it in ServletContext - that'll probably work better than my current scenario.
I've decided to rename struts-xdoclet to AppFuse! Why? Because 1) it's easier to say, 2) it's a more descriptive name, and 3) it's the fuse to get your app started! I'll be checking it into SourceForge's Struts project soon, and will post more information then.
I've been thinking about my sample app for the Struts Chapter and I'd like to develop something that's useful. I doubt I'll have the time to pull it off, but I'd like to develop a resume builder/viewer app. I think it'd be a great way to demonstrate CRUD with Struts with skills and such. It could even be an application that would support multiple users, where skills can be shared and selected. I've been thinking about doing something like this for a while. It's a pain to update my resume right now because there's 4 different versions - online JSP, downloadable HTML, Word and Text. I've often thought about just creating an XML version and using JSTL to to XSL transformations into HTML, Text, RTF and PDF. I wonder if this XML resume project at SourceForge could help? I'd love to create an app that allows you to easily update your resume and can publish it in all these different formats. Even better, if it could be resume-standards-compliant (i.e. DTD or XSD) and allow users to select/upload/use different styles. I think this would take much of the headache out of online resume publishing. However, I'd probably spend more time tweaking it than I would just updating the 4 different versions of my resume. It'd kinda like this website, I chose to use Roller as my re-design engine because it was quick and easy - and now I spend a couple hours each day tweaking and updating. I could've redesigned for a lot cheaper! Of course, new content == hits.
The only problems I can foresee with this app (so far) are Old Man Time and that it might be a maintenance nightmare. I would suspect a lot of folks might want import/export to/from existing formats. Thoughts? Comments?
