Some JSF Portlet Notes

* Formatting notes: I use quotes to denote HTML tags in this blog.

* SRB and file system portlets (gridFTP, for example) would make good uses for JSF general listing/tree view
classes.

* The point is that both of the above have the same general abstract file view of life and so can be repeated.

* UISelectItems is potentially important, since it holds entire groups of values. The display of the values
seems to be tied to the component that surrounds it. For example, the HtmlSelectManyListbox always renders these
with "select" and "options" and "optgroups" if there are multiple values. There are several display objects
associated with these groups (select boxes, checkboxes, radios, etc.)

* HtmlDataTable is a just a "table" at its heart. But it does lots of fancy output--basically you can line up
your mutliple part data into columns and have JSF figure out the for loops.]

* But the question now is this: how do you need to extend HtmlDataTable goodness? Maybe you don't and the
whole issue is mapping this to a backing bean.

* Also, note again that the backing bean can be independent of the display. So for example a tree view of a
directory and a table view (as per current gridftp) are two different views. So a neat trick would be to
convert between one view and another.

* Another common data model may be the "user session data model" in which the user wants to navigate a
logical tree of results. This may be output as either tables with a top navigation link (as per gridftp) or
it may be the common tree view, or so on.

* So the currently unanwsered question is this: what is the data model for a big glob of results. If I do a
gridftp on a directory, how to I abstractly handle the results? That is, I have to map this into some
HTMLDataTable or Tree or something at some point in the future.

* Basic problem statement: portlets are good at some level, but they are not fine-grained enough. For example,
a job submission portlet is marginally useful since what you really want to do is make an application submission
portlet. A GridFTP portlet has some usefulness, but what you really want to do is collect all the files
(input, output, stdout, error, etc) into a single grouping and associate this with common GridFTP-like
tasks. That is, there is a logical filespace associated with a specific application. This may include other
stuff like metadata.

Similarly, SRB is a file system in its own right. So I need to be able to navigate this. But back to the
basic problem: how do I build an application page this way?

I cannot build a generic portlet that is an abstract version of a OGSA-DAI client. This doesn't have
much usefulness. Instead what I would like is a set of widgets and data models that can hold generic
OGSA-DAI stuff in them. These can then be used to build up specific OGSA-DAI application portlets.

* Another issue is this: how do I build up a workflow page? This is not really intended to be a workflow
composer but rather a lower level thing: I often need to associate the backend resources (code, data) with
each other. This is a common task.

* Yet another common job: need a list of all my jobs (past, pending, current, etc). This should be an
abstract view (an arbitrary collection) that gets mapped to a different view (tables, trees, etc.). These
view objects can be associated with events, where events (action events) are really COMMON GRID TASKS.

* So one can think of an ACTION EVENT LISTENER of type "run job" or of type "download file" or of type
"remove value", and so on. These are common actions. There can also be other action events associated with
a particular instance.

* Another possible use: the pages may be constructed using Sakai-like standard components for a common
look to everything. So we can adopt/modify this for a standard OGCE look.

* I think the problem with the current approach is that we confuse ACTIONS with PORTLETS. For example, the GRAM
portlet is really a single action portlet (for the most part): do the thing. GridFTP is a collection of actions
for remote file manipulation, and so on. In the current (velocity) set up, these actions are tied to specific
forms by name. But this is too rigid. I can't (for example) combine the action code a button to multiple
listeners.

* Some JSF virtues:
- Multiple views to same data: my GridFTP view can toggle between Tree and Table views.
- Reusable views for different data: GridFTP, SRB, Job Monitors, OGSA-DAI can all reuse my nift tree widget.
- Multiple event listeners on a single form. Compare this to Velocity, JSP, which basically have
1 action per form. Consider the problem of reusing the action code of a velocity portlet.
- Input form names are auto-generated, so you don't have to keep track of these or break your
portlet if you change names. Or, you don't have to adopt naming conventions to reuse your action
code. Consider again the Velocity example.
- Lots of built-in validators (for strings, ints, etc, or for ranges of values, and so on).
- We can create libraries of stuff: events, nifty display widgets, etc.

* Validators: can write custom validators to make sure that the user has a credential.