[OPEN-ILS-DEV] ***SPAM*** Re: ***SPAM*** Rethinking the Evergreen OPAC client

[Mike Rylander]

On Wed, Nov 4, 2009 at 5:06 PM, steven chan <schan at vcn.bc.ca> wrote:
> On 3-Nov-09, at 3:18 PM, Jason Etheridge wrote:
>
>> Let us know if there are API tweaks or additions that could make things
>> easier. I've
>> always had a wish for multiple OPAC's and staff clients competing and
>> cooperating, using the same API's, but different technology stacks.
>
> Hi Jason. Generally speaking, if the API was more completely documented and
> in more detail, I would guess there would be one less barrier to
> development. I think one of the strengths of the Evergreen system is its
> rich ajax API, but I also thinks it needs a bit of an architectural review.

This architectural redesign has already occurred, but strictly
speaking, what you list below was already addressed by the old Remote
Request API.  More below...

>
> In terms of specific tweaks, I have described them in an internal design
> note of mine, which I copy and paste below. On the input side:
>
> Automatically package input data consisting of multiple values into a list.
> Provide sensible default values for some service calls that offer more
> general services than that needed by the OPAC. Combine the two-phase login
> sequence consisting of ‘auth.authenticate.init’ and
> ‘auth.authenticate.complete’ into one service call ‘auth.session.create’ and
> persist the returned session ID for future use. For services accessing user
> records and circulation transactions, which require the caller to use a
> session ID, automatically provide it if there is an active session. For
> those services requiring a user ID as well, provide it automatically if the
> caller does not specify one. Shorten the service name from, for example,
> service=‘open_ils.search’, method=’open-ils.search.biblio.multiclass.query’
> to ‘search.biblio.multiclass.query’, because the prefix is common and we
> assume a service call will not specify the method of another service.

You should really look into the Dojo modules, mentioned earlier out by
Dan Scott, as these already do all of what you want and much more.
They are also built on top of the much more extensible and performant
(in most cases) HTTP Translator, instead of the original gateway.

These modules use Dojo instead of jQuery, but at this point that's a
done deal for getting code into the main source.  The choice has been
made, and a very large amount of time and code invested.  Dojo has
many more features than jQuery (though the syntax is, or course, not
identical feature-for-feature -- $ is spelled dojo.query in Dojo, for
instance), is faster at a good number of operations (in particular,
with cross-browser DOM manipulation), and has a great deal of
Evergreen code built around it in the newer client-side interfaces.
As for the popularity of Dojo vs jQuery, as a datapoint, IBM is using
(and backing, and contributing to) Dojo for its custom Domino UIs.

>
> On the output side:
>
> If output data is a list of anonymous values, automatically convert it into
> an object. If necessary, recurse into nested lists and return nested data
> objects, ie, do 'field-mapping'. Convert any other output data values into
> sensible data objects.
>

Again, this is already handled by the Evergreen Dojo modules, but also
by the custom code that uses the old-style gateway.

All that said, however, I am very interested to see what you've done.
The OPAC is due for a good refactoring, and all concept-level ideas
and proposals should be considered.

-- 
Mike Rylander
 | VP, Research and Design
 | Equinox Software, Inc. / The Evergreen Experts
 | phone:  1-877-OPEN-ILS (673-6457)
 | email:  miker at esilibrary.com
 | web:  http://www.esilibrary.com