(NOTES FOR A PRESENTATION FRAMEWORK)
1. ELEMENTARY CONCEPTS.
1.1.1. A visual representation of all data within a response to an HTTP request.
1.2.1. Any business intelligence required by a page.
1.3.1. All page data related to a process.
2. DERIVED CONCEPTS.
2.1. ABSTRACT WIDGET.
2.1.1. An abstract Java class representing a widget unrelated to its process.
2.2. CONCRETE WIDGET.
2.2.1. A concrete Java class representing a widget.
2.3. WIDGET INTERFACE.
2.3.1. A Java interface with the getter methods generated by XMLC for all DOM elements used by a widget.
2.4. PAGE INTERFACE.
2.4.1. A Java interface that extends the widget interfaces used by all widgets within a page.
2.5. ABSTRACT PAGE.
2.5.1. An abstract Java class that implements a page interface to use a variety of abstract widgets.
2.6. CONCRETE PAGE.
2.6.1. A concrete Java class that inherits from an abstract page to provide its concrete widgets.
3.1. HTTP CYCLE (REQUEST AND RESPONSE).
3.1.1. Handling an HTTP request involves instantiating a concrete page. Each concrete page uses a variety of concrete widgets. These concrete widgets are capable of rendering themselves as well as getting their own data. Each one uses a subset of the getter methods in the page interface for getting the DOM elements used in rendering itself as well as any available data retrieval API for getting data.
3.1.2. Each concrete widget receives a widget interface implemented by an abstract page. However, as it is really the concrete page that gets passed to all concrete widgets within a page, the page interface an abstract page implements has to extend all widget interfaces used by all of its abstract widgets. It may address this by extending other page interfaces as well. So any concrete page has to instantiate XMLC generated classes implementing each one of the widget interfaces its page interface extends because of the getter methods in them.
3.1.3. Rendering a widget means building part of the DOM tree representing a page. Thus a concrete page generates a response only after all of its widgets render themselves. Issues as look and feel and presentation format are handled in part by XMLC, as described in Nick Xidis’ article Enhydra Design Patterns for ASPs, upon which this framework is largely based. Other issues as DOM generation according to a Java interface are handled totally by XMLC, also as described in Nick Xidis’ article.
3.2. PAGE INTERFACE IMPLEMENTERS.
3.2.1. Each widget interface implementer is a Java class generated by XMLC from a document, for example, an HTML page. This class contains a DOM tree representing the document. In addition, XMLC generates a getter method for each page element identified by an “id” attribute. So the page interface implemented by a concrete page has all getter methods its XMLC generated classes must have, providing compile time checking for page templates.
3.3. ABSTRACT WIDGETS BUILDING.
3.3.1. Abstract widgets can be built on top of Barracuda’s component model. One can write abstract widgets as wrappers to Barracuda’s components, so it gets easy to replace the underlying component model if needed. Barracuda’s components have the ability of rendering different document formats, as HTML, XML etc. They can be used in combination with Barracuda’s event model, another nice Enhydra contribution.
Why is this easier than just learning HTML and JSP?
That question should drive the creation of any web framework, and it is not addressed here at all. Learning some special-sauce XML DTD takes time and effort, and it had better pay off. As someone who has managed people who used (and myself used) whiz-bang XML-based web frameworks on several occasions, I can say that it probably won't pay off, and you will find yourself saying "I can do this with JSP/HTML, but not here. Why?". Additionally, you will have a hard time getting your average HTML programmer to be able to deal with proprietary XML and a event-driven model that is different from the normal web simple request/response model.
HTML and JSP are published specs that are widely known, flexible and easy to learn. Thus, users of these technologies do not need to be expensive Java programmers. How many Java programmers want to deal with front-end presentation? Almost none. They should be used on the server-side, with cheaper HTML programmers doing the front end and perhaps one server-side guy as liason. Using some XML-based (or whatever-based) web framework complicates the process and requires Java programmers (or other expensive programmers) at every step of the way.
Why not just use the features of JSP and HTML to accomplish what you want, perhaps making some simple custom tags to achieve code re-use? It's simple, straightfoward, easy to learn, and easy to maintain.
XML is for communicating between disparate systems, not for junking up the process and communication of an entirely Java-based system.
I really don't think your comments apply to all web frameworks rather they seem to be directed at XML-based frameworks alone.
The main reason to use a framework is to not have to recreate certain reusable elements. For example, a good framework will probably provide form validation, i18n support, integration with other important technologies, etc. There are frameworks which are designed to be used directly with JSP (i.e. Struts, WebWork, Turbine, etc.) Other frameworks pick other template languages but still provide the same types of services while others (such as Barracuda) break the mold and do something completely different. Regardless of the approach all frameworks are designed to reduce the amount of coding necessary to build web apps. You can rewrite everything from scratch all the time, but that sure does seem like a waste.
If you are interested in learning more about the different frameworks available then check out the Wafer Project
. Wafer project is an attempt to provide a common means for comparing and contrasting the many open source Java web frameworks which are currently available.
I am currently using a combination of XMLC, Barracuda, and Struts for an application at work. As someone who's worked extensively with web-apps this has been like a dream come true. First of all, there is no xml to learn. If you are a developer and have done anything with the DOM there isn't anything new here. Well, you have to learn to type java org.enhydra.xml.xmlc.commands.xmlc.XMLC -keep <anypage>.html. That's how you compile the HTML pages into actual classes. Secondly, this is the only "framework" that absolutely seperates code and presentation. There is not a spec of code in any HTML pages. That right there would make this worth it. And thirdly, as a Java programmer, there is nothing new that I have to learn. The HTML guy gives me a page, I compile it and then I'm not trying to figure out where to put a hunk of scriptlet code that I won't remember anything about two months later. I have a documented class with DOM handles that is easily manipulated using things that I already know.
Just a quick comment on the
"HTML and JSP are published specs that are widely known, flexible and easy to learn. Thus, users of these technologies do not need to be expensive Java programmers. How many Java programmers want to deal with front-end presentation? Almost none. They should be used on the server-side, with cheaper HTML programmers doing the front end and perhaps one server-side guy as liason. Using some XML-based (or whatever-based) web framework complicates the process and requires Java programmers (or other expensive programmers) at every step of the way."
The first sentence is true. The second sentence is not quite as correct. Those inexpensive HTML people are inexpensive because they don't know Java, that's why, in the real world, you end up with the HTML people at your desk every 20 minutes asking you how to get a piece of code in their page to work. My answer to your third question about dealing with front-ends is none, and that's the beauty of XMLC. To direct one comment to the rest of the paragraph, you have Java developers involved in every step of the way regardless.
I, as a long-time professional developer who gets paid to write code, love XMLC and Barracuda. I hope to never, ever have to use JSP again. It's just not a maintainable resource IMHO.
The problem with this is that XMLC doesnt actually preserve exactly what the html coder wrote - it runs it through jtidy first. On some browsers, we found this could result in visible, ugly layout changes.
I totally agree that web designers shouldnt be made to edit jsps though. We try to achieve this too, but using our own mechanism.
In our development I wrote a lax html parser ant task to convert all our html to jsps with struts tags, the key goals being that the html the jsp generates is 100% identical to the original html, and that the static site works 'out of the box' converted to a dynamic site (ie we rewrite links too). Regions marked up with id attributes are extracted into separate jsps and can be replaced at build time with custom jsps using the struts tiles mechanism.
This works pretty well, although we're moving away from the id attributes - as our web designers use dreamweaver, it turns out to be a better fit to our toolset to extract dreamweaver 'library items', and 'writable areas' in their templates.
Are the 2002 comments still true today?
I'm building a new application and now researching the best platform to use. Any Comments?