Re: [VuFind-General] prev/next

[Anoop A. <ano...@mn...>]

Well it probably would break RSS feeds for searches too. As for POSTing
 Al Rykhus who works with me and has a lot more experience with Vufind
(and all things library) has actually moved away from POST to GET in our
implementation since POST has search string length limitations so that
would be a problem here also (I think). Al had some thoughts on
implementing this feature but has had other priorities on his plate lately.

We all agree there is no simple solution but if we want this feature we
need to just decide on one method and implement it OR if it's possible
we should extend Vufind to do modules/extensions. Where adding a
prev/next extension would make that feature available whatever method
that particular extension dev decides to use. This would help conserve
software bloat in the core and allow independent users to add on to
Vufind much more easily without forking away on individual installations
as new needs arise.

Cheers

-- 

- - - - - - - - - - - - - - - - - - - - - - - - -

Anoop Atre
IS Developer & Integrator, MnPALS
PH: 507.389.5060
OF: 3022 Memorial Library (Office-ML 3022)
--
"Mit der Dummheit kämpfen Götter selbst vergebens"
 ~ Johann Christoph Friedrich von Schiller


Till Kinstler wrote:
> Andrew Nagy schrieb:
> 
>> The way I envision this happening is by caching the search results and 
>> assigning a record view page the search cache id and referencing the 
>> next and previous IDs.  Difficult to do without making the URLs reallly 
>> ugly .... but maybe something like this:
>>
>> vufind.myuniversity,edu/Search/1/Record/12345/
> 
> But doesn't that break persistent links, bookmarks etc.? Because the URL 
> above is only valid in a specific session or search context (of course 
> that's the context you need for next/prev...). I feel that's no good 
> idea (inter alia because it breaks the concept of "linked data", and 
> because of some less dogmatic reasons (eg. around usability) as well).
> 
> Of course, you need to keep state/context data somewhere to do 
> next/prev. If kept in the user's session data on server side, it breaks 
> tabs/multiple windows...
> If kept in the client, it should be transfered back to the server 
> without breaking the nice stateles/session independent and persistent 
> URLs we currently have. NLA puts the whole search into the next/prev 
> links. I don't like that, because it breaks the concept "one persistent 
> URL for each record".
> 
> Is POSTing the state data a solution? Maybe like this:
> 
> <form method="POST" action="/Record/12344">
> <input type="hidden" name="Search" value="1"/>
> <input type="hidden" name="Record" value="12345"/> <!-- (needed?) -->
> <button type="submit">back</button> <!-- or whatever to submit() the 
> form -->
> </form>
> 
> <form method="POST" action="/Record/12346">
> <input type="hidden" name="Search" value="1"/>
> <input type="hidden" name="Record" value="12345"/>
> <button type="submit">next</button>
> </form>
> 
> But we need to know the IDs of the next and previous record in the 
> result set when generating these forms, then.
> 
> So maybe use a redirection:
> POST session data (or search string, because prev/next depends on 
> search, not on user session) to /Record/12345 that looks up the next (or 
> previous) record (eg. 12346) and redirects to /Record/12346? But then, 
> /Record/12346 doesn't know, which session/search it belongs to, grr. So 
> a redirect plus POST (like Shibboleth uses them)? Ugly...
> 
> No simple solution, I guess...