Menu
▾
▴
Re: [Gusdev-gusdev] Struts documentation - supporting evidence
|
From: Chetna W. <ch...@ug...> - 2003-09-04 17:33:09
|
Hello Sucheta, I dont know if this is what you looking for but checkout http://www.gusdb.org/cgi-bin/schemaBrowser and scroll for DOTS::Tablename you should ab able to find the table decription. Most of the times the table field names are intuitative. Chetna ---- Original message ---- >Date: Thu, 4 Sep 2003 12:56:47 -0400 (EDT) >From: su...@vb... >Subject: Re: [Gusdev-gusdev] Struts documentation - supporting evidence >To: "Steve Fischer" <sfi...@pc...> >Cc: "Adrian Roy Tivey" <ar...@sa...>, gus...@li... > >Hi, >I am new to the GUS developer's forum, so I am not aware if the question >has already been addressed. > >I was wondering in the table DoTS::NAFeatureImp (standard table), what are >the use of the int(1...), float(1..) and string attributes. > >Is there a place where the meaning of the attributes has been documented? > > >Sucheta > >> Adrian, see below. >> >> steve >> >> Adrian Roy Tivey wrote: >> >>>Hello, >>> >>>Thanks for your comments. Just a shortish email to expand on a couple of >>>points and request clarification on a couple of others (including >>> comments on >>>the first three points but that's just the order they happened to come >>> up!) >>> >>> >>> >>>>Adrian- >>>> >>>>Angel and I have had a chance to meet and throw together our initial >>>>ideas about a JSP/Struts based WDK. >>>> >>>>My sense is that our thinking compliments what you layed out in your >>>>Struts Demo. Basically, we are buying into the ideas you presented >>>>about how the display can work. We are also interested in starting to >>>>nail down the design of the underlying machinery (somewhat along the >>>>lines of what you outlined in your conclusions section). Much of our >>>>thinking is informed by the current WDK design. >>>> >>>>We drew up a quick list of big-ticket requirements items, some addressed >>>>by your proposal and some not: >>>> - declarative specification of content, queries, dialogs. >>>> >>>> >>> >>>I follow the middle one. I'm not sure what you mean by dialog and >>> especially >>>content through the email. Could you give a rough outline of the Content >>> bean? >>> >>> >> By "content" we mean all kinds of verbiage on the site. The canonical >> example is the tutorials available on the EpconDB site >> (http://www.cbil.upenn.edu/EPConDB/). The content is considered "model" >> not view. The current implementation is Jonathan Schug's Page >> Generator, which is written in perl. The model is stored in perl data >> structures, independently from any formatting information, and is >> formated by the PageGenerator. Its not always obvious where to draw the >> line between model and view. Another example would be that a home page >> might have Introduction, News, Funding, etc. that we would like to be in >> the model. Obviously, in the new WDK, model is stored in Beans, and >> view is stored mostly in JSP. >> >> By "dialog" we mean a form. In the current WDK, the dialogues are >> specified declaratively in the servlet-config file. They are often >> complex, with queries underlying pulldown lists, etc. In the new WDK we >> were thinking we would have Dialog beans, or similar, to manage these in >> the model. >> >>> >>> >>>> - configurable styles >>>> >>>> >>> >>>ie given an query syntax tree the way this is displayed to the user >>> should be >>>easily modifiable, or something else? >>> >> Bear with me here. I still haven't read the JSP book yet. But, the idea >> is for the JSPs to refer to a stylesheet or similar, so that we could >> potentially reuse JSPs across projects. An example would be a JSP that >> formats a query dialog. The JSP is the same between, say, allgenes and >> plasmodb, but the look is different because of the style configuration. i >> am not clear on how this relates to the tiles. >> >>> >>> >>>> - site's standard s surrounding page specific stuff (ie, your tiles >>>>solution) >>>> - JavaScript functionality >>>> >>>> >>> >>>Server-side scripting or client side? >>> >>> >> client side. we use this for example to provide mouse-over behaviour in >> some of our graphics. >> >>> >>> >>>> - calls to external resources (eg, processes) to provide stuff like >>>>graphics >>>> - boolean queries >>>> - history >>>> - report maker >>>> >>>> >>> >>>Is there a current implementation in one of the current GUS sites or a >>> spec >>>somewhere? It's been mentioned at this end but I don't think we ever went >>> into >>>it in much detail. >>> >> I guess you are refering to the ReportMaker. It is alive on the >> Allgenes site. Do a query, and then press Download from the query >> history. The code is in two places. The backend is in cvs >> GUS/ReportMaker. The frontend is still in our legacy CVS. >> >>> >>> >>> >>>> - batch submission >>>> - connection pooling >>>> - process pooling? >>>> - result caching >>>> - result paging >>>> - error handling >>>> - dialog validation >>>> - logging >>>> >>>>We sketched the following top level Beans, which we see being configured >>>>in config files (XML is fine... not sure yet about Digester) >>>> >>>> >>> >>>I only suggested that because that's what's used by Struts. Played with >>> it a >>> bit more now and it seems simple to use for what we'd want. But yes, >>> there's >>>any number of mature, open-source XML/Beans alternatives we could go for >>> instead. >>> >>> >> Angel has looked at Digester and got the sense that it was overkill. i >> haven't looked at it yet. we remain open-minded. >> >>>>, and which >>>>do not specify any formatting information: >>>> - Dialog (eg, a form) >>>> - QueryDialog (a subclass of Dialog) >>>> - other subclasses of Dialog? >>>> - Record (eg, an RNA page and/or detailed page) >>>> - ResultSet (or is this just a record?) >>>> >>>>These guys have properties, which, are also beans, of types: >>>> - Content >>>> - SqlQuery >>>> - Process >>>> >>>>And, SqlQuery and Process have as properties subclasses of Param, which >>>>is also a bean. >>>> >>>>The main difference between the beans we see for the new WDK and those >>>>in the old WDK is that the new ones don't include any formatting >>>>information. I think that means that we can have siginificantly fewer >>>>classes, because the classes don't have to differentiate based on >>>>formatting implementations. >>>> >>>>Based on our still rudimentary understanding of JSP, we imagine these >>>>kind of pages and fragments, which are somehow parameterized by the >>>> beans: >>>> - Dialog >>>> - QueryDialog >>>> - ResultSet >>>> - Record >>>> - Record Details >>>> - Content >>>> >>>> >>> >>>I suspect we may be thinking of two different things but not sure. What >>> kind of >>>thing would content be as a page or page fragment wrt a Content bean? >>> >>> >>> >> A Content fragment would be a JSP fragment that could show news items. >> >>> >>> >>>>Things we are assuming JSP can do (haven't read the book yet), and want >>>>to understand more about: >>>> - bind beans to a JSP page >>>> >>>> >>> >>>Yep. jsp:useBean to tie a JavaBean to a page local variable. We have to >>> decide >>>on a schedule and how cutting-edge we want to be. The syntax becomes even >>>clearer with JSP2.0 (eg Tomcat 5) but support for that is still at >>> alpha/beta >>>for many containers. (There *should* be a stable implementation in >>> ~December for >>>the official release of J2EE 1.4 so personally I don't think it's >>> unreasonable >>>choice) >>> >>> >> ok, lets keep that in mind. >> >>> >>> >>>> - simple control features like iterate across a list of results to >>>> display >>>> >>>> >>> >>>Not part of JSP per se but there is a standard template library that >>> includes >>>simple iterators, control flow etc. See geneResults-body.jspf for an >>> example >>> >>> >>> >>>> - fetch JSP fragments to insert (eg, one per row of a result) >>>> >>>> >>> >>>? Not sure I understand. There are two built-in include mechanisms but >>> for a >>>table of results you'd generally write the formatting code eg table tags >>> as a >>>template and insert the data into that. For the specific case of the >>>CellFormatter there is a working tag library equivalent in the demo. >>> >>> >>> >>>>As far as the config files are concerned, we agree that huge config >>>>files are not optimal. We don't yet see how best to organize them, >>>>though we want to be able to re-use some of them across projects. So, i >>>>think they will need to find there way into a directory structure of >>>>some kind. >>>> >>>>Steveo >>>> >>>> >>> >>>Adrian >>> >>> >> >> >> >> ------------------------------------------------------- >> 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/358/0 >> _______________________________________________ >> Gusdev-gusdev mailing list >> Gus...@li... >> https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev >> > > >-- >Sucheta Tripathy >Virginia Bioinformatics Institute >1880 pratt drive,Bldg XV >Virginia tech. >Blacksburg >Virginia >VA 24061 >phone-(540)231-8138 > > >------------------------------------------------------- >This sf.net email is sponsored by:ThinkGeek >Welcome to geek heaven. >http://thinkgeek.com/sf >_______________________________________________ >Gusdev-gusdev mailing list >Gus...@li... >https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev |
