Ha! Same here. We tried to be smart about upgradability by making copies of varies files that would be called by cascading changes (e.g. we call main_pugo.xsl instead of main.xsl and main_pugo.xsl calls other *_pugo.xsl versions of the native GN files and therefore we can make one change (call main.xsl instead of main_pugo.xsl) and we would be using native GN again). It still didn't work, of course, because we were still going to have to diff all of the changed files before an update to make sure it can still work.
To be honest, I'm fairly happy with using GN as a back-end only so far. Mostly I'm using it to harvest md written and housed elsewhere (or to do batch ingest), so I actually haven't been spending much time *in* GN, so to speak. Note, though, that we're also not yet consumed with account management, which might provide some challenges to working outside of GN, as well. My *expectation* is that I'll be able to do anything I want with this stack since I can have GN index content in any way I want, then have Solr do whatever I can make it do on that content. This sounds like too much bravado as I write it, so we'll see what I'm saying a year from now, eh?
As for how to modularize GN? I'm not much help here, because the only solution I can realize is what we did -- punt on any native GN interface, put Solr in between that spits out stuff any modern web dev will understand (the ajaxy stuff, json, etc.), and just tell them it's just another web service they're developing against. My GA has never even seen any GN code. An earlier GA got way bogged down in it when we had a crazy side project that embedded WorldWind as the viewer instead of OpenLayers (which had already replaced InterMap. He got it to work -- sort of -- but he hated working with all that GN stuff. So is it rude or defeatist to just say "include an instance of Solr onboard the GN source/download"?
On Oct 21, 2009, at 6:34 AM, <ajs6f@anonymised.com<mailto:ajs6f@anonymised.com>> wrote:
Our experience jibes with what Mr. Hockaday describes and suggests
Our first attempt at a portal was tightly integrated into GN. We
edited the GN XSL, we changed JavaScript libraries, and so on. Then we
realized that as soon as 2.2 was released, we needed to redo an
enormous amount of work. We had no easy way to merge our changes
without finding many errors. That's why we moved to a separated portal
that consumes GN's services. When we move to 2.4, it should be no more
difficult than migrating the material and aiming our portal at the new
instance. We hope. {grin}
"Xforms or something that presents the XML into HTML forms, and
finally separated from, the web interfaces."
This is a particularly attractive idea to me. Our site is
experimenting very seriously with moves toward XForms as our metadata
editing platform. I think it holds enormous promise.
---
A. Soroka
Digital Research and Scholarship R & D
the University of Virginia Library
On Oct 21, 2009, at 3:05 AM, <John.Hockaday@anonymised.com<mailto:John.Hockaday@anonymised.com…70…>> wrote:
Hi Chris,
I have always thought that this is a major flaw of GN development.
I'm sorry to say this but the GN developers are not web interface
designers. They are *very* good at writing web services but there is
a lot to be desired of the GN web interface design. This is why the
GN code should be separated out into different components and not
bundled together. That is:
- web services that allow content to be accesses via JavaScript
separated from,
- JavaScript that communicates back and forth to the web services
using XML, separated from,
- Xforms or something that presents the XML into HTML forms, and
finally separated from, the
- web interfaces.
There should be a basic web interface provided by the GN community
but a web designer has to learn the nitty bitty content of GN to
change this design. Hence, it should be separated from the code so
that:
- I can get graphic or web designers to design the web interface.
They don't need to know the API or JavaScript for GN.
- I then get JavaScript experts to insert the JavaScript into the
resulting web interface to call the GN API for the services that we
want to use.
- I can then allocate java developers to develop GN services that
meet the ISO 19100 and OGC standards and specifications.
This is a very good model to modularise the development of GN
because it allows the people with different skills to develop
interfaces without having to know everything about GN. It is very
hard to get a web interface designer that can program in Java etc.
who also knows about the standards and specifications to work on GN.
In fact, I believe it is impossible to find someone with all these
skills. That is why the code should be separated out into the
different components and not have HTML JavaScript all in an XSL.
I strongly support your thoughts on this matter but unfortunately
you have had to resort to some code outside of GN to get things to
work because the GN architecture has resulted in all the code being
bundled together.
My two cents worth.
John
-----Original Message-----
From: Miller, Christopher C [mailto:ccmiller@anonymised.com]
Sent: Wednesday, 21 October 2009 1:51 PM
To: geonetwork-users Users
Subject: Re: [GeoNetwork-users] Geonetwork with OpenLayer
A., I hope you don't mind I'm putting this back on-list in
case others are interested. I started off wanting to take
GeoNetwork and punch its GUI in the guts a few times, make it
look and operate a lot more swiftly and intuitively (chop the
Intermap head off, replace w/ OpenLayers, allow previewing of
services, make it generally look more modern, etc.) I
actually got pretty far, but didn't like how serpentine the
changes were, how careful we would have to be when updating
GN, and mostly how much we were still boxed in by xsl.
So the much better idea was to point a Solr instance at GN's
own lucene index and flip the switch. It worked! You have to
mess w/ Solr so it knows what to expect in the index, of
course, but for the most part it's that easy. This allowed us
to write a gui from scratch that goes php+ajax+OpenLayers >
JSON > Solr > GN (and json can be swapped out with other solr
output, of course). The best thing for me, as a librarian, is
that I could hire a GA who's just good at web stuff (not
necessarily library stuff or GIS stuff) to implement the
ideas i wanted for the gui, like per-character results (will
hopefully turn into predictive searching), hidden
command-line advanced searches (for advanced users), tabbed
results, tabbed marked records display, live previews of
WMS/WFS records (well, sorta live -- WMS gets run through
tilecache so we can precache or at least keep
already-rendered tiles around), and also the ability to
simultaneously throw the queries to other services (stupidly, r
ight now, to Google or Bing or whatever, but the idea is to
throw searches to more appropriate alternate catalogs based
on the nature of the queries themselves -- much work to do
here, of course).
This is all unfunded work, done essentially in the spare time
I have as a working librarian (the GA is just paid for by my
administration, my decision was to use him for this and do
all the normal GA work myself). It's going slowly for that
and other reasons, but a lot of the functionality is there
(just ugly and unstyled). The ideas was once I can get this
beta tested (and styled) the code will go out to
anybody/everybody (see
https://code.lib.purdue.edu/trac/gis/pugo/wiki). If anybody
really wanted to pitch in now, though, I can anonymize svn
access (anyone? anyone?).
I can say more if you're interested (I mean, I have to write
this stuff up some time anyway, right?). But so far I'm
pleased with the openness of it all and the serious lack of
limits (just time and web dev. talent, of course). It seems
like a great platform for all kinds of nutty librarian ideas,
though, which is great.
Chris
On Oct 20, 2009, at 11:24 AM,
<ajs6f@anonymised.com<mailto:ajs6f@anonymised.com>>
<ajs6f@anonymised.com<mailto:ajs6f@anonymised.com>> wrote:
Care to say any more? I'm intrigued... {grin}
Naturally, we're big fans of Solr here too.
---
A. Soroka
Digital Research and Scholarship R & D
the University of Virginia Library
On Oct 20, 2009, at 2:22 PM, Miller, Christopher C wrote:
Ryan, you can also point an instance of Apache Solr at the Lucene
index GeoNetwork writes, then use the native services offered by
Solr. We're having decent success with this on a project (not so
different from UVa's, it turns out, but not yet in production). We
like Solr quite a lot so far.
Chris
On Oct 20, 2009, at 10:16 AM,
<ajs6f@anonymised.com<mailto:ajs6f@anonymised.com
wrote:
It is accessing the data using the simple GeoNetwork-specific
services
(e.g. 'xml.search'). If you (or anyone) would like to regear it for
CSW (or some other protocol), we heartily encourage that work and are
happy to consult to it. As a reminder, you'll find the code here:
http://github.com/joegilbert/gn-geoportal/
and it is a Ruby/Sinatra project.
---
A. Soroka
Digital Research and Scholarship R & D
the University of Virginia Library
On Oct 20, 2009, at 1:07 PM, Ryan Clark wrote:
Does the portal you've developed consume the CSW service povided by
Geonetwork, or is it accessing the data in a different way?
Thanks,
Ryan
On Friday, October 16, 2009,
<ajs6f@anonymised.com<mailto:ajs6f@anonymised.com
wrote:
It's come to my attention that I sent the wrong URL for an example
instance of our portal in the below-quoted message. (I sent the
development address, which is not publicly accessible.) The correct
URL is:
http://geoportal.scholarslab.org/
---
A. Soroka
Digital Research and Scholarship R & D
the University of Virginia Library
Begin forwarded message:
Here at the University of Virginia, we have devised a Sinatra/
GeoExt/
OpenLayers search-browse-discovery interface to GeoNetwork that
operates by consuming the GeoNetwork services. You can see it in
action at:
http://utm.lib.virginia.edu/
and get the code at:
http://github.com/joegilbert/gn-geoportal/
---
A. Soroka
Digital Research and Scholarship R & D
the University of Virginia Library
--------------------------------------------------------------
----------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart
your
developing skills, take BlackBerry mobile applications to market
and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
GeoNetwork-users mailing list
GeoNetwork-users@lists.sourceforge.net<mailto:GeoNetwork-users
@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-users
GeoNetwork OpenSource is maintained at
http://sourceforge.net/projects/geonetwork
--------------------------------------------------------------
----------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart
your
developing skills, take BlackBerry mobile applications to market and
stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
GeoNetwork-users mailing list
GeoNetwork-users@lists.sourceforge.net<mailto:GeoNetwork-users
@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-users
GeoNetwork OpenSource is maintained at
http://sourceforge.net/projects/geonetwork
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
C.C. Miller
Assistant Professor of Library Science
Geographic Information Systems Specialist
Purdue University Libraries
http://gis.lib.purdue.edu
feed://www.lib.purdue.edu/gis/rss.php
ccmiller@anonymised.com<mailto:ccmiller@anonymised.com>
765.496.9474
IM=ccmiller@anonymised.com<mailto:IM=ccmiller@anonymised.com>
AIM=cecmcgee
Jabber=ccmiller@anonymised.com<mailto:Jabber=ccmiller@anonymised.com>
Twitter=http://twitter.com/pugolian
2215E EAS (CIVL)
Earth & Atmospheric Sciences Library (EAS)
Civil Engineering Building (CIVL)
550 Stadium Mall Drive
West Lafayette, IN 47907-2051
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
--------------------------------------------------------------
----------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart
your
developing skills, take BlackBerry mobile applications to market and
stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
GeoNetwork-users mailing list
GeoNetwork-users@lists.sourceforge.net<mailto:GeoNetwork-users
@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/geonetwork-users
GeoNetwork OpenSource is maintained at
http://sourceforge.net/projects/geonetwork
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
C.C. Miller
Assistant Professor of Library Science
Geographic Information Systems Specialist
Purdue University Libraries
http://gis.lib.purdue.edu
feed://www.lib.purdue.edu/gis/rss.php
ccmiller@anonymised.com<mailto:ccmiller@anonymised.com>
765.496.9474
IM=ccmiller@anonymised.com<mailto:IM=ccmiller@anonymised.com>
AIM=cecmcgee
Jabber=ccmiller@anonymised.com<mailto:Jabber=ccmiller@anonymised.com>
Twitter=http://twitter.com/pugolian
2215E EAS (CIVL)
Earth & Atmospheric Sciences Library (EAS)
Civil Engineering Building (CIVL)
550 Stadium Mall Drive
West Lafayette, IN 47907-2051
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
--------------------------------------------------------------
----------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year.
Jumpstart your
developing skills, take BlackBerry mobile applications to
market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
GeoNetwork-users mailing list
GeoNetwork-users@lists.sourceforge.net<mailto:GeoNetwork-users@anonymised.comforge.net>
https://lists.sourceforge.net/lists/listinfo/geonetwork-users
GeoNetwork OpenSource is maintained at
http://sourceforge.net/projects/geonetwork
------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart
your
developing skills, take BlackBerry mobile applications to market and
stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
GeoNetwork-users mailing list
GeoNetwork-users@lists.sourceforge.net<mailto:GeoNetwork-users@anonymised.comforge.net>
https://lists.sourceforge.net/lists/listinfo/geonetwork-users
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork
------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
GeoNetwork-users mailing list
GeoNetwork-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-users
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
C.C. Miller
Assistant Professor of Library Science
Geographic Information Systems Specialist
Purdue University Libraries
http://gis.lib.purdue.edu
feed://www.lib.purdue.edu/gis/rss.php
ccmiller@anonymised.com<mailto:ccmiller@anonymised.com>
765.496.9474
IM=ccmiller@anonymised.com<mailto:IM=ccmiller@anonymised.com>
AIM=cecmcgee
Jabber=ccmiller@anonymised.com<mailto:Jabber=ccmiller@anonymised.com>
Twitter=http://twitter.com/pugolian
2215E EAS (CIVL)
Earth & Atmospheric Sciences Library (EAS)
Civil Engineering Building (CIVL)
550 Stadium Mall Drive
West Lafayette, IN 47907-2051
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
