Hi
We have move to use xslt formatter instead of the default groovy one, due to lots of problems with this formatter in some servers and the difficulty to determine what is causing that, but thats another history …
The xslt formatter works fine, at least with default iso19139, but with a custom profile we were getting this:
2016-06-30 14:34:10,532 ERROR [jeeves] - Error occurred within a transaction
; SystemID: file:///nfs_dply/pdok/ngr3/data/formatter//xslt/render-layout.xsl; Line#: 105; Column#: -1
After spending some time trying to figure out what was happening, found this property in the formatter that limits the translations loaded for the xslt formatter to the schemas listed:
https://eos.geocat.net/gitlab/ngr/geonetwork/blob/ngr3/schemas/iso19139.nl.geografie.1.3.1/src/main/plugin/iso19139.nl.geografie.1.3.1/formatter/config.properties#L24
schemasToLoad=iso19139
If you create a schema based on iso19139, you copy that file and don’t notice that you need to change that value with the name of your schema, as there’s a complete lack of documentation for this.
Does somebody knows why is that required? The formatter knows the schema of the metadata that is processing, why not load the files related to the metadata schema and relay in a external file configuration? Maybe I’m missing something?
Regards,
Jose García
···
Vriendelijke groeten / Kind regards,
Jose García
Veenderweg 13
6721 WD Bennekom
The Netherlands
T: +31 (0)318 416664
Please consider the environment before printing this email.
Hi Francois
Thanks for pointing that, but no documentation about the specific fields that can be configured in config.properties file (https://github.com/geonetwork/core-geonetwork/wiki/Schema-Formatters-and-Metadata-Views#shared-files).
I think the best would be to load at least by default the translation files for the current schema (without requiring explicit definition of schemasToLoad). If also additional schemas defined in schemasToLoad, load them. Also probably would be even better to load the schema strings and any dependent schema to avoid the schemasToLoad property, using this:
https://github.com/metadata101/iso19139.nl.services.1.2.1/blob/ceb6c9c32d97659cb787e57ff5cbe41754fe1e5a/src/main/plugin/iso19139.nl.services.1.2.1/schema-ident.xml#L11
Regards,
Jose García
···
On Mon, Jul 4, 2016 at 10:57 AM, Francois Prunayre <fx.prunayre@anonymised.com> wrote:
Hi Jose
–
2016-07-01 9:34 GMT+02:00 Jose Garcia <jose.garcia@anonymised.com>:
Hi
We have move to use xslt formatter instead of the default groovy one, due to lots of problems with this formatter in some servers and the difficulty to determine what is causing that, but thats another history …
The xslt formatter works fine, at least with default iso19139, but with a custom profile we were getting this:
2016-06-30 14:34:10,532 ERROR [jeeves] - Error occurred within a transaction
; SystemID: file:///nfs_dply/pdok/ngr3/data/formatter//xslt/render-layout.xsl; Line#: 105; Column#: -1
After spending some time trying to figure out what was happening, found this property in the formatter that limits the translations loaded for the xslt formatter to the schemas listed:
https://eos.geocat.net/gitlab/ngr/geonetwork/blob/ngr3/schemas/iso19139.nl.geografie.1.3.1/src/main/plugin/iso19139.nl.geografie.1.3.1/formatter/config.properties#L24
schemasToLoad=iso19139
If you create a schema based on iso19139, you copy that file and don’t notice that you need to change that value with the name of your schema, as there’s a complete lack of documentation for this.
Does somebody knows why is that required? The formatter knows the schema of the metadata that is processing, why not load the files related to the metadata schema and relay in a external file configuration? Maybe I’m missing something?
Jesse made some docs when making the proposal
https://github.com/geonetwork/core-geonetwork/wiki/Schema-Formatters-and-Metadata-Views
Probably we need to add more doc to here http://geonetwork-opensource.org/manuals/trunk/eng/users/tutorials/customui/view/formatter.html
Cheers.
Francois
Regards,
Jose García
–
Vriendelijke groeten / Kind regards,
Jose García
Veenderweg 13
6721 WD Bennekom
The Netherlands
T: +31 (0)318 416664
Please consider the environment before printing this email.
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
GeoNetwork-devel mailing list
GeoNetwork-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork
Vriendelijke groeten / Kind regards,
Jose García
Veenderweg 13
6721 WD Bennekom
The Netherlands
T: +31 (0)318 416664
Please consider the environment before printing this email.
2016-07-04 11:11 GMT+02:00 Jose Garcia <jose.garcia@anonymised.com>:
Hi Francois
Thanks for pointing that, but no documentation about the specific fields
that can be configured in config.properties file (
https://github.com/geonetwork/core-geonetwork/wiki/Schema-Formatters-and-Metadata-Views#shared-files
).
I think the best would be to load at least by default the translation
files for the current schema (without requiring explicit definition of
schemasToLoad). If also additional schemas defined in schemasToLoad, load
them. Also probably would be even better to load the schema strings and any
dependent schema to avoid the schemasToLoad property, using this:
https://github.com/metadata101/iso19139.nl.services.1.2.1/blob/ceb6c9c32d97659cb787e57ff5cbe41754fe1e5a/src/main/plugin/iso19139.nl.services.1.2.1/schema-ident.xml#L11
Sounds good to me. For the editor form using Spring, I did similar things
using the startsWith comparison on schema identifiers.
https://github.com/geonetwork/core-geonetwork/blob/api/services/src/main/java/org/fao/geonet/api/records/editing/MetadataEditingApi.java#L692
Maybe we could use the same approach for both the editor files and
formatters.
Francois
Regards,
Jose García
On Mon, Jul 4, 2016 at 10:57 AM, Francois Prunayre <fx.prunayre@anonymised.com>
wrote:
Hi Jose
2016-07-01 9:34 GMT+02:00 Jose Garcia <jose.garcia@anonymised.com>:
Hi
We have move to use xslt formatter instead of the default groovy one,
due to lots of problems with this formatter in some servers and the
difficulty to determine what is causing that, but thats another history ...
The xslt formatter works fine, at least with default iso19139, but with
a custom profile we were getting this:
2016-06-30 14:34:10,532 ERROR [jeeves] - Error occurred within a
transaction
; SystemID:
file:///nfs_dply/pdok/ngr3/data/formatter//xslt/render-layout.xsl; Line#:
105; Column#: -1
After spending some time trying to figure out what was happening, found
this property in the formatter that limits the translations loaded for the
xslt formatter to the schemas listed:
https://eos.geocat.net/gitlab/ngr/geonetwork/blob/ngr3/schemas/iso19139.nl.geografie.1.3.1/src/main/plugin/iso19139.nl.geografie.1.3.1/formatter/config.properties#L24
schemasToLoad=iso19139
If you create a schema based on iso19139, you copy that file and don't
notice that you need to change that value with the name of your schema, as
there's a complete lack of documentation for this.
Does somebody knows why is that required? The formatter knows the schema
of the metadata that is processing, why not load the files related to the
metadata schema and relay in a external file configuration? Maybe I'm
missing something?
Jesse made some docs when making the proposal
https://github.com/geonetwork/core-geonetwork/wiki/Schema-Formatters-and-Metadata-Views
Probably we need to add more doc to here
http://geonetwork-opensource.org/manuals/trunk/eng/users/tutorials/customui/view/formatter.html
Cheers.
Francois
Regards,
Jose García
--
*Vriendelijke groeten / Kind regards,Jose García
<http://www.geocat.net/>Veenderweg 136721 WD BennekomThe NetherlandsT: +31
(0)318 416664 <+31318416664> <https://www.facebook.com/geocatbv>
<https://twitter.com/geocat_bv>
<https://plus.google.com/u/1/+GeocatNetbv/posts>Please consider the
environment before printing this email.*
------------------------------------------------------------------------------
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
_______________________________________________
GeoNetwork-devel mailing list
GeoNetwork-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at
http://sourceforge.net/projects/geonetwork
--
*Vriendelijke groeten / Kind regards,Jose García
<http://www.geocat.net/>Veenderweg 136721 WD BennekomThe NetherlandsT: +31
(0)318 416664 <+31318416664> <https://www.facebook.com/geocatbv>
<https://twitter.com/geocat_bv>
<https://plus.google.com/u/1/+GeocatNetbv/posts>Please consider the
environment before printing this email.*
Hi Francois
Indeed the code looks really similar. I’ll take a look to unify it.
Regards,
Jose García
···
On Mon, Jul 4, 2016 at 12:23 PM, Francois Prunayre <fx.prunayre@anonymised.com> wrote:
–
2016-07-04 11:11 GMT+02:00 Jose Garcia <jose.garcia@anonymised.com>:
Hi Francois
Thanks for pointing that, but no documentation about the specific fields that can be configured in config.properties file (https://github.com/geonetwork/core-geonetwork/wiki/Schema-Formatters-and-Metadata-Views#shared-files).
I think the best would be to load at least by default the translation files for the current schema (without requiring explicit definition of schemasToLoad). If also additional schemas defined in schemasToLoad, load them. Also probably would be even better to load the schema strings and any dependent schema to avoid the schemasToLoad property, using this:
https://github.com/metadata101/iso19139.nl.services.1.2.1/blob/ceb6c9c32d97659cb787e57ff5cbe41754fe1e5a/src/main/plugin/iso19139.nl.services.1.2.1/schema-ident.xml#L11
Sounds good to me. For the editor form using Spring, I did similar things using the startsWith comparison on schema identifiers. https://github.com/geonetwork/core-geonetwork/blob/api/services/src/main/java/org/fao/geonet/api/records/editing/MetadataEditingApi.java#L692 Maybe we could use the same approach for both the editor files and formatters.
Francois
Regards,
Jose García
On Mon, Jul 4, 2016 at 10:57 AM, Francois Prunayre <fx.prunayre@anonymised.com> wrote:
Hi Jose
–
Vriendelijke groeten / Kind regards,
Jose García
Veenderweg 13
6721 WD Bennekom
The Netherlands
T: +31 (0)318 416664
Please consider the environment before printing this email.
2016-07-01 9:34 GMT+02:00 Jose Garcia <jose.garcia@anonymised.com>:
Hi
We have move to use xslt formatter instead of the default groovy one, due to lots of problems with this formatter in some servers and the difficulty to determine what is causing that, but thats another history …
The xslt formatter works fine, at least with default iso19139, but with a custom profile we were getting this:
2016-06-30 14:34:10,532 ERROR [jeeves] - Error occurred within a transaction
; SystemID: file:///nfs_dply/pdok/ngr3/data/formatter//xslt/render-layout.xsl; Line#: 105; Column#: -1
After spending some time trying to figure out what was happening, found this property in the formatter that limits the translations loaded for the xslt formatter to the schemas listed:
https://eos.geocat.net/gitlab/ngr/geonetwork/blob/ngr3/schemas/iso19139.nl.geografie.1.3.1/src/main/plugin/iso19139.nl.geografie.1.3.1/formatter/config.properties#L24
schemasToLoad=iso19139
If you create a schema based on iso19139, you copy that file and don’t notice that you need to change that value with the name of your schema, as there’s a complete lack of documentation for this.
Does somebody knows why is that required? The formatter knows the schema of the metadata that is processing, why not load the files related to the metadata schema and relay in a external file configuration? Maybe I’m missing something?
Jesse made some docs when making the proposal
https://github.com/geonetwork/core-geonetwork/wiki/Schema-Formatters-and-Metadata-Views
Probably we need to add more doc to here http://geonetwork-opensource.org/manuals/trunk/eng/users/tutorials/customui/view/formatter.html
Cheers.
Francois
Regards,
Jose García
–
Vriendelijke groeten / Kind regards,
Jose García
Veenderweg 13
6721 WD Bennekom
The Netherlands
T: +31 (0)318 416664
Please consider the environment before printing this email.
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
GeoNetwork-devel mailing list
GeoNetwork-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork
Vriendelijke groeten / Kind regards,
Jose García
Veenderweg 13
6721 WD Bennekom
The Netherlands
T: +31 (0)318 416664
Please consider the environment before printing this email.