This Redwood tool sounds interesting. If only it were available on Sourceforge ;)

Redwood Layering and Form Management

This post addresses how modeling the model impacts the process of data creation, modification, and removal in the Redwood system. As we have already discussed, the unique feature of redwood is that it provides a way for you to represent your application model as a hierarchical tree of objects, each element in the configuration corresponding to a "branch" in your application tree. In this model, any application process can be broken down into a simple series of redwood branch creations, modifications, and even removals. So in the redwood view of the world, a business process (such a boring term) boils down to creating, modifying, and removing a series of branches in the redwood tree. And as previously discussed, the framework itself is responsible for verifying that the current user has the security clearence to take those various actions. The application is also able to extend the base functionality to include any additional processing, but it is the framework that is responsible for invoking all of this.

But as we consider the process of creating and modifying application data in the web environment, the fact that we have modeled the model in the framework gives us a great opportunity to put a lot of structure into HTML forms processing that would not be possible otherwise. This structure allows us to develop new application functionality very rapidly as it puts structure into our field validation, page re-rendering, and security checking.

The layers are the following:

HTTP Parameters (servlet API stuff)
---------------------------------
Redwood Task List
---------------------------------
Redwood Task (1 or many)
---------------------------------
Redwood Data Branch (1 per task)
---------------------------------
Java Bean
---------------------------------
Database row

The first step in this process is to transform from the servlet world into the Redwood world. There is a well-defined contract (perhaps a topic for another post) that allows the front and back ends to agree on what constitutes a task, and what parameters will be bound to that task. The RedwoodTask can be thought of as a mini-request object that contains a collection of key value pairs that will ultimately end up in the database. Once the tasks have been assembled, they are then validated. Task validation can take place in the framework, or in the application if the rules are more complicated than just "not blank, length < 20".

The great thing about having the task object as a holding area between the data branch and the unstructured request object is that it can hold the values in a type-free context during validation and then pass the values through to the Java bean if validation passes, or it can be used to re-render the entered values on the page if there are validation errors. That was a mouthful, so perhaps an example of how this is applied would be useful. Consider the rent field on Tribe apartment listings. We have included this as a free-form HTML text field on the front end, but before it goes into the database we need to make sure that the user has entered a numeric value for this field. When the form is submitted, the arguments are first organized into their individual tasks. The rent value is taken from the HTTP request and dropped into the apartment task. Then, a check is done on the rent attribute of the apartment task to see if the entered string contains only numbers. If so, the task is then transformed into a Redwood Data branch, and the attributes of the task are placed into a Java bean, which lives inside of the data branch. The last thing we need to do then is actually persist the change to the database. All RedwoodTask objects contain a mode setting describing what needs to be done to the underlying data branch: create, modify, or remove, or replace. Once the databranch is populated, the correct action API is called and the database reflects the desired result of this process.

If the task object wasn't there as a go-between and we tried to dump the parameters straight into data branches, then we would get a Java Exception when trying to put letters into a numeric data type. However, you could easily argue that I could just do the validation without bothering with a task at all. The great thing about having a task object is that if the validation fails I have a place where I can put a validation error message, and the framework can then use that object to re-render the form with the valued that I typed in previously along with a message explaining the error. This way, we are able to repopulate all of the values in the page including the erroneous ones, and allow you to correct your mistake and resubmit. There are many sites on the web that do this (obviously) but the Redwood framework brings a lot of structure to it, and consequently *not* a lot of application code. We never have to worry about coding the re-population logic, or directing back to the same page on form validation errors because it is a service of the platform.

Even better, having such a structure in place allows us to implement multi-page workflows quickly and easily, and in a stateless fashion. There is enough structure in the browser-server contract that a multi-page workflow (such as the flow for creating a new listing or event) can be automatically maintained by the framework without exerting any undue stress on the developer. Of course, there is stress associated with learning how to leverage all of these features, but the result is code that does the right thing and is very compact.

And in my world, less code = less bugs!

[ next: Redwood Search (I think) ]

Great stuff! Can't wait until the next installment.

Now that I have inundated you with words, I thought that I would show you a picture of what our redwood tree currently looks like. This picture, although it is a bit small to be readable, should give you an idea of the scope of the tribe.net application. Having a single document like this can be quite helpful in getting a 10,000 ft. view of a web application - it tells us at a glance the relationships between our application objects and gives insight into what people, listings, and tribes are capable of owning.

As an example of how this setup is useful, adding the blog functionality to the new pcard was simply a matter of making child branches for the articles, comments, and photos and the security issues as well as database code were automatically taken care of just by virtue of the fact that the branches are where they are in the tree.

This picture also splits the tree up into the major components: Listings, People, and Tribes.

Here is the picture:

louvre.tribe.net/tribe/upl...2859b122b6