gusdev-gusdev — Topics concerning GUS development

[Gusdev-gusdev] gus installation problem

[sam w. <gus...@ya...>]

Hi, there,
 
when I install gus (schema 2), I meet the following problem:
 
[exec]DBI subclasses 'GUS::ObjRelP::DbiDbHandle::db' and ::st are not setup, RootClass ignored at /home/oracle/gus_home/lib/perl/perl/GUS/ObjRelP/DbiDatebase.pm line 152

I don't know the reason and how can I reslove it.
 
my os is red linux 7.2. database is oracle 9i, perl is 5.8.0, ant is 1.5.3.
 
thank you very much!
 


---------------------------------
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software

[Gusdev-gusdev] Re: import statement policy

[Jonathan C. <cra...@pc...>]

Steve-

By the way, there are certainly others who believe import .* is bad.  See, 
for example, this page (from someone who has written a utility to expand 
import statements):

<http://javadude.com/tools/importifier/>

This person makes the statement that "Import on demand is pure, 
unadulterated EVIL." and then gives three arguments to back it up:

>    * If you use a name that exists in more than one package, the Java 
>compiler cannot determine which fully-qualified name to use. You need to 
>specify the full qualification yourself.

True, but that's OK so long as the total time you spend doing this is less 
than the time you save by using import .* in the first place.  Plus, in 
most cases the programmer will be aware of ambiguous class names and will 
avoid using .* in those cases.

>    * If a name is currently unambiguous (exists in only one package that 
>you specify via import-on-demand), someone could add the same name to 
>another package and your program will no longer compile.

This is a very good point.  However, costs are incurred whenever code on 
which you depend is changed.  For example, if that same person had instead 
changed the definition of an interface or renamed an existing, your code 
would also not compile.  That's just life.

>          o Note that this happened with the Java2 platform. Originally, 
>the List class existed in package java.awt. In Java2, Sun added a new 
>List class to the java.util package. If your program imports java.awt.* and 
>java.util.*, and uses List, it will compile in JDK 1.1 but not in the 
>Java 2 platform!

This is the same as the previous argument, and although I agree it's a 
terrible "feature" from a theoretical standpoint, in practice it's just 
not that big a deal.  I certainly agree that production/released code 
should use fully-qualified imports, but while it's under development I 
think a certain amount of laziness is a good thing.

>    * If someone is reading your code, they need to check in each 
>specified package to see which contains a referenced class Foo.

Or, they could do one of the following things:
  1. Run the code through a program that will do it for them.
  2. Use etags or JDE or a similar feature to look up class names.
  3. Read the JavaDocs for your program before looking at the code.

Jonathan

[Gusdev-gusdev] Re: import statement policy

[Jonathan C. <cra...@pc...>]

Steve-

On Sat, 2 Aug 2003, Steve Fischer wrote:
> This file refers to a bunch of classes that are new to me, and, as i am 
> trying to understand what is going on, i have to go visiting.  But, each 
> time i do so, i have to wade through all those packages to try to figure 
> out where the class lives in order to visit it.  sometimes i can guess, 
> and sometimes i can't

What development environment are you using?  At least in emacs, you can 
use the standard etags package, or something fancier like JDE, both of 
which should allow you to find all possible definitions of an unqualified 
class name with a mouse click or two and a couple of keystrokes.  This 
should be as fast as, if not faster than, scrolling to the top of the file 
to find the relevant fully-qualified import statement, particularly when 
you add in the amortized cost of maintaining a correct minimal list of 
fully-qualified includes (preferably in lexically-sorted order -- see 
below).

Perhaps we should ask the following question: why does Java have import 
statements?  They are not necessary, in the sense that you can write every 
valid Java program without them, by using fully-qualified names throughout. 
I can think of only two reasons why import statements were added to the 
Java language:

 1. They save the programmer a lot of time (from typing long names).
 2. They provide a concise human-readable summary of the dependencies of 
    a class or interface.

This may be an oversimplification, but I believe that people who tend to 
care more about 1. will use ".*" more often in their import statements, 
and people who care more about 2. will tend to use ".*" less frequently.  
Of course my argument about 2. depends somewhat on whether people care 
more about summarizing package-level dependencies or class-level 
dependencies.  In some situations one might only care to know the 
package-level dependencies, in which case ".*" is sufficient.  If you want 
to be able to quickly assess both these things from a class that has a 
large number of import statements, it would seem wise to adopt 
the additional convention of sorting the import statements (so that it's 
easier for the eye to pick out the distinct packages involved.)

I don't really buy the argument that 2) is important enough to justify 
wasting a programmer's valuable time maintaining sorted lists of 
fully-qualified import statements.  There are programs that can convert 
Java code from one form (fully-qualified imports) to the other (.* imports) 
and back again; so if you inherit a large codebase with .* imports, you 
just have to run a program to convert it to whatever form you find easiest 
to understand.  Using a program to do this job, instead of a programmer, also 
has the advantage that it solves the maintenance problem; any class that 
isn't referenced won't have an import statement.  So I think my opinion is 
that ideally programmers should be allowed to use whatever style is easiest 
for them, but that before the code is checked into CVS, it should be run 
through a tool that expands all the import statements and eliminates the 
unneeded ones.

Jonathan

[Gusdev-gusdev] import statement policy

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

folks-

during jonathan crabtree's last code review at our CBIL lab meeting, we 
had a little discussion about Java's import statement, in particular, 
whether its ok to use an asterisk.  with renewed vigor, i want to sell 
the idea that i don't think it is. (tomatoes are invited)

I have been gearing up to start coding in crabtree's servlet/WDK world 
and to do so i have had to take a comprehensive tour.  it has been clear 
that this has been more difficult because of the obscuring of what class 
comes from what package.  Here is a typical import statement (from the 
file AllgenesPageFormatter.java):

import cbil.csp.*;
import cbil.gus.servlet.*;
import cbil.gus.servlet.db.*;
import cbil.gus.servlet.pages.*;
import cbil.gus.servlet.util.*;
import java.io.*;
import java.sql.*;
import java.util.*;
import javax.servlet.http.*;

This file refers to a bunch of classes that are new to me, and, as i am 
trying to understand what is going on, i have to go visiting.  But, each 
time i do so, i have to wade through all those packages to try to figure 
out where the class lives in order to visit it.  sometimes i can guess, 
and sometimes i can't

The arguments excusing the asterisks were:
  1. if we have javadocs, then they resolve the package and you can link 
to the class.  But, that is only helpful if, indeed, we have a  javadoc 
and if we are perusing an API not the actual code.

  2. it is a hassle to include the full path in the import statements.  
in my experience, this is not so.  if you don't use asterisks, then the 
compiler will complain about any unmentioned classes, so you just plop 
them in as part of getting the class to compile.  also, it is typically 
the case that we only use a small number of classes per package so the 
number of import statements is not that much bigger.

3. it is hard to maintain because the compiler doesn't complain about 
import statements that are no longer needed.  yes, but it doesn't matter 
that much of there are irrelevant import statements.  and, if the import 
statements have the full path, it is quite easy to perform a periodic 
cleanup by just marching through the import statements and making sure 
the classes are mentioned in the code below.  on the other hand, a 
package statement with a * is very hard to purge if it is not needed, 
because you have to survey each class mentioned in the file to see if 
the package is still used.

so, my proposal is that -unless i find myself dripping with tomato- code 
that we review should have fully qualified import statements.

steve

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

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

[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

[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

[Gusdev-gusdev] new RAD tables

[Angel P. <an...@pc...>]

This is a heads-up for RAD development and users:

New RAD tables :
     ProtocolQCParam -- for holding quality control parameters resulting
                        from protocol applications

A re-work of the Analysis tables :
     Analysis
     AnalysisInput
     AnalysisParam
     AnalysisQCParam
     AnalysisResultImp (and AnalysisResult view)
     LogicalGroup
     LogicalGroupLink

Some array tables:
     ArrayGroup
     ArrayGroupLink

Documentation still needs to be inserted to be viewed on the web, but 
the schema will be available with GUS 3.1 due out shortly.

Angel

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

[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

[Gusdev-gusdev] new plugin documentation facility

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

folks-

i have completed the first phase of introducing a new documentation 
facility for plugins.

it is backward compatible, so you don't need to do anything to your 
plugins immediately.

but, we should convert them slowly but surely so they have consistent 
and thorough documentation.  (this will be required for "certification")

the main features are:
 - the documentation for the plugin lives in the plugin's .pm file
 - there are a standard set of documentation fields that are expected 
(eg, description, tables depended on, notes)
 - there is a new command line argument processor that replaces 
easyCsp.  it supports:
       - easy way to add new argument types (eg, date, tablename, etc)
       - list arguments
       - constraint functions
       - standardized documentation of the argument

To see what this all looks like:
   - do a cvs update -d from $PROJECT_HOME/GUS
   - (if you're not at cbil, do a ga +meta and a ga +update 
GUS::Common::Plugin::SubmitRow)
   - try ga GUS::Common::Plugin::SubmitRow --help   to see the docs 
displayed in text
   - see http://www.gusdb.org/documentation/plugins/ which is where the 
plugin docs are shown in html
   - check out the plugin itself: 
$PROJECT_HOME/GUS/Common/plugin/perl/SubmitRow.pm
   - see http://www.gusdb.org/documentation.html for the overall 
documentation (available from http://www.gusdb.org)
   - see http://www.gusdb.org/documentation/GUS-PluginMgr-Plugin.html 
for the Plugin API

steve

Re: [Gusdev-gusdev] unique sequence designator for DoTS.NASequence

[Jonathan C. <cra...@pc...>]

Terry, Bindu-

Bindu Gajria wrote:
> You are right about the fact that
> (taxon_id, external_database_release_id, source_id) is being used
> to attempt retrieval of the sequence.

As I think Steve mentioned, whenever we want to directly reference an
entry in an external database from within GUS, we use the following pair
of attributes in the referencing table (ExternalNASequence in this case):

external_database_release_id
source_id

The naming is obviously bad, because there's nothing to indicate that
the two columns are related in any way.  We have adopted the convention
that this pair of attributes should *uniquely* identify a single entry
in the referenced database.  In practice, however, there is nothing to
enforce this convention, and so it has likely been violated in our
current database.  Here's an example where there appear to be duplicate
rows for a given external_database_release_id, source_id (which actually
may or may not be a violation of this specific convention, depending on
whether the two sequences in question really are the same):

SQL> select external_database_release_id from dots.externalnasequence
       where source_id = 'AJ276847';

EXTERNAL_DATABASE_RELEASE_ID
----------------------------
			   2
			   2

In the above SQL you'll also note that we're not using the full GenBank
accession number (e.g. AJ276847.1), which means that to find the correct
GenBank entry you have to do one of two things:

1. Look at the NCBI "GI", stored (also by convention) in the
    secondary_identifier column.  (In my example above one of the
    two sequences doesn't have a secondary_identifier.)
2. Use the GenBank release number (133) stored in the
    sres.ExternalDatabaseRelease table, to determine which version of
    AJ276847 was the one included in GenBank release 133.

#2 is extremely inconvenient and so, although we may be sticking to the
letter of our convention here (that external_database_release_id and
source_id alone uniquely identify the referenced entry), we're not doing
a good job of following its spirit.

> Code commented out in the plugin, before attempting retrieval
> of the externalNASequence, is :
> 
>   # NOTE: for P_yoelii, source_id is of the form: chrPyl_(\d\d\d\d\d)
>   #       so, source_id needs to be cushioned with 0s (zeroes)
>   #my $tmpStr = $T->{ASSEMBLY}->{ASMBL_ID}->{content};
>   #while (length ($tmpStr) < 5) { $tmpStr = '0'.$tmpStr; }
>   #$enaSeq{source_id} = 'chrPyl_' . $tmpStr;
> 
> The comment is *not* because plugin is still being worked on. It
> exists as the source_id is being constructed from such a line in
> the P_yoelii XML file:
> 
> <ASMBL_ID CLONE_NAME = "MALPY00111">111</ASMBL_ID>
> 
> source_id here is chrPyl_00111 in GUS, and so needed the different
> (than the P falciparum XML files) mechanism for the source_id

Are you saying that to run the plugin on yoelii one has to uncomment
the above code?  If so then I agree with Terry's assessment that the
code is still under construction; at the very least it should be
possible to check (or require that the user specify) the taxon/species
of the data to be loaded, and then select a method of constructing the
source_id based on that.  Making the user comment or uncomment code
in order to get a program to work is not a good practice in general
(though I'm certainly guilty of doing it in code that only I use)
and it's an even worse practice in the GUS plugin framework, because
when you make any change to the plugin the system will force you to
update the AlgorithmImplementation entry in the database.  Therefore
alternately running the plugin on falciparum and yoelii would result
in a long stream of apparent updates to the plugin (in the
AlgorithmImplementation table) even though in reality nothing has
changed except the commenting/uncommenting of this small piece of
code.

(p.s. a single "sprintf" would be a much more concise way of generating
the 0-padded yoelii id than the while loop.)

>> It's not clear to me that the intent of source_id is
>> to uniquely identify the sequence. Is that so?
> 
> yes, that is so, along with taxon_id and external_database_release_id.

Strike taxon_id from the above statement.

>> In the TIGR XML, the CLONE_NAME and ASMBL_ID are two alternative 
>> candidates
>> for uniquely naming a sequence. TIGR documents CLONE_NAME for internal
>> use and ASMBL_ID for external use in uniquely identifying a sequence.

In that case we would use ASMBL_ID as the source_id and CLONE_NAME as
the secondary_identifier.  We typically only use the GUS "name" column
if we have a third id or name that hasn't been stored in either the
source_id or the secondary_identifer.  When loading GenBank entries we
use it for the locus_id.

Jonathan

p.s. The above discussion covers direct links to external databases.  We
also have indirect links, which look like this:

dots.NAFeature -> dots.NADbRefNAFeature -> sres.DbRef -> [external db]

Typically the direct links are used when there is a clear 1-1 relationship
between an entry in GUS and an entry in an external database, and the usual
interpretation of such a link is that the GUS entry was *loaded from* the
referenced external database entry.  The links that go through DbRef, on
the other hand, need not be 1-1, and the semantics are more varied (i.e.
this thing links to that one, but they're not necessarily the same, and
nor is one necessarily loaded from or derived from the other.)

Re: [Gusdev-gusdev] unique sequence designator for DoTS.NASequence

[Bindu G. <bi...@sa...>]

Terry -

At 23:17 -0500 7/20/03, Terry Clark wrote:
>Hi Bindu and others, 
>You might have seen that I made a few minor
>changes to
>    GUS::Common::Plugin::LoadGeneFeaturesFromXML::makeChromosome()
>to get the TIGR Arabidopsis genome uploaded into GUS working
>because the sequence identification mapping is not yet worked out.
>I have some questions and comments about this.
>
>In the plugin at makeChromosome() there is a query performed
>to determine whether the submitted sequence is in the db.
>The approach that is in place uses a query selecting entries
>based on attributes values for:
>    i) taxonomy, ii) external_release_id, and iii) source_id
>There is some code commented out here, since the plugin
>is under construction.

You are right about the fact that
(taxon_id, external_database_release_id, source_id) is being used
to attempt retrieval of the sequence.

   # NOTE: for falciparum XML, map_asmbl_id_to_source_id method was used to set
   #       the source_id appropriately.
   $enaSeq{source_id} = $self->map_asmbl_id_to_source_id($T);

... i.e. picking source_id from TIGR XML


Code commented out in the plugin, before attempting retrieval
of the externalNASequence, is :

   # NOTE: for P_yoelii, source_id is of the form: chrPyl_(\d\d\d\d\d)
   #       so, source_id needs to be cushioned with 0s (zeroes)
   #my $tmpStr = $T->{ASSEMBLY}->{ASMBL_ID}->{content};
   #while (length ($tmpStr) < 5) { $tmpStr = '0'.$tmpStr; }
   #$enaSeq{source_id} = 'chrPyl_' . $tmpStr;

The comment is *not* because plugin is still being worked on. It
exists as the source_id is being constructed from such a line in
the P_yoelii XML file:

<ASMBL_ID CLONE_NAME = "MALPY00111">111</ASMBL_ID>

source_id here is chrPyl_00111 in GUS, and so needed the different
(than the P falciparum XML files) mechanism for the source_id


>It's not clear to me that the intent of source_id is
>to uniquely identify the sequence. Is that so?

yes, that is so, along with taxon_id and external_database_release_id.

>Presently, source_id is constructed from with the hardwiring
>in the mapping         vvvv that we're working on.
>       source_id = ASMBL_ID_2_stringMap + ASMBL_ID
>The source_id above is a unique name by virtue of ASMBL_ID.
>
>On the other hand, NAME is an attractive self-documenting GUS
>attribute that tempts me to use it for the query checking for novelty.
>In the plugin, NAME was/is set to CLONE_NAME, which seems fine,
>although with the caveat for TIGR, this is labeled as for their
>internal use.
>
>In the TIGR XML, the CLONE_NAME and ASMBL_ID are two alternative candidates
>for uniquely naming a sequence. TIGR documents CLONE_NAME for internal
>use and ASMBL_ID for external use in uniquely identifying a sequence.
>
>I punted for now by adding the condition to the query
>    $ena_gus->setName($T->{ASSEMBLY}->{HEADER}->{CLONE_NAME})
>i.e., the attributes
>    i) taxonomy, ii) external_release_id, and iii) CLONE_NAME
>
>What do you think?

Perhaps this will work well. I have only looked at XML files of
falciparum and yoelii so far, and that too, only 1 revision of
these. So, not much experience with all this.

Else, we should think of a strategy (a method within the plugin)
to modify source_id after collecting field contents of some XML
tag/attribute, and having specified some choice parameters. INHO
this doesn't sound like a good way to go for various reasons.


Bindu



>Terry
>
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: VM Ware
>With VMware you can run multiple operating systems on a single machine.
>WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the
>same time. Free trial click here: http://www.vmware.com/wl/offer/345/0
>_______________________________________________
>Gusdev-gusdev mailing list
>Gus...@li...
>https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev

Re: [Gusdev-gusdev] GUS And Bioperl

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

Arnaud-

You can get a db connection without the plugin manager.  see 
$PROJECT_HOME/GUS/Common/bin/deleteEntries.pl for example.

But, as far as running plugins, that inherently involves the plugin 
framework.  If you are only reading the db, you won't need this.

Also, while mapping using the object layer may be easier, it may also be 
slower, possibly significantly (but this bears looking into).

steve

Arnaud Kerhornou wrote:

> Hi
>
> Following the conference call, I've been working on setting up a demo 
> about interfacing Bioperl and having GUS as a datasource. There are 
> several ways for doing this.
> * The first way is to implement the Bioperl-db interfaces to point at 
> GUS instead of a BioSQL database. That involves to map the GUS 
> relational design into the Bioperl one. It would be used in a 
> read-only mode.
> * A second way is to map Bioperl Objects into GUS objects and use the 
> GUS objects API to access the database. That seems to involve less 
> work  as the mapping between the object layer and the relational layer 
> as well as the DB connections would be delegated to the GUS layer. 
> This code could be used for read and write access.
>
> To do so, I've tried to use the GUS object layer, but it is actually 
> embedded into the Plugin Framework which processes the initialisation 
> step (DB connection, plugin registration...). How could I use the perl 
> layer independently of the GusApplication framework ?
>
> Thanks
> Arnaud
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: VM Ware
> With VMware you can run multiple operating systems on a single machine.
> WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the
> same time. Free trial click here: http://www.vmware.com/wl/offer/345/0
> _______________________________________________
> Gusdev-gusdev mailing list
> Gus...@li...
> https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev

Re: [Gusdev-gusdev] unique sequence designator for DoTS.NASequence

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

terry-


in general external_database_release_id and source_id should be unique, 
if, of course, the source_id is a primary key for the external db.

steve

Terry Clark wrote:

>Hi Bindu and others,  
>You might have seen that I made a few minor
>changes to 
>   GUS::Common::Plugin::LoadGeneFeaturesFromXML::makeChromosome()
>to get the TIGR Arabidopsis genome uploaded into GUS working 
>because the sequence identification mapping is not yet worked out.
>I have some questions and comments about this.
>
>In the plugin at makeChromosome() there is a query performed 
>to determine whether the submitted sequence is in the db. 
>The approach that is in place uses a query selecting entries 
>based on attributes values for:
>   i) taxonomy, ii) external_release_id, and iii) source_id
>There is some code commented out here, since the plugin 
>is under construction.
>
>It's not clear to me that the intent of source_id is
>to uniquely identify the sequence. Is that so?
>Presently, source_id is constructed from with the hardwiring
>in the mapping         vvvv that we're working on.
>      source_id = ASMBL_ID_2_stringMap + ASMBL_ID
>The source_id above is a unique name by virtue of ASMBL_ID.
>
>On the other hand, NAME is an attractive self-documenting GUS 
>attribute that tempts me to use it for the query checking for novelty.
>In the plugin, NAME was/is set to CLONE_NAME, which seems fine,
>although with the caveat for TIGR, this is labeled as for their
>internal use.
>
>In the TIGR XML, the CLONE_NAME and ASMBL_ID are two alternative candidates 
>for uniquely naming a sequence. TIGR documents CLONE_NAME for internal
>use and ASMBL_ID for external use in uniquely identifying a sequence.
>
>I punted for now by adding the condition to the query
>   $ena_gus->setName($T->{ASSEMBLY}->{HEADER}->{CLONE_NAME})
>i.e., the attributes
>   i) taxonomy, ii) external_release_id, and iii) CLONE_NAME
>
>What do you think? 
>
>Terry
>
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: VM Ware
>With VMware you can run multiple operating systems on a single machine.
>WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the
>same time. Free trial click here: http://www.vmware.com/wl/offer/345/0
>_______________________________________________
>Gusdev-gusdev mailing list
>Gus...@li...
>https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev
>  
>

[Gusdev-gusdev] GUS And Bioperl

[Arnaud K. <ax...@sa...>]

Hi

Following the conference call, I've been working on setting up a demo 
about interfacing Bioperl and having GUS as a datasource. There are 
several ways for doing this.
* The first way is to implement the Bioperl-db interfaces to point at 
GUS instead of a BioSQL database. That involves to map the GUS 
relational design into the Bioperl one. It would be used in a read-only 
mode.
* A second way is to map Bioperl Objects into GUS objects and use the 
GUS objects API to access the database. That seems to involve less work  
as the mapping between the object layer and the relational layer as well 
as the DB connections would be delegated to the GUS layer. This code 
could be used for read and write access.

To do so, I've tried to use the GUS object layer, but it is actually 
embedded into the Plugin Framework which processes the initialisation 
step (DB connection, plugin registration...). How could I use the perl 
layer independently of the GusApplication framework ?

Thanks
Arnaud

[Gusdev-gusdev] unique sequence designator for DoTS.NASequence

[Terry C. <tw...@cs...>]

Hi Bindu and others,  
You might have seen that I made a few minor
changes to 
   GUS::Common::Plugin::LoadGeneFeaturesFromXML::makeChromosome()
to get the TIGR Arabidopsis genome uploaded into GUS working 
because the sequence identification mapping is not yet worked out.
I have some questions and comments about this.

In the plugin at makeChromosome() there is a query performed 
to determine whether the submitted sequence is in the db. 
The approach that is in place uses a query selecting entries 
based on attributes values for:
   i) taxonomy, ii) external_release_id, and iii) source_id
There is some code commented out here, since the plugin 
is under construction.

It's not clear to me that the intent of source_id is
to uniquely identify the sequence. Is that so?
Presently, source_id is constructed from with the hardwiring
in the mapping         vvvv that we're working on.
      source_id = ASMBL_ID_2_stringMap + ASMBL_ID
The source_id above is a unique name by virtue of ASMBL_ID.

On the other hand, NAME is an attractive self-documenting GUS 
attribute that tempts me to use it for the query checking for novelty.
In the plugin, NAME was/is set to CLONE_NAME, which seems fine,
although with the caveat for TIGR, this is labeled as for their
internal use.

In the TIGR XML, the CLONE_NAME and ASMBL_ID are two alternative candidates 
for uniquely naming a sequence. TIGR documents CLONE_NAME for internal
use and ASMBL_ID for external use in uniquely identifying a sequence.

I punted for now by adding the condition to the query
   $ena_gus->setName($T->{ASSEMBLY}->{HEADER}->{CLONE_NAME})
i.e., the attributes
   i) taxonomy, ii) external_release_id, and iii) CLONE_NAME

What do you think? 

Terry

[Gusdev-gusdev] >>MAKE OVER 2,000% PROFIT SELLING INFORMATION!

[jeraidina <mak...@ya...>]

  
***HERE IS AN OFFER YOU DON'T WANT TO MISS!***

Over 1,200 Books, Manuals, And Reports On CD-Rom! 

Full Reprint Rights!  

Sell The Entire Collection For As Much $$$ As You Like!  

Never Pay us any royalty fee!

Read them, Sell them and bank the money!

The best part is this...

You can use all our web pages and marketing 
material (included) to make a fortune selling 
these amazing books, reports and manuals.

It's a ready made business!

You can even sell them on ebay and clean house!

>>You will also get a second bonus CD ROM...

Including 9 E-Books on how to advertise and
start making some real money on the Internet!

>>Plus yet another added Bonus...

How to make serious money on ebay and other 
auction sites overnight!

To find out more about this Risk Free Offer, Do not respond by email. 
Instead, Click the link below or copy and paste the web site address 
into your web browser.


<br><A HREF="http://www.leadsvvewillvve.us/reports.htm">Click Here For More 

Information</A><br>

http://www.leadsvvewillvve.us/reports.htm




______________________________________________________
Want to be REMOVED from our email list?
You were sent this email because you used our Opt-in service.
We hope you enjoy reading our messages. However, if you'd rather
not receive future e-mails from us, Click on the link below.
http://www.leadsvvewillvve.us/removeme.htm
Thank you for your cooperation.
________________________________________________________

Re: [Gusdev-gusdev] plugin documentation effort

[Terry C. <tw...@cs...>]

Steve, maybe also specify all tables that are modified
by running the plugin.

Terry 


On  0, Steve Fischer <sfi...@pc...> wrote:
> Folks-
> 
> As more and more plugins are being used outside CBIL, it is becoming 
> clear that the plugins need more documentation, and in some cases need 
> to be cleaned up for use outside of CBIL.
> 
> The idea we have come up with is to begin the process of "certifying" 
> plugins.  A certified plugin would:
>   - be listed as such on a web page available from gusdb.org
>   - have argument lists that make sense and conform to an (emerging) 
> plugin arguments standard
>   - have a usage string that makes sense
>   - be checked for GUS 3.0 compliance
>   - be checked for hard-coded references to CBIL-specific files or data 
> (eg externalDatabaseReleaseIds)
>   - be documented.
>   - ultimately, we would also like the plugins (new ones anyway) to 
> conform to a structured programming standard
> 
> For the documentation, we have in mind to develop a "plugin 
> documentation template."  This template would specify a bunch of 
> information about the plugin that needs to be supplied, eg:
>    - overview of the plugin
>    - dependencies on other data (with pointers to plugins that provide it)
>    - sources of input data
>    - how to restart the plugin
>    - failure cases
>    - expected run time
>    - expected db resource usage
>    - other assumptions
>    - overall context of how the plugin is used
> 
> To get things rolling, I would like to poll everybody for:
>   1. which plugin should we start with as a demonstration project
>   2. please add to and/or improve my list of questions the plugin 
> documentation template should ask
> 
> Any and all other ideas are encouraged.
> 
> Steve
> 
> 
> 
> -------------------------------------------------------
> 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/psa00100006ave/direct;at.asp_061203_01/01
> _______________________________________________
> Gusdev-gusdev mailing list
> Gus...@li...
> https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev

[Gusdev-gusdev] plugin documentation effort

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

Folks-

As more and more plugins are being used outside CBIL, it is becoming 
clear that the plugins need more documentation, and in some cases need 
to be cleaned up for use outside of CBIL.

The idea we have come up with is to begin the process of "certifying" 
plugins.  A certified plugin would:
   - be listed as such on a web page available from gusdb.org
   - have argument lists that make sense and conform to an (emerging) 
plugin arguments standard
   - have a usage string that makes sense
   - be checked for GUS 3.0 compliance
   - be checked for hard-coded references to CBIL-specific files or data 
(eg externalDatabaseReleaseIds)
   - be documented.
   - ultimately, we would also like the plugins (new ones anyway) to 
conform to a structured programming standard

For the documentation, we have in mind to develop a "plugin 
documentation template."  This template would specify a bunch of 
information about the plugin that needs to be supplied, eg:
    - overview of the plugin
    - dependencies on other data (with pointers to plugins that provide it)
    - sources of input data
    - how to restart the plugin
    - failure cases
    - expected run time
    - expected db resource usage
    - other assumptions
    - overall context of how the plugin is used

To get things rolling, I would like to poll everybody for:
   1. which plugin should we start with as a demonstration project
   2. please add to and/or improve my list of questions the plugin 
documentation template should ask

Any and all other ideas are encouraged.

Steve

[Gusdev-gusdev] Core.AlgorithmParamKey DESCRIPTION attribute modified

[Terry C. <tw...@cs...>]

This attribute was defined as 
  DESCRIPTION         VARCHAR2(255)
causing a problem for the comment/description for
GUS::Common::Plugin::LoadPfam

Rather than shortening the comment and modifying
the source, I opted to change the TABLE as shown
below to
    DESCRIPTION   VARCHAR2(1024)

Terry 




 SQL ERROR!! involving

    INSERT INTO Core.AlgorithmParamKey (  group_read, algorithm_param_key_id, user_read, algorithm_implementation_id, modification_date, other_write, algorithm_param_key_type_id, row_group_id, algorithm_param_key, user_write, other_read, group_write, row_user_id, description, row_alg_invocation_id, is_list_valued, row_project_id )
    VALUES   (  ?, ?, ?, ?, SYSDATE, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ? )
 Values: 1, 280, 1, 22, 0, 0, 1, flat_file, 1, 1, 1, 1, Flat file containing the release of Pfam to load.
Expects
                        the file containing the annotation and full alignments in Pfam
                        format of all Pfam-A families (called "Pfam-A.full" in release 5.2)
                        The specified file may be in gzip (.gz) or compressed (.Z) format.

SQL> alter table Core.AlgorithmParamKey modify
  2          DESCRIPTION   VARCHAR2(1024)
  3  );
)



OKAY NOW,

gus> ga +create GUS::Common::Plugin::LoadPfam --commit
Reading properties from /home/gus/run/config/GUS-PluginMgr.prop
Reading properties from /home/gus/.gus.properties
Mon Jul  7 13:40:35 2003        INFO    Plugin GUS::Common::Plugin::LoadPfam registered with cvs revision '1.10' and cvs tag ' ' .

[Gusdev-gusdev] Disp.pm note

[Terry C. <tw...@cs...>]

The module GUS::Common::Plugin::LoadGeneFeaturesFromXML 
requires the GUS Perl module Disp.pm.  It was tempting
to qualify "use Disp" as "use CBIL::Util::Disp", but to
stay in sync with the release, I opted to extend my PERL5LIB path.

Terry