Yes, you can use this file and embedd it into biomart.tt just like all other templates are calling/embedding sub-units (templates). Of course you are free to modify biomart.tt and leave this out, however just as you mentioned 'maintenance', I thought would be better if you can simply add a line to biomart.tt and copy across the relevant code over to resultspage.tt and maintain your own resultsPanel.
cheers syed On Tue, 2008-02-26 at 13:46 +0000, Roger Hull wrote: > Hi Syed, > > Are you sure about resultspage.tt? - this file doesn't seem to be used. > > Regards, > Roger > > Syed Haider wrote: > > Hi Roger, > > to manipulate the results for say sorting, filtering etc etc, have a > > loot at > > > > biomart-perl/conf/templates/default/resultspage.tt > > > > you can modify this panel according to your needs. > > > > > > cheers > > syed > > > > > > On Mon, 2008-02-25 at 17:41 +0000, Roger Hull wrote: > > > >> Hi, > >> > >> The URL API provides a good solution for canned queries which can be > >> implemented as standard BioMart queries. But I also need to implement > >> another type of canned query, which takes data from a BioMart and > >> post-processes it in various ways. I can do this using the perl API, > >> for example, and display the results in a new web page. > >> > >> However, what I would like to do is to make use of the existing > >> MartView features for displaying and downloading the data, so that the > >> user has a more uniform experience. Also, for some types of canned > >> query, I would like the user to be able to change the filtering and/or > >> attribute selections and press "Results" to get a new set of > >> post-processed results, displayed in the MartView page. > >> > >> Is there some function that I could hook into which delivered the > >> results internally within MartView? Of course I want to minimise the > >> code changes, for future maintainability, but if there is one place > >> (or a small number of places) where I could insert a function call > >> which would post-process the data, this should be manageable. > >> > >> I also need to do the same for the Count function. Currently the Count > >> returned is "how many rows in the main table of the dataset match your > >> filters so far". In the case of PRIDE, this is the number of > >> experiments. But often I need to know the number of rows returned from > >> the query, not the number of rows from the main table - for example I > >> want to know the number of distinct proteins or peptides which match > >> my filters. > >> > >> Regards, > >> Roger. > >>
