Developer Working Group 3: APIs and Plug-in Architecture
Session Leader(s): Chris Barnett, Steve McDonald
Background & Agenda:
Many of us would like to extend Open Geoportal or even use different front-end or back-end technologies. To do this and still share a common code base, we need an architecture that supports plug-ins and has well defined APIs.
Areas for discussion:
1. current ways to extend and customize Open Geoportal
2. Use cases.
3. possibilities for a plug-in architecture; Java and JavaScript
4. a RESTful or REST-like API for the portal (both for use by the client and externally)
5. APIs for OGP code itself. What does a useful API look like?
6. Prioritize.
The goal of the session is to identify ways to make Open Geoportal more flexible and extensible. Where possible, concrete implementation ideas should be specified. Where they cannot be specified, action items will emerge.
Some longer term action items for the DWG are likely to be:
1. Identification/documentation of de facto OGP APIs.
2. Identify where same diverge from best practices or are insufficient.
3. Propose a set of APIs
4. Implement.
5. Repeat for Java, JavaScript, RESTful APIs
The following link is a whiteboard to put any thoughts you have on the topic:
https://docs.google.com/document/d/1u0eL-zaKKVPS5LmUUGvQhT8V_LcBT0Rl9P5SgR3h2Qo/edit?usp=sharing
Session Notes:
Chris: Spring MVC on backend, supports dependency injection, servlets via config file, abstract issues like downlad
JavaScript: more of a problem
in 2.0, backbone, decoupling, some event passing,
data in backbone or this.foo
Mike: OGP is designed for a certain user experience, what would people want to change
Chris: add preview types
Darren: for plugins need to define core
perhaps cart is plug-in
skin as plug-in
Garey: perhaps css plugin
Mike: don’t need cart either
encourage template usage, each one in a separate file
encourage use of require.js: modules wrapped in a define function
Chris: backbone – logic layer with data objects, attributes affected, events fire on event changes and the UI is updated, improves structure of code
Chris: need to identify what is pluggable
Darren: advanced search as plugin
Garey: pop-up info window, selecting correct stylesheet
Darren: redirect to persistent url in another window for info
Chris: consider separation between frontend and backend, potential ogc standard for portals,
Garey: plugin to provide getcapabilities
Garey: security, per layer based on department/group membership
Darren: Stanford uses firewall, uses apache level, all data is restricted
Garey: horde plugin, Apache plugins
Steve: plugin architecture examples? jQuery, Leaflet. no great suggestions.
Chris: how much of this goes into the roadmap
Garey: collection level records
MIke: collection record search could be very different and need a different UI
Darren: just a link to collection information would be useful, Google earth has folders but they don’t work well.
Garey: GeoServer plug of neo4j to deal with relations and nodes to create network data representations of maps
Garey: identify core areas?
Mike: put as much into css as possible
Notes On Plugins From Whiteboard
Client Side:
Cart Actions
Advanced Search
Info Window
Preview
Authentication
Server Side:
Download Method
Modules:
Preview Controls
Skin
Core Code:
Map
List of layers
Mouse over bounding box
Search results
Search box
Preview map
Solr Schema, but it could be abstracted.
Mike: rather than hacking css, use import statement
Garey: results of search only facets and use selects
multiple authentication types supported
Chris: UI is an interface to the index
Location field, a very open field that perhaps need some guidelines
Mike: collection json, define elements of hash
Chris: consider the cart as the first pluggable option, or advanced search
Garey: info window should be easy
Darren: include tooltip for info button behavior
Action Items: