gusdev-gusdev

[Gusdev-gusdev] Struts documentation

[Marie-Adele R. <ma...@sa...>]

Hi,

I've attached the discussion document on a Struts/JSP framework (finally).
There's a quick guide to it's contents at the beginning. We'd appreciate any
comments on this, via the list, and in particular the work plan in the
conclusion section.

Thanks,

Adrian

Re: [Gusdev-gusdev] Struts documentation

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

Folks-

thanks alot for making the demo and sending along the doc.

can you send us a link to the demo pages?

on the assumption 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. 
If that is so, then here are some possible objectives that come to mind:
 1. work within the GUS build system
 2. creation of a default website (bravo on your effort here)
 3. all the session stuff we might need
 4. use of JSP to separate layout from content
 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
 6. some kind of abstraction to specify queries that are used to 
generate result pages
 7. support for the boolean and history modes

I don't know how familiar you guys are with our current WDK (it is not 
in the sanger cvs).  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.  

steve


Marie-Adele Rajandream wrote:

>Hi,
>
>I've attached the discussion document on a Struts/JSP framework (finally).
>There's a quick guide to it's contents at the beginning. We'd appreciate any
>comments on this, via the list, and in particular the work plan in the
>conclusion section.
>
>Thanks,
>
>Adrian
>
>
>
>  
>

Re: [Gusdev-gusdev] Struts documentation

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

> Folks-
> 
> thanks alot for making the demo and sending along the doc.
> 
> can you send us a link to the demo pages?

If you want to be awed and impressed by a computer ... you should probably go
out and watch Terminator 3. In the meantime we have a very simple demo for you.
This was put together jointly by the PSU developers. It's main purposes were to:
a) convince ourselves that we wanted to recommend Struts
b) demonstrate how little code it takes to provide different looks using Tiles
c) try out directory structures, build mechanisms etc

http://dev.genedb.org/demogenedb/

The site should behave identically with three different looks. These can be
chosen from the front-page. There are two query pages. The first one allows you
to choose an organism, number of rows and any one of a choice of three queries
(wow!), one of which deliberately causes an uncaught SQL exception by requesting
a non-existent column. These should lead you to a results table, styled
appropriately for the look. The second form demonstrates the Validator mechanism.

The navbar and footer links are just cut'n'pasted from their respective sites so
probably won't work. Personally I think the plus points of the demo are the
small amount of code to generate the different looks and the custom tag libs eg
for the row colouring and cell formatting.

Please note:
a) The code behind the site is available through webcvs, link on front page
b) It's running on our dev. server so may be unavailable from time to time
c) The TMM query does work but very, very slowly ie go and make a cup of coffee
timescales. (It's using an old version of the SQL query rather than an optimised
version Arnaud wrote)

Please mail any problems with it.

Further emails coming...
Adrian

Re: [Gusdev-gusdev] Struts documentation

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

move over Pixar.

looks good.  how many of the objectives that we have stated do you think 
your demo addresses?

to the extent that it doesn't address all, maybe we should draw up a 
second round design doc organized by the objectives??

steve

steve

Adrian Roy Tivey wrote:

>>Folks-
>>
>>thanks alot for making the demo and sending along the doc.
>>
>>can you send us a link to the demo pages?
>>    
>>
>
>If you want to be awed and impressed by a computer ... you should probably go
>out and watch Terminator 3. In the meantime we have a very simple demo for you.
>This was put together jointly by the PSU developers. It's main purposes were to:
>a) convince ourselves that we wanted to recommend Struts
>b) demonstrate how little code it takes to provide different looks using Tiles
>c) try out directory structures, build mechanisms etc
>
>http://dev.genedb.org/demogenedb/
>
>The site should behave identically with three different looks. These can be
>chosen from the front-page. There are two query pages. The first one allows you
>to choose an organism, number of rows and any one of a choice of three queries
>(wow!), one of which deliberately causes an uncaught SQL exception by requesting
>a non-existent column. These should lead you to a results table, styled
>appropriately for the look. The second form demonstrates the Validator mechanism.
>
>The navbar and footer links are just cut'n'pasted from their respective sites so
>probably won't work. Personally I think the plus points of the demo are the
>small amount of code to generate the different looks and the custom tag libs eg
>for the row colouring and cell formatting.
>
>Please note:
>a) The code behind the site is available through webcvs, link on front page
>b) It's running on our dev. server so may be unavailable from time to time
>c) The TMM query does work but very, very slowly ie go and make a cup of coffee
>timescales. (It's using an old version of the SQL query rather than an optimised
>version Arnaud wrote)
>
>Please mail any problems with it.
>
>Further emails coming...
>Adrian
>
>
>-------------------------------------------------------
>This SF.Net email sponsored by: Free pre-built ASP.NET sites including
>Data Reports, E-commerce, Portals, and Forums are available now.
>Download today and enter to win an XBOX or Visual Studio .NET.
>http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
>_______________________________________________
>Gusdev-gusdev mailing list
>Gus...@li...
>https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev
>  
>

Re: [Gusdev-gusdev] Struts documentation - objectives

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

Quoting Steve Fischer <sfi...@pc...>:

...
> on the assumption 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. 
> If that is so, then here are some possible objectives that come to mind:
>  1. work within the GUS build system
>  2. creation of a default website (bravo on your effort here)
>  3. all the session stuff we might need
>  4. use of JSP to separate layout from content
>  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
>  6. some kind of abstraction to specify queries that are used to 
> generate result pages
>  7. support for the boolean and history modes


We had a similar list but I can't recall it at the moment. The only ones I
remember not covered above are:
8. Make it feasible for the curators to maintain their own pages for eg news
9. Be able to integrate third-party services (for some definition of integrate)

Adrian

Re: [Gusdev-gusdev] Struts documentation - objectives

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

I would like to add an objective:
  - an abstraction of form parameters.  Here at CBIL we have a system 
called CSP (originally "CBIL Style Police") which abstracts data types 
like Doubles, Enums, Trees.  It constructs the dialogue fragment to dump 
into a page, provides help text, and validates the input.


Adrian Roy Tivey wrote:

>Quoting Steve Fischer <sfi...@pc...>:
>
>...
>  
>
>>on the assumption 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. 
>>If that is so, then here are some possible objectives that come to mind:
>> 1. work within the GUS build system
>> 2. creation of a default website (bravo on your effort here)
>> 3. all the session stuff we might need
>> 4. use of JSP to separate layout from content
>> 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
>> 6. some kind of abstraction to specify queries that are used to 
>>generate result pages
>> 7. support for the boolean and history modes
>>    
>>
>
>
>We had a similar list but I can't recall it at the moment. The only ones I
>remember not covered above are:
>8. Make it feasible for the curators to maintain their own pages for eg news
>9. Be able to integrate third-party services (for some definition of integrate)
>
>Adrian
>
>
>
>
>
>  
>

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

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

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.

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

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

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

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

I think (b). We deliberately tried to limit the number of dependancies in the
demo so didn't try and integrate it into the GUS build mechanism, which I
haven't got in front of me. I would guess the src and lib directories (any
others?) should be merged into the existing dir. structure. The rest is really
website specific so should probably go into a new (file-system) branch, wdk or
something. Does this sound reasonable?  


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

Although the docs. didn't make it clear we're not really thinking about
overlaying the code. As you say there are already mechanisms for reusing it
while still extending and/or modifying its behaviour (either by inheritance or
delegation). But there are no similar mechanisms for images, layouts, JSP pages,
query config files etc. So it's those that people can override by overlay. (One
slight extension - if we have an XInclude processor we can potentially split the
various XML config files into sections so that other sites can include shared
sections they want without cut'n'pasting.)

> 
> steve

A

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

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

ok, sounds good on both points.

steve

Adrian Roy Tivey wrote:

>>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.
>>    
>>
>
>I think (b). We deliberately tried to limit the number of dependancies in the
>demo so didn't try and integrate it into the GUS build mechanism, which I
>haven't got in front of me. I would guess the src and lib directories (any
>others?) should be merged into the existing dir. structure. The rest is really
>website specific so should probably go into a new (file-system) branch, wdk or
>something. Does this sound reasonable?  
>
>
>  
>
>>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.
>>    
>>
>
>Although the docs. didn't make it clear we're not really thinking about
>overlaying the code. As you say there are already mechanisms for reusing it
>while still extending and/or modifying its behaviour (either by inheritance or
>delegation). But there are no similar mechanisms for images, layouts, JSP pages,
>query config files etc. So it's those that people can override by overlay. (One
>slight extension - if we have an XInclude processor we can potentially split the
>various XML config files into sections so that other sites can include shared
>sections they want without cut'n'pasting.)
>
>  
>
>>steve
>>    
>>
>
>A
>  
>

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

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

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.
  - configurable styles
  - site's standard s surrounding page specific stuff (ie, your tiles 
solution)
  - JavaScript functionality
  - calls to external resources (eg, processes) to provide stuff like 
graphics
  - boolean queries
  - history
  - report maker
  - 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), 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

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
  - simple control features like iterate across a list of results to display
  - fetch JSP fragments to insert (eg, one per row of a result)

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.

Steve

Adrian Roy Tivey wrote:

>>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.
>>    
>>
>
>I think (b). We deliberately tried to limit the number of dependancies in the
>demo so didn't try and integrate it into the GUS build mechanism, which I
>haven't got in front of me. I would guess the src and lib directories (any
>others?) should be merged into the existing dir. structure. The rest is really
>website specific so should probably go into a new (file-system) branch, wdk or
>something. Does this sound reasonable?  
>
>
>  
>
>>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.
>>    
>>
>
>Although the docs. didn't make it clear we're not really thinking about
>overlaying the code. As you say there are already mechanisms for reusing it
>while still extending and/or modifying its behaviour (either by inheritance or
>delegation). But there are no similar mechanisms for images, layouts, JSP pages,
>query config files etc. So it's those that people can override by overlay. (One
>slight extension - if we have an XInclude processor we can potentially split the
>various XML config files into sections so that other sites can include shared
>sections they want without cut'n'pasting.)
>
>  
>
>>steve
>>    
>>
>
>A
>  
>