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

[Steve F. <sfi...@pc...>]

Adrian, see below.

steve

Adrian Roy Tivey wrote:

>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?
>  
>
By "content" we mean all kinds of verbiage on the site.  The canonical 
example is the tutorials available on the EpconDB site 
(http://www.cbil.upenn.edu/EPConDB/).  The content is considered "model" 
not view.   The current implementation is Jonathan Schug's Page 
Generator, which is written in perl.  The model is stored in perl data 
structures, independently from any formatting information, and is 
formated by the PageGenerator.  Its not always obvious where to draw the 
line between model and view.  Another example would be that a home page 
might have Introduction, News, Funding, etc. that we would like to be in 
the model.  Obviously, in the new WDK, model is stored in Beans, and 
view is stored mostly in JSP.

By "dialog" we mean a form.  In the current WDK, the dialogues are 
specified declaratively in the servlet-config file.  They are often 
complex, with queries underlying pulldown lists, etc.  In the new WDK we 
were thinking we would have Dialog beans, or similar, to manage these in 
the model.

>  
>
>>  - configurable styles
>>    
>>
>
>ie given an query syntax tree the way this is displayed to the user should be
>easily modifiable, or something else?   
>
Bear with me here.  I still haven't read the JSP book yet.  But, the idea is for the JSPs to refer to a stylesheet or similar, so that we could potentially reuse JSPs across projects.   An example would be a JSP that formats a query dialog.  The JSP is the same between, say, allgenes and plasmodb, but the look is different because of the style configuration.  i am not clear on how this relates to the tiles.

>  
>
>>  - site's standard s surrounding page specific stuff (ie, your tiles 
>>solution)
>>  - JavaScript functionality
>>    
>>
>
>Server-side scripting or client side?
>  
>
client side.  we use this for example to provide mouse-over behaviour in 
some of our graphics.  

>  
>
>>  - 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.
>
I guess you are refering to the ReportMaker.  It is alive on the 
Allgenes site.  Do a query, and then press Download from the query 
history.  The code is in two places.  The backend is in cvs 
GUS/ReportMaker.  The frontend is still in our legacy CVS.

>
>  
>
>>  - 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.
>  
>
Angel has looked at Digester and got the sense that it was overkill.  i 
haven't looked at it yet.  we remain open-minded.

>>, 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?
>
>  
>
A Content fragment would be a JSP fragment that could show news items.

>  
>
>>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)  
>  
>
ok, lets keep that in mind.

>  
>
>>  - 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
>  
>