Difference between revisions of "19.12.2013 SmartFish - Search/Map JS Integration"
From D4Science Wiki
Yann.laurent (Talk | contribs) |
|||
Line 14: | Line 14: | ||
* Technical discussion items | * Technical discussion items | ||
** ''Web-Services calls'': Massimiliano asked for clarifications how the web-services are called in the portal. Web-services calls are done directly using jQuery Ajax calls (pure Javascript, no PHP) | ** ''Web-Services calls'': Massimiliano asked for clarifications how the web-services are called in the portal. Web-services calls are done directly using jQuery Ajax calls (pure Javascript, no PHP) | ||
− | ** ''Use of PHP'': Yann clarified that the current scope of PHP is only to interface with a simple & small postgres database that provides multilingual capacity & CMS-like content to the Chimaera portal | + | ** ''Use of PHP'': Yann clarified that the current scope of PHP is only to interface with a simple & small postgres database that provides multilingual capacity & CMS-like content to the Chimaera portal - the "back-end" managing web service calls and JSON exploitation are delegated to JS components, independent from the PHP portal. |
** ''Use of jqxWidgets'': the need of making the JS component independent from widget JS libraries (jqxWidgets) was highlighted. This will be part of JS improvements towards having a generic component. | ** ''Use of jqxWidgets'': the need of making the JS component independent from widget JS libraries (jqxWidgets) was highlighted. This will be part of JS improvements towards having a generic component. | ||
** ''VREs needs'': For now there is no need of VRE clearly identified. What has been highlighted with P.Pagano was the possibility to extend the potential use of indexing capacities & web-services with JS components to query these services and provide a user interface. | ** ''VREs needs'': For now there is no need of VRE clearly identified. What has been highlighted with P.Pagano was the possibility to extend the potential use of indexing capacities & web-services with JS components to query these services and provide a user interface. | ||
** ''Portlet integration aspects'': | ** ''Portlet integration aspects'': | ||
*** Massimiliano gave some hints on how the Search/Map JS component will be embedded in the infrastructure | *** Massimiliano gave some hints on how the Search/Map JS component will be embedded in the infrastructure | ||
− | *** | + | *** Creation of portlet that will embed the JS component (a jsp page) and make it usable in the iMarine portal. This portlet will allow test and validation of the component in a different environment than SmartFish to ensure the complete independence from the initial platform. |
* Software policy/quality considerations | * Software policy/quality considerations | ||
− | ** ''Development tools'': Infrastructure development tools should be used ie. SVN gCube repository (yet used), ETICS (for building). | + | ** ''Development tools'': Infrastructure development tools should be used ie. SVN gCube repository (yet used - but JS is included in the SmartFish SVN repository, it has to be made independant), ETICS (for building). |
** ''Releases'' | ** ''Releases'' | ||
*** E.Blondel asked for information on how the JS component should be managed in term software release/artifact (vs. what is currently done with Maven / gCube java components) | *** E.Blondel asked for information on how the JS component should be managed in term software release/artifact (vs. what is currently done with Maven / gCube java components) | ||
Line 29: | Line 29: | ||
*** Release cycles occur more or less on a monthly-basis | *** Release cycles occur more or less on a monthly-basis | ||
** ''Documentation needs'' | ** ''Documentation needs'' | ||
− | *** need of a Developer guide (gCube wiki): technical description of the component | + | *** need of a Developer guide (gCube wiki): technical description of the component - how to embed it in another application |
*** need of a User Guide (gCube wiki): how to exploit the component from a user point of view | *** need of a User Guide (gCube wiki): how to exploit the component from a user point of view | ||
Line 35: | Line 35: | ||
'''''Actions''''' | '''''Actions''''' | ||
− | * next call (Emmanuel & Massimiliano): to be scheduled for early | + | * next call (Emmanuel & Massimiliano): to be scheduled for early January for discussing Search/Map JS integration in a portlet |
* integration requirements yet highlighted: | * integration requirements yet highlighted: | ||
** need of a specific SVN where the JS components source code (both Search & Map) will be hosted | ** need of a specific SVN where the JS components source code (both Search & Map) will be hosted | ||
** need of deploying the test portlet in the [[https://dev.d4science.org/web/guest development portal]] in order to easy develop the generic JS component | ** need of deploying the test portlet in the [[https://dev.d4science.org/web/guest development portal]] in order to easy develop the generic JS component |
Latest revision as of 09:16, 20 December 2013
Skype : 4:30pm - 5:30pm
People
- CNR: Massimiliano Assante
- FAO: Yann Laurent, Emmanuel Blondel
Notes
- Y.Laurent made a quick summary of the Chimaera objectives, as follows:
- develop a very simple portal based on semantic search services, that could be then managed by low IT capacity institutions in the Eastern Africa (e.g. KMFRI in Kenya)
- primary objective was put on offering i) indexing functionalities and ii) search web-services. A second objective, raised with the development the Search/Map JS component is to offer user-friendly tools to call/query the web-services, that could be plugged-in in different contexts, e.g. using different entry points (generic search, selection list or tag cloud search, map selection)
- Technical discussion items
- Web-Services calls: Massimiliano asked for clarifications how the web-services are called in the portal. Web-services calls are done directly using jQuery Ajax calls (pure Javascript, no PHP)
- Use of PHP: Yann clarified that the current scope of PHP is only to interface with a simple & small postgres database that provides multilingual capacity & CMS-like content to the Chimaera portal - the "back-end" managing web service calls and JSON exploitation are delegated to JS components, independent from the PHP portal.
- Use of jqxWidgets: the need of making the JS component independent from widget JS libraries (jqxWidgets) was highlighted. This will be part of JS improvements towards having a generic component.
- VREs needs: For now there is no need of VREVirtual Research Environment. clearly identified. What has been highlighted with P.Pagano was the possibility to extend the potential use of indexing capacities & web-services with JS components to query these services and provide a user interface.
- Portlet integration aspects:
- Massimiliano gave some hints on how the Search/Map JS component will be embedded in the infrastructure
- Creation of portlet that will embed the JS component (a jsp page) and make it usable in the iMarine portal. This portlet will allow test and validation of the component in a different environment than SmartFish to ensure the complete independence from the initial platform.
- Software policy/quality considerations
- Development tools: Infrastructure development tools should be used ie. SVN gCube repository (yet used - but JS is included in the SmartFish SVN repository, it has to be made independant), ETICS (for building).
- Releases
- E.Blondel asked for information on how the JS component should be managed in term software release/artifact (vs. what is currently done with Maven / gCube java components)
- The JS component would be embedded in a Maven artifact (WAR)
- Release cycles occur more or less on a monthly-basis
- Documentation needs
- need of a Developer guide (gCube wiki): technical description of the component - how to embed it in another application
- need of a User Guide (gCube wiki): how to exploit the component from a user point of view
Actions
- next call (Emmanuel & Massimiliano): to be scheduled for early January for discussing Search/Map JS integration in a portlet
- integration requirements yet highlighted:
- need of a specific SVN where the JS components source code (both Search & Map) will be hosted
- need of deploying the test portlet in the [development portal] in order to easy develop the generic JS component