The Hoople team is proud to announce the availablity of Hoople 1.0. Hoople is similar to Attribute-oriented programming, but geared toward "URL logic" and web app configuration. Traditionally, URL logic and configuration get spread poorly throughout the site. For example, information and 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.
• 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

With Hoople, all of these are stored in separate and unrelated areas. 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. This approach makes it easier to manage configuration files such as struts-config.xml and spring-servlet.xml files as well as put all the information and logic about what happens with a particular URL in an easy to find and easy to manage location. As an added bonus, since real files exist where Struts/Spring etc. map servlets, welcome-file-list declarations will work as expected. Hoople URL configuration files can be accessed and used via an Ant task, Servlets, Filters, or any number of other ways. Message was edited by: joeo@enigmastation.com

Sorry, I just scan through the website. However, I cannot get what is the problem that Hoople try to solve; and I don't know how Hoople solve it. May be you can mention some example of problem cases, and how Hoople fix them? May be some code samples?

Sorry, I just scan through the website. However, I cannot get what is the problem that Hoople try to solve; and I don't know how Hoople solve it. May be you can mention some example of problem cases, and how Hoople fix them? May be some code samples?

The problem that Hoople is trying to solve is similar to the problem XDoclet is trying to solve: how to move related code and configuration that is normally scattered throughout your codebase nearer to each other. One example of a problem is the action mappings in the struts-config.xml for Struts web apps. Struts requires ALL urls that are available on the system to be listed in the struts-config.xml file. You are able to break the file up into smaller files, but they are still very difficult to manage and to find what URLs are available, especially on a team with multiple developers. XDoclet makes it easier to manage by having you not store the action mappins in the struts-config.xml, but as attributes in your Action (controller) classes. During yoru Ant build, an Ant task reads all the attributes and builds up the final struts-config.xml file. Hoople works similary, but moves those attributes out of the Action class, and into a configuration file that is stored within the document root. We've found the Hoople location works better because it's easier to know what URLs are available on the system. You simply look at your document root and see (besides your JSPs, images, CSSs, etc): /index.do /news/index.do /news/news.search.do /news/news.submit.do and know exactly what URLs are available. This is especially true for teams that have non-programmers creating the JSPs etc. and don't know know what an Action class is. Although version 1.0 focuses mainly on managing config files for Struts and Spring, there are many other attributes that are good candidates for declaring in a central location. An example that is included in version 1.0 is the ability to generate Google Sitemaps. It is nice to be able to simply go to /index.do and see: <?xml version='1.0'?> <!DOCTYPE url PUBLIC "-//SUNDOG//DTD HOOPLE//EN" "http://www.sundog.net/hoople/dtd/hoople_1_0.dtd"> It brings all the information/configuration for a particular URL into one place, rather than having it scattered around Action classes and whatever generates your site maps. Additional attributes that we plan on implementing would let you include