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

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

Adrian-

i am only going to address one point now, pending more time to review 
and learn.  that said, on the whole, this looks very good.

i would like to address, point (1), the build system and the directory 
structure.  your answer below says "the dir struct is self contained, 
and we're using ant, so no prob."   i am not quite sure if you mean (a) 
that therefore we can use the dir struct you have with the build sys, or 
(b) it would be easy to rearrange it to conform.  if case (a), i'm not 
sure i see compatibility here: the dir struct has many of the same 
elements of those that we use in GUS, but, they are arranged 
differently.   i should mention that i do think it would be very easy to 
stuff this kind of thing into our dir struct, but, since i don't have a 
thorough comprehension yet, perhaps not.

a subpoint of that point:  you say below that you envision overlaying 
files to acheive customization.  I think i want to hear more about 
that.  my concern is that overlaying violates good subclassing 
practice.  in particular, if i overlay code, then i have to duplicate 
the "base" code in my customized version that i still want.

steve

Adrian Roy Tivey wrote:

>Hi Steve,
>
>I'll reorder your original email a bit - hope that's OK.
>
>I'll try and tie up the high level objectives with the Struts document to see
>how much far we meet them and what needs further discussion.
>
>  
>
>>on the assumption
>>    
>>
>
>Absolutely - just a proposal
>
>  
>
>>that Struts will be a good framework for us, i would 
>>like to step back and ask us to state what our objectives are.  on our 
>>side, we are thinking that this will become the next version of the GUS 
>>Website Development Kit. 
>>    
>>
>
>Sounds good
>
>  
>
>>If that is so, then here are some possible objectives that come to mind:
>> 1. work within the GUS build system
>>    
>>
>
>The proposal has a self-contained directory structure and the build mechanism is
>based around ant so shouldn't be any major problems there.
>
>  
>
>> 2. creation of a default website (bravo on your effort here)
>> 3. all the session stuff we might need
>>    
>>
>
>Not considered too much. As I understand it you're keen to move some session
>info into the database so other languages can access it. Will this be on a case
>by case basis or will all the session info be in the DB? Will it be cached in
>the HttpSession object? Either way the Struts actions have access to the
>Session object and a db connection pool... 
>
>
>  
>
>>I don't know how familiar you guys are with our current WDK (it is not 
>>in the sanger cvs). 
>>    
>>
>
>Yep. We've looked at it, liked it and reused it! See:
>http://www.genedb.org/gusapp/servlet?page=boolq
>
>  
>
>>In addition to handling all the session stuff, its 
>>most important feature is a big fat config file )per site) which goes a 
>>long way to using a declarative approach to specifying the details of 
>>the site and its queries.  I have attached one of these files, 
>>dotsgenes-config.in.  This file specifies the Allgenes.org site.  You 
>>will find that it contains about 100 queries, which is how many are used 
>>on the site (excluding those that are hard coded into java code for 
>>various snazzy graphics).  In many cases, the entries in this file 
>>completely specify a query or result page by declaring parameters to the 
>>underlying dev kit classes.
>>    
>>
>
>The declarative approach really appeals. (The only negative point was the
>complexity of the config file or perhaps more the size of it which was quite
>daunting when we first looked at it). The proposals about querying etc all
>assume basically the current CBIL model for querying. It just points out areas
>which could be modified or extended based either on (4) or our experiences of
>modifying it to make it organism specific.
>
>
>  
>
>> 5. some kind of abstraction of query pages that allows us to separate 
>>the sql from layout considerations (and also the sql used to populate 
>>and or construct pulldowns
>>    
>>
>
>In the demo the queries are just in a properties file. Again I think CBIL is
>planning to move to XML so off the top of my head the allgenes functional Go
>query becomes something like:
>
><query id="gbFuncGO">
>   <class>SqlQuery</class>
>   <description>GO functional classification</description>     
>   <abbrev>go function</abbrev>
>   <sql>
>select distinct pa.na_sequence_id
>from dots.GOAssociation ga, allgenes_60.ProteinAssembly pa, dots.ProjectLink pl
>where ga.go_term_id = $$0$$
> and ga.table_id = 180
> and ga.row_id = pa.protein_id
> and pa.taxon_id $$2$$
> and pa.na_sequence_id = pl.id
> and pl.project_id = @PROJECT_ID@
> and pl.table_id = 56
>   </sql>
>   ...
>   <params>
>      <param id="goFunctionP">
>      <param id="reviewedGOP">
>      <param id="taxonIdP">
>   </params>
></query>
>
>
><param id="goFunctionP">
>    <class>SingleSqlEnumParam</class>
>    <description>Gene Ontology consortium cellular function ontology</description>
>    <prompt>GO Function:</prompt>
>    <indent>...</indent>
>    <query>
>select gt.go_term_id, substr(gt.name, 0, 50) as name
>from sres.goterm gt
>where gt.external_database_release_id = 6918
>order by substr(gt.name, 0, 50)
>    </query>
></param>
>
>ie a fairly straight translation. (Note the SingleSqlEnumParam is just like a
>SqlEnumParam except it takes both it's label and value from the single query).
>There's still a query factory (although there's now also a ParamFactory too as
>the values/labels may vary due to organism)
>
>A custom tag eg <gus:query id="gbFuncGO" /> would look up the query, work out
>what parameters are needed and display them much as now. So to that extent the
>layout is still in Java. But that's already pretty well abstracted behind the
>DialogFactory so it should be fairly easy to plug-in an alternative. (But how
>many ways are there to represent eg a drop-down list in HTML!)
>
>
>  
>
>> 6. some kind of abstraction to specify queries that are used to 
>>generate result pages
>>    
>>
>
>Basically the same mechanism as now and as in (5). Specified in a config file.
>The difference is that a query currently queries store a ResultFormatter which
>in turns specifies the table layout, the cell formatting etc We'd turn that on
>it's head slightly. A query would have a (default) target which Struts maps to a
>particular page. The infrastructure basically returns a ResultSet to that page
>which can extract and display whatever info it likes, however it likes.
>
>Again the page designer decides which CellFormatter to apply (using the custom
>tag library). To be clear I don't think the curators need to able to create this
>kind of page from scratch, although they should probably be able to look at the
>source and understand enough to eg remove a column or swap two around or add
>explanatory text to the page.
>
>  
>
>> 7. support for the boolean and history modes
>>    
>>
>
>If the result set download are viewed as a seperate operation the history page
>is really like any other query/result page.
>
>The boolean is the difficult one. The short answer is it doesn't change
>substantially which appears to defeat (4) but the amount of logic far outweighs
>the amount of presentation code. I'll try and expand on this later.  
>
>  
>
>> 4. use of JSP to separate layout from content
>>    
>>
>
>Absolutely
>
>  
>
>>steve
>>    
>>
>
>A.
>  
>