| 1 | MICHAEL'S LIST :-)
|
|---|
| 2 |
|
|---|
| 3 | /home/kjdon/public_html/michael (www.cs.waikato.ac.nz/~kjdon/michael) has some helpful docs - actually only one - the jni book.
|
|---|
| 4 | also see hints.tex and manual.tex in docs/manual - printed out too.
|
|---|
| 5 |
|
|---|
| 6 |
|
|---|
| 7 | * GS2MGPPSearch - currently for field searching, it uses a hard coded list of fields - this should be read in from the config file and be colleciton dependent. see createParameter, for the FIELD_FIELD_PARAM.
|
|---|
| 8 |
|
|---|
| 9 |
|
|---|
| 10 | * images from the server. currently we expect that they are on the same machine - the xslt puts in links to them. need a better way to get images that works remotely. so far do this for the colleciton icons. once document display is worked out better, do it for document images too.
|
|---|
| 11 | Then there is the generic associated resource retrieval. this will depend on document DTD and what xlinks we use for associated docs/resources. maybe the id of a resource is its http address if there is one, otherwise you get it through soap or in the xml.
|
|---|
| 12 | theres two routines in GSFile - base64EncodeFromFile() and base64DecodeToFile() which goes file <-> base64 string - can use these to put image etc into xml.
|
|---|
| 13 |
|
|---|
| 14 | * add the Gatherer code to cvs.
|
|---|
| 15 | I've been meaning to do this for ages, but never got around to it. The code is at www.greenstone.org/gatherer. talk to david.
|
|---|
| 16 |
|
|---|
| 17 | * dynamic xslt ie old format statements.
|
|---|
| 18 | in gs2 the collection builder can add format statements for search results, doc text, classifiers to the collect.cfg file. gs3 uses xslt for formatting pages.
|
|---|
| 19 | collection builders should be able to specify some xslt eg a single template for a document in a search result list, to the config file, to be passed to the actions and incorporated into teh stylesheet before processing the page.
|
|---|
| 20 |
|
|---|
| 21 | What I have done so far:
|
|---|
| 22 | In browse action, the code checks for the existence of a <stylesheet> element in the response:'
|
|---|
| 23 |
|
|---|
| 24 | Node new_style = GSXML.getChildByTagName(response, GSXML.STYLESHEET_ELEM);
|
|---|
| 25 | if (new_style !=null) {
|
|---|
| 26 | GSXSLT.mergeStylesheets(style_doc, (Element)new_style);
|
|---|
| 27 | response.removeChild(new_style);
|
|---|
| 28 | }
|
|---|
| 29 |
|
|---|
| 30 | If it finds it, it adds it in to the stylesheet which will be used for transforming the page (mergeStylesheets), and then removes it from the response.
|
|---|
| 31 |
|
|---|
| 32 | If a template is added with a higher priority, it will be used instead of the default one
|
|---|
| 33 |
|
|---|
| 34 | eg
|
|---|
| 35 | <xsl:template match="document" priority="3">
|
|---|
| 36 |
|
|---|
| 37 | I have tried this out with hardcoding the service to return a static xslt along with a classifier response and it works fine.
|
|---|
| 38 |
|
|---|
| 39 | TODO:
|
|---|
| 40 |
|
|---|
| 41 | For classifiers: edit the GS2Browse service agent to look in a config file for xslt fragments - should probably go in the collectionConfig.xml which isn't used yet. but for now can go in buildConfig.xml.
|
|---|
| 42 |
|
|---|
| 43 | Then it needs to pass the appropriate one back with a response. - they are classifier specific.
|
|---|
| 44 | have a look at classifier.xsl (in interfaces/default/transforms) to see how the templates are used. The ones you'd want to return are document and maybe node, but node is really complicated.
|
|---|
| 45 |
|
|---|
| 46 | you need to decide how to add it into the config file - element names etc and where to put it - inside the classifier element? in a <stylesheet> node or something different?
|
|---|
| 47 |
|
|---|
| 48 | Once that is working for classifiers, you can do the same thing for query search results and document text. You will need to do the action side as well for those, but that should just be a metter of cutting and pasting code.
|
|---|
| 49 |
|
|---|
| 50 | Another thing to think about: the browse action just looks for the stylesheet element in a normal response. but perhaps it should be a separate request sent to a service? do you have some xslt which you would like me to use?
|
|---|
| 51 |
|
|---|
| 52 | if it just comes back in a response from a different request, when doing eg a query, when does it come back? with the original query result? I guess you'd send a request to a query, and along with the document list, it could send back a stylesheet element if it wanted too.
|
|---|
| 53 |
|
|---|
| 54 | It may be cleaner to have a separate request, I dont know.
|
|---|
| 55 |
|
|---|
| 56 | * Display stuff vs metadata
|
|---|
| 57 |
|
|---|
| 58 | When you get a service description, you also get a <display> element which has text strings for the service name, submit button, and any text needed for the parameters. (see query_messages)
|
|---|
| 59 |
|
|---|
| 60 | When you do a browse thingy, along with any classifier info you also get some metadata - Title (see browse_messages).
|
|---|
| 61 |
|
|---|
| 62 | Where do you draw the line between a display element and a metadata element?
|
|---|
| 63 |
|
|---|
| 64 | The full name of the service that is currently in the display could arguably be a metadata element.
|
|---|
| 65 |
|
|---|
| 66 | we need a consistent view of what is metadata and what is just a display element.
|
|---|
| 67 |
|
|---|
| 68 | all agents respond to a describe yourself message which retrieves metadata as part of the description.
|
|---|
| 69 |
|
|---|
| 70 | when the about page is produced for a collection or service cluster, a list of services are obtained, and currently their names are just displayed. We need their real names to be displayed. should this be gotten though a describe yourself message to each service and pick the name out of the display? or do a describe yourself, just for metadata and have the name returned as metadata instead?
|
|---|
| 71 |
|
|---|
| 72 | Note, describe requests have another attribute called info (I think), so you can narrow down the request eg
|
|---|
| 73 | <request type='describe' info='metadataList'>
|
|---|
| 74 |
|
|---|
| 75 | this works for the message router - is it implemented in all agents? (collections, service clusters and services?) I think it should be.
|
|---|
| 76 |
|
|---|
| 77 | ANd I think I prefer that service name eg "Query a collection" for TextQuery should be a metadata element.
|
|---|
| 78 |
|
|---|
| 79 | anyway, have a think about it.
|
|---|
| 80 |
|
|---|
| 81 | The main thing I would like out of this is for the service names eg TextQuery not to appear on the about pages, but are replaced with the metadata Title eg "Query a collection" which can then be changed depending on the users language.
|
|---|
| 82 |
|
|---|
| 83 | * add document for building
|
|---|
| 84 |
|
|---|
| 85 | The addDocument service (in GS2Construct) has not been implemented. It should take a file name and add the document to the import directory of teh collection.
|
|---|
| 86 | there are problems with just transmitting a file name - the service may live remotely and therefore the document is not there. You should probably send it attached to the html - therefore need to work out:
|
|---|
| 87 | how to get the document attached to the form (theres something to do with post and encoding = multipart ?? otherwise the browser just sends the filename),
|
|---|
| 88 | and then where to get it in the servlet - is it a parameter? or something else?
|
|---|
| 89 |
|
|---|
| 90 | and then it needs to be added into the xml request to be passed to the service.
|
|---|
| 91 |
|
|---|
| 92 | If the program is running locally its much simpler just to send a filename - can we somehow check for this?
|
|---|
| 93 |
|
|---|
| 94 | * also to do with building, a little harder, is the ConfigureCollection service. There is no stub for it yet, but easy enough to add one. - need to add this service to the service description xml stuff, and write a processConfigureColleciton() method. It would be easy enough to display the config file in a big text box, and have the user edit it like the collector does.
|
|---|
| 95 |
|
|---|
| 96 | the hard bit is that when you click ConfigureCollection, you dont know what collection you are going to be dealing with - all the building services, you select the collection on the service page. with the configure stuff, you need to select the collection, and then the config file needs to be retrieved. so its really a two step process to configure the coll - first select the coll, submit that, then edit the config file, and submit that.
|
|---|
| 97 |
|
|---|
| 98 | All the services currently are one step - need to think about how this type of service fits into the model.
|
|---|
| 99 |
|
|---|
| 100 | maybe it needs a hidden arg? - to tell teh service if you're at stage 1 or 2?
|
|---|
| 101 | when teh action does the request, it then asks for the service description again to redisplay it for the user. maybe if the service knows that it has done the first half, it sends the second type of description?
|
|---|
| 102 |
|
|---|
| 103 | * sequence of services
|
|---|
| 104 |
|
|---|
| 105 | some service clusters have services that you are supposed to carry out in sequence such as building, but there may be others.
|
|---|
| 106 |
|
|---|
| 107 | can we do a generic action or xslt or something that sends teh user to teh next service once they've completed the first one?
|
|---|
| 108 |
|
|---|
| 109 | Maybe teh service cluster/serviceRack class specifies teh sequence of services, and they are all handled individually like present except that some xslt puts a next button on each page with a link to teh next service in the list.
|
|---|
| 110 |
|
|---|
| 111 | * tidy up the setup.bash, install.bash stuff. see david. theres some things that need to be done once on install, and if you do them again your system craps out. but if you change what needs to be done in cvs, the user cant update their system without great knowledge of what needs to be done. other stuff like make needs to be done after every cvs update. there are two scripts install and update which attempts to solve part of this. setup.bash needs to be run multiple times and ends up adding stuff to teh path more than once.
|
|---|
| 112 |
|
|---|
| 113 | anyway, all this install stuff could be much nicer. If you really want to make it nice, you could look at doing a proper configure, and using --prefix etc so that its a proper package (see john also for help about this) - bin, lib etc would get put to their proper places not necessarily into gsld3/bin etc.
|
|---|
| 114 |
|
|---|
| 115 | * Lucene - svetlana has done a project comparing mg, mgpp and lucene. investigate further whether lucene would be good for us to use. incremental update?
|
|---|
| 116 | report on my desk. |
|---|
