Cocoon Forms

Here is a small writeup on CForms usage. Again, nothing that can't be found in the documentation, just for personal reference:

First create a flowscript that loads the Form resource:
cocoon.load("resource://org/apache/cocoon/forms/flow/javascript/Form.js");

Next create a function that creates an instance of the Form class with a form descriptor as a constructor argument.
var form = new Form("registration.form.xml");

Now you will call showForm on your form instance and pass a display pipeline as a parameter. CForms will loop within the showForm function until the form validates (as per the form descriptor above):
form.showForm("registration-display-pipeline");

The display pipeline needs to have cform template code within it, typically namespace ft (http://apache.org/cocoon/forms/1.0#template); the form-template element with a continuation-id element within. It will also have cform instance code within it, typically having a namespace fi (http://apache.org/cocoon/forms/1.0#instance).
<ft:form-template action="continue" method="POST">
<ft:continuation-id/>
<fi:group>

The form action continue is caught by the pipeline, simply:
<map:match pattern="continue">
<map:call continuation="{request-param:continuation-id}"/>
</map:match>

The display pipeline needs to have the forms transformer applied to it. It should come before any of your GUI or i18n transformations (correct me if I'm wrong here) and obviously after the generate output described above.
<map:transform type="forms"/>

Finally you can do as you wish with the form model within Flowscript and send the user to a result page with the form model as a parameter:
var model = form.getModel();
var bizdata = { "username" : model.name }
cocoon.sendPage("registration-success-pipeline.jx", bizdata);

The success pipeline simply generates a jx file that takes "username" as a parameter.

Cocoon Authentication Framework

This may be a repeat from the documentation, but for my own reference here are the actions associated with the Cocoon Authentication Framework (CAF):

auth-login
This action attempts a login, it requires a username and optionally password to proceed; obviously it works like an action and you put the success page within the action and the failure page outside of it.

auth-loggedIn
This action will return true if a user is currently logged in to the CAF, and it is useful to put a redirect-to inside of for alternate views of pages. For example a landing page my have information about the service and a signup link, but redirect a user who is logged in to their home page.

auth-protect
This action will protect a page by requiring a user to be logged in to the CAF. It works like a normal action, nested map statements go within the action and are evaluated if there are valid credentials, and a redirect-to login page typically goes outside of it.

auth-logout
This action will log a user out of the CAF, in the example it is placed within an auth-protect but I'm not sure if it is required to be.

Each of these actions requires the parameter "handler," it does not matter what the value is as long as it is the same for all areas.

Look out soon for a Hibernate powered authentication writeup, as well as other Cocoon/Hibernate related articles.

J2EE MVC Options (as of 2002)

I purchased a book, Expert One-On-One: J2EE Design and Development, that was spoken very highly of in Amazon's customer reviews. Chapter 12 explains the MVC (model-view-controller) pattern at length and outlines three open-source options for web application development using the MVC pattern.

Struts
Struts seems to lack any key strengths in the opinion of the author, with its key weakness being that applications are tied to Struts and Servlet API. It also contains peculiarities in the way it populates beans such as inability to be useful for non-string values, and its almost completely concrete implementation.

Maverick
Maverick's key strengths are its display-agnostic ViewContext interface and "domification" (conversion of a Bean to a DOM document). Domification allows for easy integration of XML-based transformation pipelines and display technologies such as XSLT. The pipeline and domification are conceptually similar to Apache's Cocoon project, which is not discussed in this book.

WebWork
WebWork is the framwork the author seems to look most favorably upon. Its key strengths are its agnostic approachs to model construction (not depending on anything but the ActionContext in most cases), bean population and presentation technology. However, some drawbacks are that it ties requests to the Command pattern which may be inappropriate for some requests, and the separation of action from the Servlet API may be unrealistic for more sophisticated user interaction.

Popoon Hijacked!

Note: this article is a draft.

I stole Popoon and made it run Blocks created for my system natively, and use the templates created for them natively as well.

For those not familiar with Cocoon/Popoon, it is an implementation of MVC which uses pipelines to separate concerns of web applications. It was designed to use XML piplines to pass structured information between components, specifically actions, generators, transformers, and serializers.

My existing Block engine does much the same thing, but in a different way; it uses the idea of context, and each component adds its data to the context in a place specified by its parent. It offers extreme flexibility, however I was in the market to revamp the configuration format and make it more MVC-like, as it is currently built off prototype code and I have used it enough that it's getting time to make things concrete.

I have experience with Apache Cocoon and am quite impressed by the sitemap format in particular, however I am some doubts and gaps in my knowledge of its internals. I am also lacking any kind of design experience with Cocoon applications.

.......

Basically what I did was make Popoon's pipelines able to carry native PHP assoc arrays from generators to transformers. I wrote three simple components: block generator, phpassoc2xml and smarty transformers. Smarty takes an assoc array as an input, and my system currently uses Smarty templates for the display layer. So what I did was take code that works within my prototype engine and make it concrete within a more developed and stable engine. I may choose to transition away from blocks and smarty and toward generators and xslt, however with a few modifications I was able to hijack the entire popoon engine and make it run my existing code natively.