Morpho: Issueshttps://projects.ecoinformatics.org/ecoinfo/https://projects.ecoinformatics.org/ecoinfo/ecoinfo/favicon.ico?14691340362002-06-13T15:36:00ZEcoinformatics Redmine
Redmine Bug #531 (New): use itislib to check taxon name spellinghttps://projects.ecoinformatics.org/ecoinfo/issues/5312002-06-13T15:36:00ZMatt Jonesjones@nceas.ucsb.edu
<p>When entering taxon names in the various fields, especially coverage, use the<br />itislib to llok up the names in ITIS to validate the spelling. If a taxon name<br />is not found in ITIS, notify the user so that they can correct the spelling.</p> Bug #530 (In Progress): add spell checking supporthttps://projects.ecoinformatics.org/ecoinfo/issues/5302002-06-13T15:33:57ZMatt Jonesjones@nceas.ucsb.edu
<p>Need a spell checker that checks common words in science as well as standard<br />english. Use while editing metadata.</p> Bug #511 (In Progress): Enhance Icons for morpho StatusBarhttps://projects.ecoinformatics.org/ecoinfo/issues/5112002-05-22T23:06:13ZMatthew Brookebrooke@nceas.ucsb.edu
<p>Minor leftover from bug <a class="issue tracker-1 status-3 priority-2 priority-default closed" title="Bug: need visual indicator of login and network status (Resolved)" href="https://projects.ecoinformatics.org/ecoinfo/issues/358">#358</a> (which has been fixed by adding a new <br />statusbar).</p>
<p>This current "bug" is really an enhancement - the icons used in development of <br />the status bar were just "quick & dirty" creations for testing. Need to <br />review and maybe improve or change them for production release (need a "look" <br />that's more consistent with the existing button images and between the 3 <br />icons?)</p> Bug #509 (In Progress): HTTPProxy Firewall support neededhttps://projects.ecoinformatics.org/ecoinfo/issues/5092002-05-16T16:53:47ZDan Higginshiggins@nceas.ucsb.edu
<p>Morpho has no functionality for working behind a HTTPFirewall with a Proxy. Such<br />functionality (e.g. setting Proxy Name, port, etc) exists for other Java<br />applications (e.g. JEdit) and should be added to Morpho.</p> Bug #460 (In Progress): XML Editor should be better synched with Metacat & handle temp docshttps://projects.ecoinformatics.org/ecoinfo/issues/4602002-04-06T19:39:38ZDan Higginshiggins@nceas.ucsb.edu
<p>Older versions of local documents should be stored in a separate folder and<br />handled differently than current version to allow local editing and updates<br />without having to send all those documents to metacat when a package submitted<br />to the server after local editing.</p>
<p>Also need to keep track of last doc version downloaded from Metacat and handle<br />issue of another user updating a document between connections. Fold in ability<br />to store locally documents where information is incomplete becausde creation has<br />not yet been completed.</p> Bug #458 (In Progress): Need to configure Morpho to accept stream-based result setshttps://projects.ecoinformatics.org/ecoinfo/issues/4582002-04-06T05:07:28ZDan Higginshiggins@nceas.ucsb.edu
<p>For performance purposes, Metacat needs to send results in a stream created as<br />results are generated (rather than getting all the results and then sending<br />them). [The other option being considered is to send the response in 'chunks' of<br />a set size.]</p>
<p>Morpho needs to be able ot handle both stream and chunk based responses. It<br />should create the ResultSet table and add result rows as they arrive from the<br />server (rather than getting the entire result set and then displaying the whole<br />table.)</p> Bug #400 (In Progress): need graphical view of sampling layouthttps://projects.ecoinformatics.org/ecoinfo/issues/4002002-01-23T16:18:44ZMatt Jonesjones@nceas.ucsb.edu
<p>Sandy Andelman made the following feature request:</p>
<p>I wanted to relay to you a suggestion for Morpho. Based on experience with last<br />year's set of graduate seminars, trying to work with data from the previous<br />Waide-Willig working group, and the current seminars to date, we have found that<br />it is IMPOSSIBLE to decide how to appropriately integrate data from multiple<br />sources without a schematic diagram of the spatial arrangement of the sampling<br />units.</p>
<p>In other words, if we don't have a diagram the data are USELESS for integrating<br />across scales. So right now, we are maintaining information on the spatial<br />sampling design separately, which is ok for now, but if we want Morpho to be a<br />tool that is used by ecologists, it will need to have this capability.</p>
<p>Currently, Morpho does not have the capability to incorporate this type of<br />information. I would like to suggest that this be made a high priority. Given<br />the increasing emphasis of ecologists on spatial pattern, this seems like an<br />essential feature.</p>
<p>Please let me know what you think of this idea.</p> Bug #394 (In Progress): window positions need to be savedhttps://projects.ecoinformatics.org/ecoinfo/issues/3942002-01-11T19:38:03ZChad Berkleyberkley@nceas.ucsb.edu
<p>Morpho needs to save the position of each of its windows so that when they are<br />closed then shown again, they can be put in the same place where the user had<br />them the last time they opened them. Also, initial window positions need to be<br />standardized. some windows center themselves on the screen (maxX/2,maxY/2) when<br />others are created in the upper left hand corner (0,0).</p> Bug #360 (In Progress): consolidate configuration informationhttps://projects.ecoinformatics.org/ecoinfo/issues/3602001-12-01T01:00:45ZMatt Jonesjones@nceas.ucsb.edu
<p>Morpho currently has configuration info about schemas, layout, and help hints<br />spread across at least 4 types of configuration files (config.xml, package<br />wizard config files, xml editor config files, and dtds). There may also be some<br />hardcoded stuff in the code. Need to consolidate allof this information into<br />one easy to use configuration scheme. This will probably involve using xml<br />schema docs directly to extract information. We should however maintain a<br />distinction between schema configuration (dtd/schema) and layout configuration.<br /> I'm not sure we currently maintain this difference well.</p> Bug #326 (In Progress): Ability to repeat more than one fieldhttps://projects.ecoinformatics.org/ecoinfo/issues/3262001-11-09T18:52:34ZChristy Christyubowlc00@umail.ucsb.edu
<p>The repeat button to add more fields is good, but it would be useful to be able<br />to have the ability to add more than one set of fields at a time. This would be<br />especially applicable to describing attributes for a large table. Maybe a second<br />button next to the repeat button (?multiple repeat?) could pull up a screen that<br />asks how many fields to add?</p> Bug #307 (In Progress): package event handler to improve resultset refresh performancehttps://projects.ecoinformatics.org/ecoinfo/issues/3072001-10-24T17:58:21ZMatt Jonesjones@nceas.ucsb.edu
<p>Performance on Morpho is pretty poor, partly because it spends so much time<br />querying Metacat and the local files in order to keep the main resultset display<br />refreshed. We could substantially improve things by caching the resultset<br />(which we already have in memory) and making updates to it rather than<br />re-querying Metacat (or locally). Whenever the user makes a change to any file<br />in a package, it results in one of three events: PACKAGE-INSERTED,<br />PACKAGE-UPDATED, or PACKAGE-DELETED. For each of these events, the change can<br />occur on the local data store or on the metacat store, or both.</p>
<p>I propose that we develop an event notification system so that any morpho<br />component that is interested can find out when one of these events has occurred<br />(which will require the component generating the event to initiate the<br />notification). For INSERT and UPDATE events, if the package is local, we can<br />look at the package on disk, extract the relevant resultset info, and delete the<br />old entry in the in-memory resultset, and add the new entry in the in-memory<br />resultset. If the changed package is only on metacat, we'll have to retrieve<br />the package from metacat to get the package details, and then insert into the<br />in-memory copy as above (which is expensive), or hopefully we can get the info<br />from our local cache. In the case of DELETE events, we can always just remove<br />the entry from the resultset.</p>
<p>To implement this requires creating these basic classes/methods:</p>
<p>In a DataPackage class (not sure which yet):<br />void firePackageEvent(PackageEvent pe);<br /> called by all routines that insert, update, or delete packages<br />void addPackageEventListener(PackageEventListener listenrer);<br /> called by a class that wants to register as a listener for pe's</p>
<p>In classes that want to listen for pe's:<br />void handlePackageEvent(PackageEvent pe);<br /> called by the event handler whenever a package is changed<br /> this method is provided by all classes that want to be notified of<br /> package events (like the ResultSet class) and would be part of a<br /> PackageEventListener interface that they would implement</p>
<p>The PackageEvent class would include attributes like:<br /> source -- a reference to the package generating the event<br /> identifier -- the docid of the package generating the event<br /> eventType -- INSERT, UPDATE, DELETE, other?</p>
<p>This feature would allow us to keep all ResultSets up-to-date as changes are<br />made to packages without re-querying morpho or metacat, which should improve the<br />overall user-interface performance substantially.</p>
<p>Feedback requested.</p> Bug #306 (In Progress): [RFE] folder views to organize data packageshttps://projects.ecoinformatics.org/ecoinfo/issues/3062001-10-24T06:19:42ZMatt Jonesjones@nceas.ucsb.edu
<p>Feature request from Christy Bowles for a way to organize data packages in<br />Morpho into folders.</p>
<p>Additional thoughts by me about how this could work:<br />----------------------------------------------------<br />The current results window shows a seemingly unordered list of data packages. <br />As one accumulates data packages, this can get quite unruly. This RFE includes<br />several possible suggested improvements:</p>
<p>1) There is a need for a mechanism to organize data packages into virtual<br />folders that show up in the results window. These collections of data packages<br />are no more than a way of aggregating similar packages together visually, and it<br />does not imply anything about how the packages are stored on disk. One could<br />imaging for a user interface a tree-table with expandable folder icons on the<br />left that expand into lists of data packages. The user could drag packages from<br />one folder to another to organize their packages and morpho would rmember the<br />folder contents.</p>
<p>2) Note that some ways of organizing packages into folders could be automatic,<br />such as grouping all of the packages by originator (which brings up the issue,<br />could the same package appear in mutiple folders if there are multiple<br />originators?). This would imply an ability to switch among several 'folder<br />views', which might be custom user-generated groupings or automatically<br />generated groupings.</p>
<p>3) Both with or without the above folders feature, need to be able to sort on<br />the metadata fields that are the column headers of the table.</p>
<p>Although these would be nice features, they will have to wait for at least the<br />1.1 release of morpho.</p> Bug #302 (In Progress): create metacat account from morpho profile dialoghttps://projects.ecoinformatics.org/ecoinfo/issues/3022001-10-17T03:28:39ZMatt Jonesjones@nceas.ucsb.edu
<p>create metacat account from morpho profile dialog</p> Bug #205 (In Progress): cut/copy/pastehttps://projects.ecoinformatics.org/ecoinfo/issues/2052001-04-09T21:53:57ZMatt Jonesjones@nceas.ucsb.edu
<p>Integrate cut/copy/paste into appropriate functional areas of morpho.</p> Bug #124 (In Progress): batch display and printing of resultsetshttps://projects.ecoinformatics.org/ecoinfo/issues/1242000-09-20T18:29:54ZMatt Jonesjones@nceas.ucsb.edu
<p>This RFE is for a mechanism for batch display of the documents in a resultset, <br />so that the user can see a single, "integrated" view of all of the relevant <br />metadata and page through it or print it. Generating a PDF file for this may be <br />sufficient. How this is accomplished while maintaining the appropriate <br />associations between metadata and data entities is not yet determined.</p>
<p>This RFE originated from comments from <a class="email" href="mailto:schild@nceas.ucsb.edu">schild@nceas.ucsb.edu</a>.</p>