[GeoNetwork-devel] Ajax use in the future Geonetwork

Dear Arnaud,
Thanks for the post!

I can give a rough answer, being that we plan to move more services towards AJAX based ones. The libraries used are indeed the ones you pointed at.

The plan is to eventually move all pages to ajax based ones, but help is welcome in that respect. Both Andrea and Stefano have started to port services to use ajax and Andrea has been prototyping portlets over the last days too. I think that based on these experiences he has some ideas in mind of how to achieve the porting to ajax in the cleanest manner and leave that input to him.

I have made some screenshots of mock-ups that give an impression where I would like to go next with the GUI for the home page and presentation of search results. I will post these to the community website for people to comment on and send the link to them to this list.

One of the ideas we have in that respect is to have a small map viewer that serves both to set an AoI as well as to create a WMS based map layer combination without immediately switching to the full map view. Only when ready with searching and finding map services, you would open the full map view. This could be based on InterMap (default) or be based on another map client.

OK, hope this is useful,
Ciao,
Jeroen

On Sep 27, 2006, at 5:24 PM, Arnaud Dupuis wrote:

Dear,
We are currently working on a “French” adaptation of GeoNetwork which calls GeoSource. As we want to contribute to the GeoNetwork project, we would like to know what do you plan to do with ajax in the near future of GeoNetwork?

Indeed we want to customize some of our pages with some Ajax functions and it would be preferable that we use your ajax libraries in order to be homogeneous.

*We've noticed that in the 2.1.0 alpha1 version, the "harvesting" module calls ajax libraries (prototype.js, sarissa.js, geonetwork-ajax.js).* *Do you think that these libraries will still be used?* *Do you think that you will adapt existing module(s) of geonetwork with asynchrone requests? If yes, which ones?*

Thanks in advance.

Arnaud DUPUIS
05.34.61.93.39

SILOGIC Société d’ingénierie informatique
6 rue Roger Camboulives
B.P. 1133
31036 TOULOUSE
FRANCE
http://www.silogic.fr

Dear Jeroen,

Thanks for your quick answer. I’ve an onother question about the use of ajax in “harvesting Module”.
It seems that the XSL transformation is done on the client instead of to be on the server. Could you tell me why did you choose this technical way?
Indeed, I would say that this way

  • increases the transfered data from server to client (XML file + XSL file),
  • may cause troubles if the client browser does not implement the “right” xslt processor
  • and finally increases the time of response for the final user.
    What is your point of view?

Thanks.

Arnaud

----- Original Message -----
From: Jeroen Ticheler
To: Arnaud Dupuis
Cc: Geonetwork-devel
Sent: Thursday, September 28, 2006 12:04 AM
Subject: Re: Ajax use in the future Geonetwork

Dear Arnaud,Thanks for the post!

I can give a rough answer, being that we plan to move more services towards AJAX based ones. The libraries used are indeed the ones you pointed at.

The plan is to eventually move all pages to ajax based ones, but help is welcome in that respect. Both Andrea and Stefano have started to port services to use ajax and Andrea has been prototyping portlets over the last days too. I think that based on these experiences he has some ideas in mind of how to achieve the porting to ajax in the cleanest manner and leave that input to him.

I have made some screenshots of mock-ups that give an impression where I would like to go next with the GUI for the home page and presentation of search results. I will post these to the community website for people to comment on and send the link to them to this list.

One of the ideas we have in that respect is to have a small map viewer that serves both to set an AoI as well as to create a WMS based map layer combination without immediately switching to the full map view. Only when ready with searching and finding map services, you would open the full map view. This could be based on InterMap (default) or be based on another map client.

OK, hope this is useful,
Ciao,
Jeroen

On Sep 27, 2006, at 5:24 PM, Arnaud Dupuis wrote:

Dear,
We are currently working on a “French” adaptation of GeoNetwork which calls GeoSource. As we want to contribute to the GeoNetwork project, we would like to know what do you plan to do with ajax in the near future of GeoNetwork?

Indeed we want to customize some of our pages with some Ajax functions and it would be preferable that we use your ajax libraries in order to be homogeneous.

*We've noticed that in the 2.1.0 alpha1 version, the "harvesting" module calls ajax libraries (prototype.js, sarissa.js, geonetwork-ajax.js).* *Do you think that these libraries will still be used?* *Do you think that you will adapt existing module(s) of geonetwork with asynchrone requests? If yes, which ones?*

Thanks in advance.

Arnaud DUPUIS
05.34.61.93.39

SILOGIC Société d’ingénierie informatique
6 rue Roger Camboulives
B.P. 1133
31036 TOULOUSE
FRANCE
http://www.silogic.fr

Hi Arnaud,

the use of Ajax provides a better user experience than a simple web page.
In our case, it has one more advantage because when you connect to servers
with low bandthwidth (like those in South Africa) you don't have to reload the
page. Here are my answers to your questions:

  a.. increases the transfered data from server to client (XML file + XSL file),

False.

The XSL stylesheets are loaded only once for each Ajax interface and they are
usually small. Furthermore, the XML that gets sent over the net is much smaller
compared to the HTML.

  b.. may cause troubles if the client browser does not implement the "right" xslt processor

True.

Now there are only 2 browsers that support XSL: FireFox and Internet Explorer.
In any case we think that FireFox is available to all platforms and has an excellent
implementation of the web standards: for us it is the best choice. So, the 'right'
XSL processor became the firefox's one.

Furthermore, Ajax is becoming a dominant technology and this will motivate
many browser developers to add XSL support to their browsers.

  c.. and finally increases the time of response for the final user.

False.

Consider my scenario for example: the browser and the server are on the same
machine. When you login in geonetwork it takes about 2 secs to authenticate
and redraw the page (and this is the simplest service). The equivalent Ajax
request is served in less than 0.5 secs. If you play with the new harvesting
interface you can see that it works in realtime. Every Ajax request is much faster
than full HTML because the bottleneck here is the network data being transferred
(with Ajax you have less than 1K) and the browser rendering.

Regarding the services that will be moved to Ajax, we will start with administration
of groups, categories and users. Other forms will follow.

Cheers,
Andrea

Dear Jeroen,

Thanks for your quick answer. I've an onother question about the use of ajax in "harvesting Module".
It seems that the XSL transformation is done on the client instead of to be on the server. Could you tell me why did you choose this technical way?
Indeed, I would say that this way
  a.. increases the transfered data from server to client (XML file + XSL file),
  b.. may cause troubles if the client browser does not implement the "right" xslt processor
  c.. and finally increases the time of response for the final user.
What is your point of view?

Thanks.

Arnaud
  ----- Original Message -----
  From: Jeroen Ticheler
  To: Arnaud Dupuis
  Cc: Geonetwork-devel
  Sent: Thursday, September 28, 2006 12:04 AM
  Subject: Re: Ajax use in the future Geonetwork

  Dear Arnaud,
  Thanks for the post!

  I can give a rough answer, being that we plan to move more services towards AJAX based ones. The libraries used are indeed the ones you pointed at.

  The plan is to eventually move all pages to ajax based ones, but help is welcome in that respect. Both Andrea and Stefano have started to port services to use ajax and Andrea has been prototyping portlets over the last days too. I think that based on these experiences he has some ideas in mind of how to achieve the porting to ajax in the cleanest manner and leave that input to him.

  I have made some screenshots of mock-ups that give an impression where I would like to go next with the GUI for the home page and presentation of search results. I will post these to the community website for people to comment on and send the link to them to this list.

  One of the ideas we have in that respect is to have a small map viewer that serves both to set an AoI as well as to create a WMS based map layer combination without immediately switching to the full map view. Only when ready with searching and finding map services, you would open the full map view. This could be based on InterMap (default) or be based on another map client.

  OK, hope this is useful,
  Ciao,
  Jeroen

  On Sep 27, 2006, at 5:24 PM, Arnaud Dupuis wrote:

    Dear,
    We are currently working on a "French" adaptation of GeoNetwork which calls GeoSource. As we want to contribute to the GeoNetwork project, we would like to know what do you plan to do with ajax in the near future of GeoNetwork?

    Indeed we want to customize some of our pages with some Ajax functions and it would be preferable that we use your ajax libraries in order to be homogeneous.

    We've noticed that in the 2.1.0 alpha1 version, the "harvesting" module calls ajax libraries (prototype.js, sarissa.js, geonetwork-ajax.js).
    Do you think that these libraries will still be used?
    Do you think that you will adapt existing module(s) of geonetwork with asynchrone requests? If yes, which ones?

    Thanks in advance.

    Arnaud DUPUIS
    05.34.61.93.39

    SILOGIC Société d'ingénierie informatique
    6 rue Roger Camboulives
    B.P. 1133
    31036 TOULOUSE
    FRANCE
    http://www.silogic.fr

Hi all,
Just to be a bit clearer on this one:

On Sep 28, 2006, at 2:55 PM, Andrea Carboni wrote:

b… may cause troubles if the client browser does not implement the “right” xslt processor

True.

Now there are only 2 browsers that support XSL: FireFox and Internet Explorer.

These are used by 97% of the people we have visiting our FAO GeoNetwork site for instance. The other 3% are using unrecognized browsers, 1.5% Safari and some specific Linux browsers. Not sure all of these remaining 1.5% are incompatible with AJAX. Safari is working on full AJAX support.

In any case we think that FireFox is available to all platforms and has an excellent

implementation of the web standards: for us it is the best choice. So, the ‘right’

XSL processor became the firefox’s one.

Internet Explorer is the other browser that will and should be supported. There are some issues here, but with testing and by using generic libraries like prototype, these issues should be solvable. With the first use of AJAX in the administration section we have not done full IE compatibility, but that has to be done for the full release.

Furthermore, Ajax is becoming a dominant technology and this will motivate

many browser developers to add XSL support to their browsers.

:slight_smile:

Ciao,
Jeroen