schema-profiles not as pluggable as they need to be...

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

schema-profiles not as pluggable as they need to be...

Paul van Genuchten
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'.
http://geonetwork-opensource.org/manuals/trunk/eng/users/administrator-guide/managing-metadata-standards/index.html#adding-a-schema

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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork
Reply | Threaded
Open this post in threaded view
|

Re: schema-profiles not as pluggable as they need to be...

delawen
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
<[hidden email]> 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'.
> http://geonetwork-opensource.org/manuals/trunk/eng/users/administrator-guide/managing-metadata-standards/index.html#adding-a-schema
>
> 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork
Reply | Threaded
Open this post in threaded view
|

Re: schema-profiles not as pluggable as they need to be...

SimonPigot
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 [[hidden email]]
Sent: Wednesday, 2 December 2015 7:39 PM
To: Paul van Genuchten
Cc: Devel [hidden email]
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
<[hidden email]> 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'.
> http://geonetwork-opensource.org/manuals/trunk/eng/users/administrator-guide/managing-metadata-standards/index.html#adding-a-schema
>
> 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork
Reply | Threaded
Open this post in threaded view
|

Re: schema-profiles not as pluggable as they need to be...

delawen
Good!!

Let us know as soon as you have more documentation written, so we
don't reinvent the wheel :)

On Wed, Dec 2, 2015 at 10:03 AM,  <[hidden email]> wrote:

> 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 [[hidden email]]
> Sent: Wednesday, 2 December 2015 7:39 PM
> To: Paul van Genuchten
> Cc: Devel [hidden email]
> 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
> <[hidden email]> 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'.
>> http://geonetwork-opensource.org/manuals/trunk/eng/users/administrator-guide/managing-metadata-standards/index.html#adding-a-schema
>>
>> 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
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
>> 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork
Reply | Threaded
Open this post in threaded view
|

Re: schema-profiles not as pluggable as they need to be...

Francois Prunayre
In reply to this post by Paul van Genuchten
Hi Paul,

2015-12-02 9:32 GMT+01:00 Paul van Genuchten <[hidden email]>:
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'.
http://geonetwork-opensource.org/manuals/trunk/eng/users/administrator-guide/managing-metadata-standards/index.html#adding-a-schema

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.


For new profile, I would recommend to use a dedicated repository like https://github.com/metadata101/ instead of mixing all schemas in schema-plugins repository. It's then much easier to use submodule to plug a profile in a custom flavour of GeoNetwork.

In 3.x, Java logic for each profiles can be much easier be moved to the plugin. BTW, as we are doing more and more on the client side, we have now more JS logic. Did you (and Maria) made some experiment to extract the JS parts in a separate maven module - for the community module work last year ? I've not much ideas on this, but last changes from Simon improve this a little for ISO profiles.

Once you've the repository for the plugin, we could probably use Jenkins to build packages for each plugins - but we'll have to better maintain versions between GN and plugins.

My .2 cents.

Francois



 
------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork
Reply | Threaded
Open this post in threaded view
|

Re: schema-profiles not as pluggable as they need to be...

delawen
On Mon, Dec 7, 2015 at 8:27 PM, Francois Prunayre <[hidden email]> wrote:

> Hi Paul,
>
> 2015-12-02 9:32 GMT+01:00 Paul van Genuchten <[hidden email]>:
>>
>> 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'.
>>
>> http://geonetwork-opensource.org/manuals/trunk/eng/users/administrator-guide/managing-metadata-standards/index.html#adding-a-schema
>>
>> 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.
>>
>
> For new profile, I would recommend to use a dedicated repository like
> https://github.com/metadata101/ instead of mixing all schemas in
> schema-plugins repository. It's then much easier to use submodule to plug a
> profile in a custom flavour of GeoNetwork.
>
> In 3.x, Java logic for each profiles can be much easier be moved to the
> plugin. BTW, as we are doing more and more on the client side, we have now
> more JS logic. Did you (and Maria) made some experiment to extract the JS
> parts in a separate maven module - for the community module work last year ?

Hi,

Yes, we have experimented in that field (and we are still!). Not in
extracting the current javascript in different modules, but in being
able to add extra javascript/html maven projects to GeoNetwork having
to modify just a few lines in wro-sources and pom.xml files. I have as
a pending task write a good documentation  on how to write your own UI
using as a backup the default one but being able to override whatever
you need. Some steps are still a bit ugly (for example, you have to
use mvn jetty:run-explode instead of jetty:run if you want to override
some files), but it is in an easy working status now.

On the other hand, the only solution we have found for the "hardcoded"
parts in javascript for schemas is to get the code dynamically from a
service. For example, get the array of schemas and their namespaces
from the server. Which probably is the best option... right? And have
a bean on each schemas that loads this definitions on the service.

> I've not much ideas on this, but last changes from Simon improve this a
> little for ISO profiles.
>
> Once you've the repository for the plugin, we could probably use Jenkins to
> build packages for each plugins - but we'll have to better maintain versions
> between GN and plugins.
>
> My .2 cents.
>
> Francois
>
>
>
>
>>
>>
>> ------------------------------------------------------------------------------
>> 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
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
>> 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork
Reply | Threaded
Open this post in threaded view
|

Re: schema-profiles not as pluggable as they need to be...

Francois Prunayre
Hola Maria,

2015-12-07 22:22 GMT+01:00 María Arias de Reyna <[hidden email]>:
On Mon, Dec 7, 2015 at 8:27 PM, Francois Prunayre <[hidden email]> wrote:
> Hi Paul,
>
> 2015-12-02 9:32 GMT+01:00 Paul van Genuchten <[hidden email]>:
>>
>> 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'.
>>
>> http://geonetwork-opensource.org/manuals/trunk/eng/users/administrator-guide/managing-metadata-standards/index.html#adding-a-schema
>>
>> 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.
>>
>
> For new profile, I would recommend to use a dedicated repository like
> https://github.com/metadata101/ instead of mixing all schemas in
> schema-plugins repository. It's then much easier to use submodule to plug a
> profile in a custom flavour of GeoNetwork.
>
> In 3.x, Java logic for each profiles can be much easier be moved to the
> plugin. BTW, as we are doing more and more on the client side, we have now
> more JS logic. Did you (and Maria) made some experiment to extract the JS
> parts in a separate maven module - for the community module work last year ?

Hi,

Yes, we have experimented in that field (and we are still!). Not in
extracting the current javascript in different modules, but in being
able to add extra javascript/html maven projects to GeoNetwork having
to modify just a few lines in wro-sources and pom.xml files. I have as
a pending task write a good documentation  on how to write your own UI
using as a backup the default one but being able to override whatever
you need. Some steps are still a bit ugly (for example, you have to
use mvn jetty:run-explode instead of jetty:run if you want to override
some files), but it is in an easy working status now 

Ok, so needs more improvements. Not sure what would be best to hook dynamic dependencies to the wro4j mechanism. Maybe one service should create a list of dependencies based on the plugins loaded (similar to what oasis catalogs are doing). To be investigated.



On the other hand, the only solution we have found for the "hardcoded"
parts in javascript for schemas is to get the code dynamically from a
service. For example, get the array of schemas and their namespaces
from the server. Which probably is the best option... right? And have
a bean on each schemas that loads this definitions on the service. 

That may cover some other needs that Simon did not covered in his PR.

Francois

 

> I've not much ideas on this, but last changes from Simon improve this a
> little for ISO profiles.
>
> Once you've the repository for the plugin, we could probably use Jenkins to
> build packages for each plugins - but we'll have to better maintain versions
> between GN and plugins.
>
> My .2 cents.
>
> Francois
>
>
>
>
>>
>>
>> ------------------------------------------------------------------------------
>> 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
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
>> 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork
Reply | Threaded
Open this post in threaded view
|

Re: schema-profiles not as pluggable as they need to be...

Emanuele Tajariol-2
In reply to this post by Francois Prunayre
Hi,

> For new profile, I would recommend to use a dedicated repository like
> https://github.com/metadata101/ instead of mixing all schemas in
> schema-plugins repository. It's then much easier to use submodule to plug a
> profile in a custom flavour of GeoNetwork.

Shall we need to add a notice on
   https://github.com/geonetwork/schema-plugins
telling that the repo is deprecated and the new oneschema-onerepo approach
should be followed?

   Cheers,
   Emanuele


Alle 20:27:49 di Monday 7 December 2015, Francois Prunayre ha scritto:

> Hi Paul,
>
> 2015-12-02 9:32 GMT+01:00 Paul van Genuchten <[hidden email]>:
> > 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'.
> >
> > http://geonetwork-opensource.org/manuals/trunk/eng/users/administrator-gu
> > ide/managing-metadata-standards/index.html#adding-a-schema
> >
> > 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/SchemaM
> > anagerService.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/DatePickerDi
> > rective.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.
>
> For new profile, I would recommend to use a dedicated repository like
> https://github.com/metadata101/ instead of mixing all schemas in
> schema-plugins repository. It's then much easier to use submodule to plug a
> profile in a custom flavour of GeoNetwork.
>
> In 3.x, Java logic for each profiles can be much easier be moved to the
> plugin. BTW, as we are doing more and more on the client side, we have now
> more JS logic. Did you (and Maria) made some experiment to extract the JS
> parts in a separate maven module - for the community module work last year
> ? I've not much ideas on this, but last changes from Simon improve this a
> little for ISO profiles.
>
> Once you've the repository for the plugin, we could probably use Jenkins to
> build packages for each plugins - but we'll have to better maintain
> versions between GN and plugins.
>
> My .2 cents.
>
> Francois
>
> > -------------------------------------------------------------------------
> > ----- 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
> > [hidden email]
> > https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
> > GeoNetwork OpenSource is maintained at
> > http://sourceforge.net/projects/geonetwork


--
==
GeoServer Professional Services from the experts!
Visit http://goo.gl/NWWaa2 for more information.
==

Ing. Emanuele Tajariol
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054  Massarosa (LU)
Italy
phone: +39 0584 962313
fax:    +39 0584 1660272
mob:   +39  380 2116282

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

-------------------------------------------------------

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork
Reply | Threaded
Open this post in threaded view
|

Re: schema-profiles not as pluggable as they need to be...

Francois Prunayre


2015-12-08 12:24 GMT+01:00 Emanuele Tajariol <[hidden email]>:
Hi,

> For new profile, I would recommend to use a dedicated repository like
> https://github.com/metadata101/ instead of mixing all schemas in
> schema-plugins repository. It's then much easier to use submodule to plug a
> profile in a custom flavour of GeoNetwork.

Shall we need to add a notice on
   https://github.com/geonetwork/schema-plugins
telling that the repo is deprecated and the new oneschema-onerepo approach
should be followed?

Sounds good Emanuele and maybe indicating which plugins are still maintained or not and which one are now on metadata101 or elsewhere.

Francois

 

   Cheers,
   Emanuele


Alle 20:27:49 di Monday 7 December 2015, Francois Prunayre ha scritto:
> Hi Paul,
>
> 2015-12-02 9:32 GMT+01:00 Paul van Genuchten <[hidden email]>:
> > 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'.
> >
> > http://geonetwork-opensource.org/manuals/trunk/eng/users/administrator-gu
> > ide/managing-metadata-standards/index.html#adding-a-schema
> >
> > 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/SchemaM
> > anagerService.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/DatePickerDi
> > rective.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.
>
> For new profile, I would recommend to use a dedicated repository like
> https://github.com/metadata101/ instead of mixing all schemas in
> schema-plugins repository. It's then much easier to use submodule to plug a
> profile in a custom flavour of GeoNetwork.
>
> In 3.x, Java logic for each profiles can be much easier be moved to the
> plugin. BTW, as we are doing more and more on the client side, we have now
> more JS logic. Did you (and Maria) made some experiment to extract the JS
> parts in a separate maven module - for the community module work last year
> ? I've not much ideas on this, but last changes from Simon improve this a
> little for ISO profiles.
>
> Once you've the repository for the plugin, we could probably use Jenkins to
> build packages for each plugins - but we'll have to better maintain
> versions between GN and plugins.
>
> My .2 cents.
>
> Francois
>
> > -------------------------------------------------------------------------
> > ----- 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
> > [hidden email]
> > https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
> > GeoNetwork OpenSource is maintained at
> > http://sourceforge.net/projects/geonetwork


--
==
GeoServer Professional Services from the experts!
Visit http://goo.gl/NWWaa2 for more information.
==

Ing. Emanuele Tajariol
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054  Massarosa (LU)
Italy
phone: <a href="tel:%2B39%200584%20962313" value="+390584962313">+39 0584 962313
fax:    <a href="tel:%2B39%200584%201660272" value="+3905841660272">+39 0584 1660272
mob:   <a href="tel:%2B39%20%20380%202116282" value="+393802116282">+39 380 2116282

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

-------------------------------------------------------


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork
Reply | Threaded
Open this post in threaded view
|

Re: schema-profiles not as pluggable as they need to be...

Francois Prunayre
In reply to this post by Emanuele Tajariol-2
Hi Plugin maintainers ;)

2015-12-08 12:24 GMT+01:00 Emanuele Tajariol <[hidden email]>:
Hi,

> For new profile, I would recommend to use a dedicated repository like
> https://github.com/metadata101/ instead of mixing all schemas in
> schema-plugins repository. It's then much easier to use submodule to plug a
> profile in a custom flavour of GeoNetwork.

Shall we need to add a notice on
   https://github.com/geonetwork/schema-plugins
telling that the repo is deprecated and the new oneschema-onerepo approach
should be followed?


Don't hesitate to update the plugin's status depending on your projects to indicate if they're maintained/deprecated and which version can be used with it.

Cheers.

Francois


 

   Cheers,
   Emanuele


Alle 20:27:49 di Monday 7 December 2015, Francois Prunayre ha scritto:
> Hi Paul,
>
> 2015-12-02 9:32 GMT+01:00 Paul van Genuchten <[hidden email]>:
> > 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'.
> >
> > http://geonetwork-opensource.org/manuals/trunk/eng/users/administrator-gu
> > ide/managing-metadata-standards/index.html#adding-a-schema
> >
> > 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/SchemaM
> > anagerService.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/DatePickerDi
> > rective.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.
>
> For new profile, I would recommend to use a dedicated repository like
> https://github.com/metadata101/ instead of mixing all schemas in
> schema-plugins repository. It's then much easier to use submodule to plug a
> profile in a custom flavour of GeoNetwork.
>
> In 3.x, Java logic for each profiles can be much easier be moved to the
> plugin. BTW, as we are doing more and more on the client side, we have now
> more JS logic. Did you (and Maria) made some experiment to extract the JS
> parts in a separate maven module - for the community module work last year
> ? I've not much ideas on this, but last changes from Simon improve this a
> little for ISO profiles.
>
> Once you've the repository for the plugin, we could probably use Jenkins to
> build packages for each plugins - but we'll have to better maintain
> versions between GN and plugins.
>
> My .2 cents.
>
> Francois
>
> > -------------------------------------------------------------------------
> > ----- 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
> > [hidden email]
> > https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
> > GeoNetwork OpenSource is maintained at
> > http://sourceforge.net/projects/geonetwork


--
==
GeoServer Professional Services from the experts!
Visit http://goo.gl/NWWaa2 for more information.
==

Ing. Emanuele Tajariol
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054  Massarosa (LU)
Italy
phone: <a href="tel:%2B39%200584%20962313" value="+390584962313">+39 0584 962313
fax:    <a href="tel:%2B39%200584%201660272" value="+3905841660272">+39 0584 1660272
mob:   <a href="tel:%2B39%20%20380%202116282" value="+393802116282">+39 380 2116282

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

-------------------------------------------------------


------------------------------------------------------------------------------

_______________________________________________
GeoNetwork-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork