Bug #1240
closed
Old profiles need eml 2 returndoc types
Added by Matthew Brooke over 20 years ago.
Updated over 20 years ago.
Category:
morpho - general
Description
Profiles created in morpho < 1.5aplha1 do not contain:
<returndoc>eml://ecoinformatics.org/eml-2.0.0</returndoc>
...so any eml2 documents saved under these profiles do not subsequently show up
in a search dialog.
Short-term Resolution:
This could possibly be fixed as part of the install step when we next create an
installer?
Long-Term Resolution:
a) Maybe the eml-version-specific impementation of the abstractdatapackage
should have some kind of accessor method to pass return doctypes dynamically to
the query code, instead of storing these in profile settings?
b) If the profile settings need to have these returndoc types in them (so you
can set up a "beta-6 only" profile, for instance??) then maybe the default is to
call the datapackage for a list of return doctypes if a profile xml doc doesn't
exist on disk?
I'd vote for (a) if at all possible
It looks like the current profile is updated when a new version is installed,
but other profiles are not. Another possible fix is simply to update ALL
installed profiles when a new version is installed.
I set the current profile code up to be update config.xml anytime the version
string in the code changes. When Morpho first runs it checks if your version of
the config.xml corresponds to the version in the morpho app -- if not, it copies
a new one for you. So, each of you probably got a new profile when the version
was changed, but somehow managed to revert to an old copy of config.xml?
In any case, I agree with Matthew -- there's no reason for the returndoc types
to be in the profile now that we have the data package set up as we do. Each
subclass of AbstractDataPackage should be able to provide doctype info for the
doctypes it can support.
FIXED. For simplicity, this has been fixed by moving the returndoc,
retrunfield, and doctype configuration parameters out of the profile and into
the main config.xml file. This means that these settings are now
application-wide. This was done in preference to folding the info into the
AbstractDataPackage subclasses because it was easier and because that system
wouldn't be as flexible with respect to minor version changes. It would also
have required changes to config.xml to list the supported types, so was a far
more complicated solution. Minimizing unnecessary changes at this point is good.
Original Bugzilla ID was 1240
Also available in: Atom
PDF