At least some of that is done as part of a proposal I'm about to do a pull request for - I have added plugins for ANZLIC, MCP etc to 3.x.x in the ANZMEST fork develop branch so have had to cope with at least some of this.
Cheers,
Simon
________________________________________
From: María Arias de Reyna [delawen@anonymised.com]
Sent: Wednesday, 2 December 2015 7:39 PM
To: Paul van Genuchten
Cc: Devel geonetwork-devel@lists.sourceforge.net
Subject: Re: [GeoNetwork-devel] schema-profiles not as pluggable as they need to be...
Hi,
What I have been suggesting is to remove all the hard-coded parts in
javascript and have services in GeoNetwork to populate that parts. We
can add beans on each schema project to fill it on the server side. So
once the project is inside maven, it will be automatically populated.
A similar thing can be achieved for the database changes.
I am not so sure about the maven configuration parts.
Regards,
María.
On Wed, Dec 2, 2015 at 9:32 AM, Paul van Genuchten
<paul.vangenuchten@anonymised.com> wrote:
Hi list, in recent projects i've been struggling with the new
schema-profiles in GN3.0 and found they are not that pluggable as they
are in GN2.0 (and should be imho).
A while back I've added in this page a list of actions to
'plug-a-profile'.
Managing metadata & template - GeoNetwork Opensource (EN)
Would it be interesting to see if we can move profiles to a maven
repository, so people can include profiles without having to change
pom.xml's in several places?
Recently I discovered the above page is not complete, there are other
items to update:
- On
web-ui/src/main/resources/catalog/components/common/schemamanager/SchemaManagerService.js
you have to add each of the schemas you're adding and for each add a
procedure to retrieve the proper codelists.
- On
web-ui/src/main/resources/catalog/components/edit/datepicker/DatePickerDirective.js
there is an error namespaces[gnCurrentEdit.schema]['gco'] undefined
In the javascripts there is quite some xml snippets hardcoded, which
worries me if at some point someone wants to start implementating a
totally new schema like Dublin Core, SensorML, GBIF/EML,
schema.org/Dataset or DCAT.
Some directives may only be called from the form-config in a certain
schema, and thus may be tightly bound to that schema, which could be
fine. Altough in that case it would be better to use a naming convention
like iso19139-date-picker-directive.js, any profile that is based on
iso19139 can then use that directive?
Would be interested to hear your thoughts on this and see if we can
define a way to move this forward.
------------------------------------------------------------------------------
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140
_______________________________________________
GeoNetwork-devel mailing list
GeoNetwork-devel@lists.sourceforge.net
geonetwork-devel List Signup and Options
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork
------------------------------------------------------------------------------
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140
_______________________________________________
GeoNetwork-devel mailing list
GeoNetwork-devel@lists.sourceforge.net
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork