Hoople: Attribute-oriented programming for URLs
Traditionally, configuration gets spread poorly throughout the site.
- Information/Configuration for a particular URL gets split into many different configuration files.
- Configuration files that deal with many URLs get so large that they get difficult to read and manage--especially with multiple developers.
Examples of the problem include
- Web MVC frameworks such as Struts, Spring, JSF etc. define which controllers to run for each URL in a central config file or set of files. For large sites, this quickly becomes unwieldy.
- “URL Logic” such as
- Listing/Configuration of links for “site maps"
- Security logic beyond the scope of what web.xml covers
- Documentation of what URLs are supposed to do
- Pre/post conditions for URLs running to aid in development
- Logging
is stored in separate and unrelated areas.
How does Hoople solve the problem?
Hoople is like attribute-oriented programming for URLs. Rather than having the configuration information and “URL Logic” for a particular URL spread throughout the site, you create a single XML configuration file that contains all the “logic” for each URL on the filesystem.
These XML files are stored where the file for the URL would normally go. So, for example, if your site has a URL of “/news/index.html” you would create an XML configuration file and store it at $DOCUMENT_ROOT/news/index.html. Note that since web frameworks like Struts, Spring, JSF, etc. all use a servlet that catch all *.html requests, you would normally not have that file at all.
These files can then be accessed in various ways depending on how the configuration is needed:
- For applications that require a central configuration file for all URLs at run time, an Ant task can be used to generate the required config file
- A servlet or scheduled job can parse through all the config files at run time
- A Servlet Filter can parse the configuration file at run time to apply security, logging, transactions, etc to the URL
- Developers can simply read the configuration files to find out what URLs are supposed to do and not do
But wait, there’s more!
- During development, possible URLs are easy to find because there is a file actually in the file system for each URL on the system. Compare that to having URLs specified in various XML configuration files.
- “welcome-file-list" actually works for welcome URLS managed by struts/spring/jsf because application servers see there actually is a file there, and will not automatically return a 404 error before seeing if there is a servlet-mapping that matches the URL.
