Menu
▾
▴
gusdev-gusdev
|
From: Adrian R. T. <ar...@sa...> - 2003-08-26 12:23:15
|
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? > - configurable styles ie given an query syntax tree the way this is displayed to the user should be easily modifiable, or something else? > - site's standard s surrounding page specific stuff (ie, your tiles > solution) > - JavaScript functionality Server-side scripting or client side? > - 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. > - 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. >, 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? > 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) > - 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 |
|
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 |
|
From: Steve F. <sfi...@pc...> - 2003-09-04 18:13:00
|
[I have re-subjected this email thread] The table you are looking at is an "Imp" table. These are special tables that are used by GUS to implement subclassing. GUS allows us to define a single level subclass structure. For example, we can define NAFeature as a base class, and, eg, GeneFeature and ExonFeature as subclasses of NAFeature. This is done by a trick. The subclasses are views of an Imp table which really holds the data. The "Imp" stands for implementation. In a sense, you should consider these tables as hidden. In this case, the base class view is NAFeature. Its implementation table is NAFeatureImp. And the subclass views are GeneFeature, etc. The columns in an Imp table are just named for the kind of data they hold, and are never expected to be accessed directly. Instead you use the views, either the base class (NAFeature) or the subclasses (GeneFeature). steve Chetna Warade wrote: >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 >> >> > > >------------------------------------------------------- >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 > > |
|
From: Steve F. <sfi...@pc...> - 2003-08-26 15:47:45
|
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 > > |
|
From: <su...@vb...> - 2003-09-04 16:57:42
|
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 |
|
From: Jonathan C. <cra...@pc...> - 2003-09-04 20:58:09
|
Hi Sucheta- On Thu, 4 Sep 2003 su...@vb... wrote: > 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? As Chetna mentioned, documentation is available for many of the attributes in the GUS schema browser; see http://www.gusdb.org/cgi-bin/schemaBrowser The descriptions that you see in the schema browser are actually stored in GUS itself, in the table Core.DatabaseDocumentation. However, the particular attributes that you mention are handled in a special way. Any table whose name ends in "Imp" in GUS is considered an "implementation" table. These tables are typically not queried directly; instead we query the single-table views that are defined on these tables. In the case of NAFeatureImp, for example, these views include GeneFeature and HexamerFeature; the schema browser's "view on" column shows us that both of these views are views on the NAFeatureImp table. The columns named int1, string1, etc., may be used for different things in different views, so the important thing to look at is the documentation for the individual views, not the implementation tables. For example, if you click on the link for DoTS::GeneFeature, you can see the actual SQL view definition for the view, which reads as follows: SELECT na_feature_id, na_sequence_id, subclass_view, sequence_ontology_id, name, parent_id, source_id, external_database_release_id, prediction_algorithm_id, is_predicted, review_status_id, string14 as gene_type, tinyint2 as confirmed_by_similarity, int1 as prediction_number, int2 as number_of_exons, tinyint3 as has_initial_exon, tinyint4 as has_final_exon, float1 as score, float2 as secondary_score, tinyint5 as is_pseudo, tinyint6 as is_partial, string1 as allele, string2 as citation, string3 as evidence, string4 as function, string5 as gene, string6 as label, string7 as map, string9 as phenotype, string10 as product, string12 as standard_name, string13 as usedin, modification_date, user_read, user_write, group_read, group_write, other_read, other_write, row_user_id, row_group_id, row_project_id, row_alg_invocation_id, FROM NAFeatureImp WHERE subclass_view = 'GeneFeature' WITH CHECK OPTION; In other words, the "string1" column of the NAFeatureImp table is used to store the GeneFeature's "allele". But, in another view of NAFeatureImp, it might be used for something else. This system of having multiple views on a single implementation table gives us a very simple way to implement a restricted form of subclassing in the database (that is, a GeneFeature IS-A NAFeature.) Jonathan |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X