Dear all,
Monday 1st to Tuesday 2nd June, we are organizing a client application codesprint.
See
https://github.com/geonetwork/core-geonetwork/wiki/GeoNetwork-client-app-building-blocks-codesprint-1st-and-2nd-June-2020 for details.
Do not hesitate to join us to contribute to this topic.
Kind regards.
Francois
Hi Francois
Is this going to be an online meeting? Or how does it work to contribute?
About the frameworks, I don’t have a strong opinion. Only used a bit of React for some personal stuff, but don’t have enough knowledge to say that it is better or worse than Angular, for example. Some of my colleagues are better to provide their experience with these Javascript frameworks and styling frameworks (css/sass/less).
For me is more relevant to agree on the development patterns, some basic items I think we should improve from the current implementation (please take as a list of suggestions to improve, not a critic):
Define UI design templates, so pages look as unified as possible across the application.
Unified validation across all the forms in the application, trying to use some standard validation libraries instead of handmade code and use in all forms.
Improve the current asynchronous code to retrieve the information from the catalog that is needed in the UI. I can think about settings or user details for example. In current code, some places use Angular promises, other places not, so depends on how fast the application loads sometimes the information is available or not. Probably it’s due to not being an expert in JS and probably in my code I haven’t used this always in the best way possible, but this happens across o. But it is relevant to define some development patterns also as in point 1) and for sure define all the basic data required to be available on the application load and make this information easily accessible to all the components.
Check if other alternatives than wroj4 can be used. At least for me the tests on React were really good to see any change was really picked up immediately (I’m pretty sure the same can be done with Angular and many other frameworks).
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 Jose,
Le mer. 27 mai 2020 à 11:11, Jose Garcia <jose.garcia@anonymised.com> a écrit :
Hi Francois
Is this going to be an online meeting? Or how does it work to contribute?
About the frameworks, I don’t have a strong opinion.
Depends a bit on who wants to participate. I think it does not make sense to have too many people on this mainly because we all have a clear idea of what needs improvement on the existing client side app (see https://github.com/geonetwork/core-geonetwork/wiki/GeoNetwork-client-app-building-blocks-codesprint-1st-and-2nd-June-2020#issues-in-current-app. I added your points to the list too). Working a lot on the Elasticsearch migration branch during the past months, I really think we need to rework the client side - it also looks like some projects have expectations on client side features that we can not achieve without a major rework (eg. shadow dom & web components). So having a first guidelines, a basic project setup on which we can start making prototypes would be welcomed.
Like you, I don’t have strong opinion about the frameworks and I think Florent & Olivier (and maybe Michel on styling?) are the relevant persons to make pragmatic & efficient choices to define the basis.
We started a document with a list of entries (eg. Architecture, Modules, Configuration, Libraries, Style, i18n) with for now no technical choices.
On how to contribute, we were thinking that everyone can put concerns & recommendations on the wiki then:
What do you think about this approach? Don’t hesitate to give ideas here or on the wiki page.
Also note, that the main purpose of this work is to be able to make relevant proposal based on ongoing projects limitations & requirements during the 23rd June online users meeting in order to discuss with users and developers about how could GeoNetwork evolved on the client side.
Cheers.
Francois
Only used a bit of React for some personal stuff, but don’t have enough knowledge to say that it is better or worse than Angular, for example. Some of my colleagues are better to provide their experience with these Javascript frameworks and styling frameworks (css/sass/less).
For me is more relevant to agree on the development patterns, some basic items I think we should improve from the current implementation (please take as a list of suggestions to improve, not a critic):
Define UI design templates, so pages look as unified as possible across the application.
Unified validation across all the forms in the application, trying to use some standard validation libraries instead of handmade code and use in all forms.
Improve the current asynchronous code to retrieve the information from the catalog that is needed in the UI. I can think about settings or user details for example. In current code, some places use Angular promises, other places not, so depends on how fast the application loads sometimes the information is available or not. Probably it’s due to not being an expert in JS and probably in my code I haven’t used this always in the best way possible, but this happens across o. But it is relevant to define some development patterns also as in point 1) and for sure define all the basic data required to be available on the application load and make this information easily accessible to all the components.
Check if other alternatives than wroj4 can be used. At least for me the tests on React were really good to see any change was really picked up immediately (I’m pretty sure the same can be done with Angular and many other frameworks).
Regards,
Jose GarcíaOn Wed, May 27, 2020 at 7:50 AM Francois Prunayre <fx.prunayre@anonymised.com> wrote:
Dear all,
Monday 1st to Tuesday 2nd June, we are organizing a client application codesprint.
See
https://github.com/geonetwork/core-geonetwork/wiki/GeoNetwork-client-app-building-blocks-codesprint-1st-and-2nd-June-2020 for details.Do not hesitate to join us to contribute to this topic.
Kind regards.
Francois
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 416664Please consider the environment before printing this email.
Hi Francois
Thanks for the feedback, sounds a good approach to me.
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 François,
A small detail, but important to us is that Monday is a public holiday in The Netherlands. So it would be nice if the sprint can be shifted with one or two days to also allow Michel or Paul to participate?
Cheers,
Jeroen
Op 27 mei 2020 om 15:21 heeft Francois Prunayre fx.prunayre@anonymised.com het volgende geschreven:
Hi Jose,
Le mer. 27 mai 2020 à 11:11, Jose Garcia <jose.garcia@anonymised.com> a écrit :
Hi Francois
Is this going to be an online meeting? Or how does it work to contribute?
About the frameworks, I don’t have a strong opinion.
Depends a bit on who wants to participate. I think it does not make sense to have too many people on this mainly because we all have a clear idea of what needs improvement on the existing client side app (see https://github.com/geonetwork/core-geonetwork/wiki/GeoNetwork-client-app-building-blocks-codesprint-1st-and-2nd-June-2020#issues-in-current-app. I added your points to the list too). Working a lot on the Elasticsearch migration branch during the past months, I really think we need to rework the client side - it also looks like some projects have expectations on client side features that we can not achieve without a major rework (eg. shadow dom & web components). So having a first guidelines, a basic project setup on which we can start making prototypes would be welcomed.
Like you, I don’t have strong opinion about the frameworks and I think Florent & Olivier (and maybe Michel on styling?) are the relevant persons to make pragmatic & efficient choices to define the basis.
We started a document with a list of entries (eg. Architecture, Modules, Configuration, Libraries, Style, i18n) with for now no technical choices.
On how to contribute, we were thinking that everyone can put concerns & recommendations on the wiki then:
- Monday morning / Brainstorming based on concerns & recommendations from everyone. First draft proposal (Florent, Olivier, Francois)
- Monday afternoon / Online meeting to present the options (All who are available)
- Tuesday / Write a first guideline & project basis setup
What do you think about this approach? Don’t hesitate to give ideas here or on the wiki page.
Also note, that the main purpose of this work is to be able to make relevant proposal based on ongoing projects limitations & requirements during the 23rd June online users meeting in order to discuss with users and developers about how could GeoNetwork evolved on the client side.
Cheers.
FrancoisOnly used a bit of React for some personal stuff, but don’t have enough knowledge to say that it is better or worse than Angular, for example. Some of my colleagues are better to provide their experience with these Javascript frameworks and styling frameworks (css/sass/less).
For me is more relevant to agree on the development patterns, some basic items I think we should improve from the current implementation (please take as a list of suggestions to improve, not a critic):
Define UI design templates, so pages look as unified as possible across the application.
Unified validation across all the forms in the application, trying to use some standard validation libraries instead of handmade code and use in all forms.
Improve the current asynchronous code to retrieve the information from the catalog that is needed in the UI. I can think about settings or user details for example. In current code, some places use Angular promises, other places not, so depends on how fast the application loads sometimes the information is available or not. Probably it’s due to not being an expert in JS and probably in my code I haven’t used this always in the best way possible, but this happens across o. But it is relevant to define some development patterns also as in point 1) and for sure define all the basic data required to be available on the application load and make this information easily accessible to all the components.
Check if other alternatives than wroj4 can be used. At least for me the tests on React were really good to see any change was really picked up immediately (I’m pretty sure the same can be done with Angular and many other frameworks).
Regards,
Jose GarcíaOn Wed, May 27, 2020 at 7:50 AM Francois Prunayre <fx.prunayre@anonymised.com> wrote:
Dear all,
Monday 1st to Tuesday 2nd June, we are organizing a client application codesprint.
See
https://github.com/geonetwork/core-geonetwork/wiki/GeoNetwork-client-app-building-blocks-codesprint-1st-and-2nd-June-2020 for details.Do not hesitate to join us to contribute to this topic.
Kind regards.
Francois
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 416664Please consider the environment before printing this email.
GeoNetwork-devel mailing list
GeoNetwork-devel@anonymised.com.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork
Hi Francois,
Just a small bit from my side, mostly on UI and Frameworks. I have been working a lot on views and customising them lately, and a couple of things (not a complete list) were (a bit) troublesome:
• the large size of all the CSS (I still have only a vague understanding of Wro4j)
• continued overruling of styles
• HTML I want to change is outside of the view directory and therefore unreachable
• sometimes the guidelines of the UI framework (Bootstrap) are interpreted loosely
• ‘difficult' HTML for the Editor
I have to confess, I’m guilty of a lot of these ‘crimes’.
Another item for the agenda would be Accessibility, which will be a European directive (see also https://github.com/geonetwork/core-geonetwork/issues/4694).
I don’t have a preference for a framework, other than just curiosity, but what I see more and more is the use of SCSS. That would be interesting.
But when we pick a UI framework, let’s say Bootstrap 4, let’s try to use its guidelines more strict, write clean, accessible HTML and use the frameworks theming system. In this case `custom.scss` (https://getbootstrap.com/docs/4.5/getting-started/theming/). First try to build the pages with the HTML and Classes the framework provides, and do customisation in just one place. Hope I’m making sense.
Regards
Michel
On 27 May 2020, 15:21 +0200, Francois Prunayre <fx.prunayre@anonymised.com>, wrote:
Hi Jose,
> Le mer. 27 mai 2020 à 11:11, Jose Garcia <jose.garcia@anonymised.com.437...> a écrit :
> > Hi Francois
> >
> > Is this going to be an online meeting? Or how does it work to contribute?
> > About the frameworks, I don't have a strong opinion.
>
> Depends a bit on who wants to participate. I think it does not make sense to have too many people on this mainly because we all have a clear idea of what needs improvement on the existing client side app (see https://github.com/geonetwork/core-geonetwork/wiki/GeoNetwork-client-app-building-blocks-codesprint-1st-and-2nd-June-2020#issues-in-current-app. I added your points to the list too). Working a lot on the Elasticsearch migration branch during the past months, I really think we need to rework the client side - it also looks like some projects have expectations on client side features that we can not achieve without a major rework (eg. shadow dom & web components). So having a first guidelines, a basic project setup on which we can start making prototypes would be welcomed.
>
> Like you, I don't have strong opinion about the frameworks and I think Florent & Olivier (and maybe Michel on styling?) are the relevant persons to make pragmatic & efficient choices to define the basis.
>
> We started a document with a list of entries (eg. Architecture, Modules, Configuration, Libraries, Style, i18n) with for now no technical choices.
>
> On how to contribute, we were thinking that everyone can put concerns & recommendations on the wiki then:
> * Monday morning / Brainstorming based on concerns & recommendations from everyone. First draft proposal (Florent, Olivier, Francois)
> * Monday afternoon / Online meeting to present the options (All who are available)
> * Tuesday / Write a first guideline & project basis setup
>
> What do you think about this approach? Don't hesitate to give ideas here or on the wiki page.
>
> Also note, that the main purpose of this work is to be able to make relevant proposal based on ongoing projects limitations & requirements during the 23rd June online users meeting in order to discuss with users and developers about how could GeoNetwork evolved on the client side.
>
> Cheers.
> Francois
>
>
>
> > Only used a bit of React for some personal stuff, but don't have enough knowledge to say that it is better or worse than Angular, for example. Some of my colleagues are better to provide their experience with these Javascript frameworks and styling frameworks (css/sass/less).
> >
> > For me is more relevant to agree on the development patterns, some basic items I think we should improve from the current implementation (please take as a list of suggestions to improve, not a critic):
> >
> > 1) Define UI design templates, so pages look as unified as possible across the application.
> >
> > 2) Unified validation across all the forms in the application, trying to use some standard validation libraries instead of handmade code and use in all forms.
> >
> > 3) Improve the current asynchronous code to retrieve the information from the catalog that is needed in the UI. I can think about settings or user details for example. In current code, some places use Angular promises, other places not, so depends on how fast the application loads sometimes the information is available or not. Probably it's due to not being an expert in JS and probably in my code I haven't used this always in the best way possible, but this happens across o. But it is relevant to define some development patterns also as in point 1) and for sure define all the basic data required to be available on the application load and make this information easily accessible to all the components.
> >
> > 4) Check if other alternatives than wroj4 can be used. At least for me the tests on React were really good to see any change was really picked up immediately (I'm pretty sure the same can be done with Angular and many other frameworks).
> >
> > Regards,
> > Jose García
> >
> > > On Wed, May 27, 2020 at 7:50 AM Francois Prunayre <fx.prunayre@anonymised.com1...> wrote:
> > > > Dear all,
> > > >
> > > > Monday 1st to Tuesday 2nd June, we are organizing a client application codesprint.
> > > > See
> > > > https://github.com/geonetwork/core-geonetwork/wiki/GeoNetwork-client-app-building-blocks-codesprint-1st-and-2nd-June-2020 for details.
> > > >
> > > > Do not hesitate to join us to contribute to this topic.
> > > >
> > > > Kind regards.
> > > >
> > > > Francois
> > > > _______________________________________________
> > > > 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.
_______________________________________________
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
Hi Michel,
Le mer. 27 mai 2020 à 16:31, Michel Gabriel <michel.gabriel@anonymised.com> a
écrit :
Hi Francois,
Just a small bit from my side, mostly on UI and Frameworks. I have been
working a lot on views and customising them lately, and a couple of things
(not a complete list) were (a bit) troublesome:- the large size of all the CSS (I still have only a vague
understanding of Wro4j)
- continued overruling of styles
- HTML I want to change is outside of the view directory and therefore
unreachable
- sometimes the guidelines of the UI framework (Bootstrap) are
interpreted loosely
- ‘difficult' HTML for the Editor
Added to the wiki.
I have to confess, I’m guilty of a lot of these ‘crimes’.
You're not alone 
Another item for the agenda would be Accessibility, which will be a
European directive (see also
https://github.com/geonetwork/core-geonetwork/issues/4694).
It is on the list.
I don’t have a preference for a framework, other than just curiosity, but
what I see more and more is the use of SCSS. That would be interesting.
Added to the options list.
But when we pick a UI framework, let’s say Bootstrap 4, let’s try to use
its guidelines more strict, write clean, accessible HTML and use the
frameworks theming system. In this case `custom.scss` (
https://getbootstrap.com/docs/4.5/getting-started/theming/). First try to
build the pages with the HTML and Classes the framework provides, and do
customisation in just one place. Hope I’m making sense.
Thanks for the inputs.
Francois
Regards
Michel
On 27 May 2020, 15:21 +0200, Francois Prunayre <fx.prunayre@anonymised.com>,
wrote:Hi Jose,
Le mer. 27 mai 2020 à 11:11, Jose Garcia <jose.garcia@anonymised.com> a
écrit :Hi Francois
Is this going to be an online meeting? Or how does it work to contribute?
About the frameworks, I don't have a strong opinion.
Depends a bit on who wants to participate. I think it does not make sense
to have too many people on this mainly because we all have a clear idea of
what needs improvement on the existing client side app (see
https://github.com/geonetwork/core-geonetwork/wiki/GeoNetwork-client-app-building-blocks-codesprint-1st-and-2nd-June-2020#issues-in-current-app.
I added your points to the list too). Working a lot on the Elasticsearch
migration branch during the past months, I really think we need to rework
the client side - it also looks like some projects have expectations on
client side features that we can not achieve without a major rework (eg.
shadow dom & web components). So having a first guidelines, a basic project
setup on which we can start making prototypes would be welcomed.Like you, I don't have strong opinion about the frameworks and I think
Florent & Olivier (and maybe Michel on styling?) are the relevant persons
to make pragmatic & efficient choices to define the basis.We started a document with a list of entries (eg. Architecture, Modules,
Configuration, Libraries, Style, i18n) with for now no technical choices.On how to contribute, we were thinking that everyone can put concerns &
recommendations on the wiki then:
* Monday morning / Brainstorming based on concerns & recommendations from
everyone. First draft proposal (Florent, Olivier, Francois)
* Monday afternoon / Online meeting to present the options (All who are
available)
* Tuesday / Write a first guideline & project basis setupWhat do you think about this approach? Don't hesitate to give ideas here
or on the wiki page.Also note, that the main purpose of this work is to be able to make
relevant proposal based on ongoing projects limitations & requirements
during the 23rd June online users meeting in order to discuss with users
and developers about how could GeoNetwork evolved on the client side.Cheers.
FrancoisOnly used a bit of React for some personal stuff, but don't have enough
knowledge to say that it is better or worse than Angular, for example. Some
of my colleagues are better to provide their experience with these
Javascript frameworks and styling frameworks (css/sass/less).For me is more relevant to agree on the development patterns, some basic
items I think we should improve from the current implementation (please
take as a list of suggestions to improve, not a critic):1) Define UI design templates, so pages look as unified as possible
across the application.2) Unified validation across all the forms in the application, trying to
use some standard validation libraries instead of handmade code and use in
all forms.3) Improve the current asynchronous code to retrieve the information from
the catalog that is needed in the UI. I can think about settings or user
details for example. In current code, some places use Angular promises,
other places not, so depends on how fast the application loads sometimes
the information is available or not. Probably it's due to not being an
expert in JS and probably in my code I haven't used this always in the best
way possible, but this happens across o. But it is relevant to define some
development patterns also as in point 1) and for sure define all the basic
data required to be available on the application load and make this
information easily accessible to all the components.4) Check if other alternatives than wroj4 can be used. At least for me
the tests on React were really good to see any change was really picked up
immediately (I'm pretty sure the same can be done with Angular and many
other frameworks).Regards,
Jose GarcíaOn Wed, May 27, 2020 at 7:50 AM Francois Prunayre <fx.prunayre@anonymised.com>
wrote:Dear all,
Monday 1st to Tuesday 2nd June, we are organizing a client application
codesprint.
SeeDo not hesitate to join us to contribute to this topic.
Kind regards.
Francois
_______________________________________________
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 13 6721 WD Bennekom The Netherlands
T: +31 (0)318 416664 <+31318416664> Please consider the environment before
printing this email.*_______________________________________________
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
Hi Jeroen,
after checking here, it sounds difficult for some of us to shift it.
What we can do is a meeting Tuesday morning so Michel and Paul can join.
I’m also fine to continue sprinting for one more day on Wednesday if you’ve availability.
We can also plan for another sprint on the same topic to continue the work as we will not meet in Bolsena this year - and we will for sure not cover all the aspect in 2 days.
Cheers.
Francois
Le mer. 27 mai 2020 à 16:04, Jeroen Ticheler <jeroen.ticheler@anonymised.com> a écrit :
Hi François,
A small detail, but important to us is that Monday is a public holiday in The Netherlands. So it would be nice if the sprint can be shifted with one or two days to also allow Michel or Paul to participate?
Cheers,
JeroenOp 27 mei 2020 om 15:21 heeft Francois Prunayre <fx.prunayre@anonymised.com.> het volgende geschreven:
Hi Jose,
Le mer. 27 mai 2020 à 11:11, Jose Garcia <jose.garcia@anonymised.com> a écrit :
Hi Francois
Is this going to be an online meeting? Or how does it work to contribute?
About the frameworks, I don’t have a strong opinion.
Depends a bit on who wants to participate. I think it does not make sense to have too many people on this mainly because we all have a clear idea of what needs improvement on the existing client side app (see https://github.com/geonetwork/core-geonetwork/wiki/GeoNetwork-client-app-building-blocks-codesprint-1st-and-2nd-June-2020#issues-in-current-app. I added your points to the list too). Working a lot on the Elasticsearch migration branch during the past months, I really think we need to rework the client side - it also looks like some projects have expectations on client side features that we can not achieve without a major rework (eg. shadow dom & web components). So having a first guidelines, a basic project setup on which we can start making prototypes would be welcomed.
Like you, I don’t have strong opinion about the frameworks and I think Florent & Olivier (and maybe Michel on styling?) are the relevant persons to make pragmatic & efficient choices to define the basis.
We started a document with a list of entries (eg. Architecture, Modules, Configuration, Libraries, Style, i18n) with for now no technical choices.
On how to contribute, we were thinking that everyone can put concerns & recommendations on the wiki then:
- Monday morning / Brainstorming based on concerns & recommendations from everyone. First draft proposal (Florent, Olivier, Francois)
- Monday afternoon / Online meeting to present the options (All who are available)
- Tuesday / Write a first guideline & project basis setup
What do you think about this approach? Don’t hesitate to give ideas here or on the wiki page.
Also note, that the main purpose of this work is to be able to make relevant proposal based on ongoing projects limitations & requirements during the 23rd June online users meeting in order to discuss with users and developers about how could GeoNetwork evolved on the client side.
Cheers.
FrancoisOnly used a bit of React for some personal stuff, but don’t have enough knowledge to say that it is better or worse than Angular, for example. Some of my colleagues are better to provide their experience with these Javascript frameworks and styling frameworks (css/sass/less).
For me is more relevant to agree on the development patterns, some basic items I think we should improve from the current implementation (please take as a list of suggestions to improve, not a critic):
Define UI design templates, so pages look as unified as possible across the application.
Unified validation across all the forms in the application, trying to use some standard validation libraries instead of handmade code and use in all forms.
Improve the current asynchronous code to retrieve the information from the catalog that is needed in the UI. I can think about settings or user details for example. In current code, some places use Angular promises, other places not, so depends on how fast the application loads sometimes the information is available or not. Probably it’s due to not being an expert in JS and probably in my code I haven’t used this always in the best way possible, but this happens across o. But it is relevant to define some development patterns also as in point 1) and for sure define all the basic data required to be available on the application load and make this information easily accessible to all the components.
Check if other alternatives than wroj4 can be used. At least for me the tests on React were really good to see any change was really picked up immediately (I’m pretty sure the same can be done with Angular and many other frameworks).
Regards,
Jose GarcíaOn Wed, May 27, 2020 at 7:50 AM Francois Prunayre <fx.prunayre@anonymised.com> wrote:
Dear all,
Monday 1st to Tuesday 2nd June, we are organizing a client application codesprint.
See
https://github.com/geonetwork/core-geonetwork/wiki/GeoNetwork-client-app-building-blocks-codesprint-1st-and-2nd-June-2020 for details.Do not hesitate to join us to contribute to this topic.
Kind regards.
Francois
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 416664Please consider the environment before printing this email.
GeoNetwork-devel mailing list
GeoNetwork-devel@anonymised.come.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork
Hi, checked with Michel & Paul we will make a progress meeting Tuesday morning at 9h30 CET.
Francois
Le jeu. 28 mai 2020 à 15:47, Francois Prunayre <fx.prunayre@anonymised.com> a écrit :
Hi Jeroen,
after checking here, it sounds difficult for some of us to shift it.
What we can do is a meeting Tuesday morning so Michel and Paul can join.
I’m also fine to continue sprinting for one more day on Wednesday if you’ve availability.
We can also plan for another sprint on the same topic to continue the work as we will not meet in Bolsena this year - and we will for sure not cover all the aspect in 2 days.Cheers.
Francois
Le mer. 27 mai 2020 à 16:04, Jeroen Ticheler <jeroen.ticheler@anonymised.com> a écrit :
Hi François,
A small detail, but important to us is that Monday is a public holiday in The Netherlands. So it would be nice if the sprint can be shifted with one or two days to also allow Michel or Paul to participate?Cheers,
JeroenOp 27 mei 2020 om 15:21 heeft Francois Prunayre <fx.prunayre@anonymised.com> het volgende geschreven:
Hi Jose,
Le mer. 27 mai 2020 à 11:11, Jose Garcia <jose.garcia@anonymised.com> a écrit :
Hi Francois
Is this going to be an online meeting? Or how does it work to contribute?
About the frameworks, I don’t have a strong opinion.
Depends a bit on who wants to participate. I think it does not make sense to have too many people on this mainly because we all have a clear idea of what needs improvement on the existing client side app (see https://github.com/geonetwork/core-geonetwork/wiki/GeoNetwork-client-app-building-blocks-codesprint-1st-and-2nd-June-2020#issues-in-current-app. I added your points to the list too). Working a lot on the Elasticsearch migration branch during the past months, I really think we need to rework the client side - it also looks like some projects have expectations on client side features that we can not achieve without a major rework (eg. shadow dom & web components). So having a first guidelines, a basic project setup on which we can start making prototypes would be welcomed.
Like you, I don’t have strong opinion about the frameworks and I think Florent & Olivier (and maybe Michel on styling?) are the relevant persons to make pragmatic & efficient choices to define the basis.
We started a document with a list of entries (eg. Architecture, Modules, Configuration, Libraries, Style, i18n) with for now no technical choices.
On how to contribute, we were thinking that everyone can put concerns & recommendations on the wiki then:
- Monday morning / Brainstorming based on concerns & recommendations from everyone. First draft proposal (Florent, Olivier, Francois)
- Monday afternoon / Online meeting to present the options (All who are available)
- Tuesday / Write a first guideline & project basis setup
What do you think about this approach? Don’t hesitate to give ideas here or on the wiki page.
Also note, that the main purpose of this work is to be able to make relevant proposal based on ongoing projects limitations & requirements during the 23rd June online users meeting in order to discuss with users and developers about how could GeoNetwork evolved on the client side.
Cheers.
FrancoisOnly used a bit of React for some personal stuff, but don’t have enough knowledge to say that it is better or worse than Angular, for example. Some of my colleagues are better to provide their experience with these Javascript frameworks and styling frameworks (css/sass/less).
For me is more relevant to agree on the development patterns, some basic items I think we should improve from the current implementation (please take as a list of suggestions to improve, not a critic):
Define UI design templates, so pages look as unified as possible across the application.
Unified validation across all the forms in the application, trying to use some standard validation libraries instead of handmade code and use in all forms.
Improve the current asynchronous code to retrieve the information from the catalog that is needed in the UI. I can think about settings or user details for example. In current code, some places use Angular promises, other places not, so depends on how fast the application loads sometimes the information is available or not. Probably it’s due to not being an expert in JS and probably in my code I haven’t used this always in the best way possible, but this happens across o. But it is relevant to define some development patterns also as in point 1) and for sure define all the basic data required to be available on the application load and make this information easily accessible to all the components.
Check if other alternatives than wroj4 can be used. At least for me the tests on React were really good to see any change was really picked up immediately (I’m pretty sure the same can be done with Angular and many other frameworks).
Regards,
Jose GarcíaOn Wed, May 27, 2020 at 7:50 AM Francois Prunayre <fx.prunayre@anonymised.com…31…> wrote:
Dear all,
Monday 1st to Tuesday 2nd June, we are organizing a client application codesprint.
See
https://github.com/geonetwork/core-geonetwork/wiki/GeoNetwork-client-app-building-blocks-codesprint-1st-and-2nd-June-2020 for details.Do not hesitate to join us to contribute to this topic.
Kind regards.
Francois
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 416664Please consider the environment before printing this email.
GeoNetwork-devel mailing list
GeoNetwork-devel@anonymised.come.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork
Okay, sounds good!
Jeroen Ticheler
GeoCat bv
Veenderweg 13
6721 WD Bennekom
Tel: +31 (0)6 81286572
Op 29 mei 2020 om 12:19 heeft Francois Prunayre fx.prunayre@anonymised.com het volgende geschreven:
Hi, checked with Michel & Paul we will make a progress meeting Tuesday morning at 9h30 CET.
Francois
Le jeu. 28 mai 2020 à 15:47, Francois Prunayre <fx.prunayre@anonymised.com> a écrit :
Hi Jeroen,
after checking here, it sounds difficult for some of us to shift it.
What we can do is a meeting Tuesday morning so Michel and Paul can join.
I’m also fine to continue sprinting for one more day on Wednesday if you’ve availability.
We can also plan for another sprint on the same topic to continue the work as we will not meet in Bolsena this year - and we will for sure not cover all the aspect in 2 days.Cheers.
Francois
Le mer. 27 mai 2020 à 16:04, Jeroen Ticheler <jeroen.ticheler@anonymised.com> a écrit :
Hi François,
A small detail, but important to us is that Monday is a public holiday in The Netherlands. So it would be nice if the sprint can be shifted with one or two days to also allow Michel or Paul to participate?Cheers,
JeroenOp 27 mei 2020 om 15:21 heeft Francois Prunayre <fx.prunayre@anonymised.com> het volgende geschreven:
Hi Jose,
Le mer. 27 mai 2020 à 11:11, Jose Garcia <jose.garcia@anonymised.com> a écrit :
Hi Francois
Is this going to be an online meeting? Or how does it work to contribute?
About the frameworks, I don’t have a strong opinion.
Depends a bit on who wants to participate. I think it does not make sense to have too many people on this mainly because we all have a clear idea of what needs improvement on the existing client side app (see https://github.com/geonetwork/core-geonetwork/wiki/GeoNetwork-client-app-building-blocks-codesprint-1st-and-2nd-June-2020#issues-in-current-app. I added your points to the list too). Working a lot on the Elasticsearch migration branch during the past months, I really think we need to rework the client side - it also looks like some projects have expectations on client side features that we can not achieve without a major rework (eg. shadow dom & web components). So having a first guidelines, a basic project setup on which we can start making prototypes would be welcomed.
Like you, I don’t have strong opinion about the frameworks and I think Florent & Olivier (and maybe Michel on styling?) are the relevant persons to make pragmatic & efficient choices to define the basis.
We started a document with a list of entries (eg. Architecture, Modules, Configuration, Libraries, Style, i18n) with for now no technical choices.
On how to contribute, we were thinking that everyone can put concerns & recommendations on the wiki then:
- Monday morning / Brainstorming based on concerns & recommendations from everyone. First draft proposal (Florent, Olivier, Francois)
- Monday afternoon / Online meeting to present the options (All who are available)
- Tuesday / Write a first guideline & project basis setup
What do you think about this approach? Don’t hesitate to give ideas here or on the wiki page.
Also note, that the main purpose of this work is to be able to make relevant proposal based on ongoing projects limitations & requirements during the 23rd June online users meeting in order to discuss with users and developers about how could GeoNetwork evolved on the client side.
Cheers.
FrancoisOnly used a bit of React for some personal stuff, but don’t have enough knowledge to say that it is better or worse than Angular, for example. Some of my colleagues are better to provide their experience with these Javascript frameworks and styling frameworks (css/sass/less).
For me is more relevant to agree on the development patterns, some basic items I think we should improve from the current implementation (please take as a list of suggestions to improve, not a critic):
Define UI design templates, so pages look as unified as possible across the application.
Unified validation across all the forms in the application, trying to use some standard validation libraries instead of handmade code and use in all forms.
Improve the current asynchronous code to retrieve the information from the catalog that is needed in the UI. I can think about settings or user details for example. In current code, some places use Angular promises, other places not, so depends on how fast the application loads sometimes the information is available or not. Probably it’s due to not being an expert in JS and probably in my code I haven’t used this always in the best way possible, but this happens across o. But it is relevant to define some development patterns also as in point 1) and for sure define all the basic data required to be available on the application load and make this information easily accessible to all the components.
Check if other alternatives than wroj4 can be used. At least for me the tests on React were really good to see any change was really picked up immediately (I’m pretty sure the same can be done with Angular and many other frameworks).
Regards,
Jose GarcíaOn Wed, May 27, 2020 at 7:50 AM Francois Prunayre <fx.prunayre@anonymised.com> wrote:
Dear all,
Monday 1st to Tuesday 2nd June, we are organizing a client application codesprint.
See
https://github.com/geonetwork/core-geonetwork/wiki/GeoNetwork-client-app-building-blocks-codesprint-1st-and-2nd-June-2020 for details.Do not hesitate to join us to contribute to this topic.
Kind regards.
Francois
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 416664Please consider the environment before printing this email.
GeoNetwork-devel mailing list
GeoNetwork-devel@anonymised.come.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork