Re: [Gusdev-gusdev] Struts documentation - supporting evidence

[Adrian R. T. <ar...@sa...>]

Hello,

Thanks for your comments. Just a shortish email to expand on a couple of
points and request clarification on a couple of others (including comments on
the first three points but that's just the order they happened to come up!) 

> Adrian-
> 
> Angel and I have had a chance to meet and throw together our initial 
> ideas about a JSP/Struts based WDK.
> 
> My sense is that our thinking compliments what you layed out in your 
> Struts Demo.  Basically, we are buying into the ideas you presented 
> about how the display can work.  We are also interested in starting to 
> nail down the design of the underlying machinery (somewhat along the 
> lines of what you outlined in your conclusions section).  Much of our 
> thinking is informed by the current WDK design.
> 
> We drew up a quick list of big-ticket requirements items, some addressed 
> by your proposal and some not:
>   - declarative specification of content, queries, dialogs.

I follow the middle one. I'm not sure what you mean by dialog and especially
content through the email. Could you give a rough outline of the Content bean?

>   - configurable styles

ie given an query syntax tree the way this is displayed to the user should be
easily modifiable, or something else?   

>   - site's standard s surrounding page specific stuff (ie, your tiles 
> solution)
>   - JavaScript functionality

Server-side scripting or client side?

>   - calls to external resources (eg, processes) to provide stuff like 
> graphics
>   - boolean queries
>   - history
>   - report maker

Is there a current implementation in one of the current GUS sites or a spec
somewhere? It's been mentioned at this end but I don't think we ever went into
it in much detail.

>   - batch submission
>   - connection pooling
>   - process pooling?
>   - result caching
>   - result paging
>   - error handling
>   - dialog validation
>   - logging
> 
> We sketched the following top level Beans, which we see being configured 
> in config files (XML is fine... not sure yet about Digester)

I only suggested that because that's what's used by Struts. Played with it a
 bit more now and it seems simple to use for what we'd want. But yes, there's
any number of mature, open-source XML/Beans alternatives we could go for instead.

>, and which 
> do not specify any formatting information:
>   - Dialog  (eg, a form)
>   - QueryDialog (a subclass of Dialog)
>   - other subclasses of Dialog?
>   - Record (eg, an RNA page and/or detailed page)
>   - ResultSet (or is this just a record?)
> 
> These guys have properties, which, are also beans, of types:
>   - Content
>   - SqlQuery
>   - Process
> 
> And, SqlQuery and Process have as properties subclasses of Param, which 
> is also a bean.
> 
> The main difference between the beans we see for the new WDK and those 
> in the old WDK is that the new ones don't include any formatting 
> information.  I think that means that we can have siginificantly fewer 
> classes, because the classes don't have to differentiate based on 
> formatting implementations.
> 
> Based on our still rudimentary understanding of JSP, we imagine these 
> kind of pages and fragments, which are somehow parameterized by the beans:
>    - Dialog
>    - QueryDialog
>    - ResultSet
>    - Record
>    - Record Details
>    - Content

I suspect we may be thinking of two different things but not sure. What kind of
thing would content be as a page or page fragment wrt a Content bean?


> Things we are assuming JSP can do (haven't read the book yet), and want 
> to understand more about:
>   - bind beans to a JSP page

Yep. jsp:useBean to tie a JavaBean to a page local variable. We have to decide
on a schedule and how cutting-edge we want to be. The syntax becomes even
clearer with JSP2.0 (eg Tomcat 5) but support for that is still at alpha/beta
for many containers. (There *should* be a stable implementation in ~December for
the official release of J2EE 1.4 so personally I don't think it's unreasonable
choice)  

>   - simple control features like iterate across a list of results to display

Not part of JSP per se but there is a standard template library that includes
simple iterators, control flow etc. See geneResults-body.jspf for an example

>   - fetch JSP fragments to insert (eg, one per row of a result)

? Not sure I understand. There are two built-in include mechanisms but for a
table of results you'd generally write the formatting code eg table tags as a
template and insert the data into that. For the specific case of the
CellFormatter there is a working tag library equivalent in the demo. 
 
> As far as the config files are concerned, we agree that huge config 
> files are not optimal.  We don't yet see how best to organize them, 
> though we want to be able to re-use some of them across projects.  So, i 
> think they will need to find there way into a directory structure of 
> some kind.
> 
> Steveo

Adrian