Introduction to the CyberWebForm
CyberWebForm (abbrev. WebForm) is a model-view-controller architecture for J2EE web application development by utilizing XML technologies.
WebForm architecture uses XML as data model and HTML pages as presentation layer. Developer can first use HTML and XML to engage rapid prototyping. This is done by
- Make a HTML markup with fake some data inside
- Extract XML data from HTML presentation layer.
The extraction process allows rich-control presentation in XML. That is, you can use XML to represent an edit control, single select control, multiple select control, date chooser control, and many others.
For a complicated web page, adding content to do more complex markup usually takes time. But extracting data into XML can ease the work. Because you can define the presentation first and then modify data in XML. The change will be reflected to the presentation layer immediate after your modification in XML.
This is something like XSLT, for those who knows about. But XSLT comes with some major problems that stop it from being widely adopted:
- In lack of a good development tool: XSLT requires an initial translation from HTML into XML, which is,
by all means, not-trivial. You have to use some tool like "TIDY". The translation is neither one-to-one
nor reversible. Templates that has been made in XSLT cannot be loaded into authoring tool such as Dreamweaver. This makes maintaining the presentation layer impossible.
- XSLT is a programming language rather than a markup language: Learning XSLT is hard. It requires skill of an experienced programmer. Art designer cannot takes the work at any part except for making the initial markup. Programmer must takes all other works, including translating HTML into XSLT, maintaining the XSLT, and generates the XSLT. If
the process is so complicated, why not just let programmers use JSP to generate HTML?
- XSLT is one way rather than two way: XSLT can only translate XML into HTML. What it cannot do is to translate user inputs back into XML. This is important, because currently when program wants to receive user input, you have to write ugly codes to parse CGI parameter. Why not extract the data directly from XML?
Later the Struts emerged from Open Source community, but comparing with WebForm architecture, Struts has the drawbacks:
- Page linkage is not entirely separated from program logic. Each modification of page linkage requires an additional modification in struts-config.xml. Each forward pages has to be defined. The programmatic logic is still a little "too" aware of the presentational changes.
- Page relationship is stored somewhere else than the original page.
When you need to see the relationship between page to page, you have to view
a struts-config.xml. The content designed as a
group of pages cannot be easily reused. There are some
difficult-to-understand stuff, which are also part of the view content,
stored in a strange place.
Now lets see the features provided by the WebForm architecture:
- Uses tags to map XML into HTML: The architecture uses tags to map XML into HTML. This procedure do not require the translation from HTML into XML. All you needs to do is to insert tags into appropriate positions.
- Bi-directional translation: Once the tag defines the mapping between XML and HTML, the translation will proceed in both ways. This means user-input will be reflected into appropriate XML nodes. This is done by predefined XForm handler. You can, of course, write your own re-usable XForm handler to perform custom translation.
- Rich and pluggable control sets: There are some predefined controls, such as single line edit, check-box, single-select, multi-select, date chooser, toggle-button, and others.
- Multi-layer bi-directional XML translation: The translation between XML and HTML can also be applied to XML and XML. This means you can translate one kind of XML into another. And the translation is still bi-directional. Modification made in one-side is directly reflected to another. This is done by XML node reference identifier. By utilizing this technique, you can build reusable XML forms and keep programmatic relevant XML's to minimum information needed.
- Logging runtime configuration support: There is a pre-implemented logging configuration user-interface, written in WebForm architecture. It can adjust the setting of Log4J at runtime while web server is running.
- Xsnipplet and Velocity simplifies the linkage between the controller
and the model: By utilizing Xsnipplet (small and simple program
written in XML) and Velocity engine, the interface between XML and the
controller logic can be very flexible and powerful, while extremely simple.
Library Dependencies
It is important to understand that WebForm architecture is a conceptually
revolutionary architecture, rather than merely an implementation. What I have
provided here is only one kind of implementation. In Java, it's more easily to
implement some hard and complex ideas. But the same architecture can also be
used if you are using other programming languages.
In WebForm Java implementation, the following libraries is required at
runtime
- JDOM
- Jaxen (XPath library)
- Log4J
- Apache Commons Lang 1.0
- Apache Commons Collections 1.0
- Apache Velocity 1.3
Mission
- Reduce web application development cost.
- Confirm requirement with customer by "rapid prototyping".
- Separate (really) view from models. Separate models from controllers. It is very possible that you replace the entire user-interface (web pages) without having to modify any XML or code.
- If is possible that in the future, you can even switch language (i.e. PHP or Perl). Of course when you do the language switch you needs to rewrite all code but not views and models. They are completely reusable.
Documentation
Related resources