- 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
News: Hoople 1.0: Attribute-Oriented Programming for URL Logic
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:
- Posted by: Nathan Voxland
- Posted on: June 27 2006 10:35 EDT
- Don't understand by Carfield Yim on June 29 2006 07:33 EDT
- do I need hoople to tell me java frameworks suk by B C on June 29 2006 08:12 EDT
- enough micro frameworks by B C on June 29 2006 08:14 EDT
- Re: Hoople 1.0: Attribute-Oriented Programming for URL Logic by Steve Lewis on June 30 2006 09:18 EDT
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'?--> 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
- documentation about what that URL does
- additional declarative security
- pre/post conditions such as a "need to have a "newsItem on the request object" post condition. Any suggestions on ways to improve the documentation would be greatly appreciated.
i think not.
Does anyone really care about these mini half a--ed solutions anymore. Solve one tiny little problem and Im supposed to add it to my stack. NOT! GO AWAY ALREADY
This is actually a very interesting idea. I'll be checking it out.