Quantcast

Next record

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Next record

Tim Prettyman
Has anyone devised a way to allow a user to move from record to record in
the full display?

Timothy Prettyman
University of Michigan Library


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Vufind-tech mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/vufind-tech
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Next record

Naomi Dushay
nat'l library of australia did it:

http://catalogue.nla.gov.au

On Oct 29, 2008, at 7:58 AM, Tim Prettyman wrote:

> Has anyone devised a way to allow a user to move from record to  
> record in
> the full display?
>
> Timothy Prettyman
> University of Michigan Library
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's  
> challenge
> Build the coolest Linux based applications with Moblin SDK & win  
> great prizes
> Grand prize is a trip for two to an Open Source event anywhere in  
> the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Vufind-tech mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/vufind-tech

Naomi Dushay
[hidden email]




-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Vufind-tech mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/vufind-tech
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Next record

Mark Triggs-2
I'd hoped nobody would notice :o)  Personally I prefer to open a bunch
of records in tabs, but popular opinion here eventually won out so we
added the next/previous buttons to the record view.

The approach we took was pretty simplistic: we just pass the original
search string, the page of results and the number of the result they
clicked, and just repeat the original search every time they click the
'next' or 'previous' link, jumping them to a particular record in the
result set.  We could have been cleverer and cached a list of docids,
but the naïve implementation was fast enough so we didn't bother.

I'm not really sure it was worth uglifying the pristine record URLs, but
such is life...

Cheers,

Mark



Naomi Dushay <[hidden email]> writes:

> nat'l library of australia did it:
>
> http://catalogue.nla.gov.au
>
> On Oct 29, 2008, at 7:58 AM, Tim Prettyman wrote:
>
>> Has anyone devised a way to allow a user to move from record to
>> record in the full display?

--
Mark Triggs
Systems Administrator
Business Systems Support, The National Library of Australia
<[hidden email]>

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Vufind-tech mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/vufind-tech
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Next record

Andrew Nagy-2
Thanks Mark for jumping in.  I was hoping to devise a similar approach but with out "uglifying" (as you put it :) ) the urls.  I haven't done much work with it, but I think I might be able to use the search history cookie to retrieve the search results and get the next and previous record.  This of course fails when you use tabs and have multiple searches going at once.

Andrew
________________________________________
From: Mark Triggs [[hidden email]]
Sent: Wednesday, October 29, 2008 6:19 PM
To: [hidden email]
Subject: Re: [VuFind-Tech] Next record

I'd hoped nobody would notice :o)  Personally I prefer to open a bunch
of records in tabs, but popular opinion here eventually won out so we
added the next/previous buttons to the record view.

The approach we took was pretty simplistic: we just pass the original
search string, the page of results and the number of the result they
clicked, and just repeat the original search every time they click the
'next' or 'previous' link, jumping them to a particular record in the
result set.  We could have been cleverer and cached a list of docids,
but the naïve implementation was fast enough so we didn't bother.

I'm not really sure it was worth uglifying the pristine record URLs, but
such is life...

Cheers,

Mark



Naomi Dushay <[hidden email]> writes:

> nat'l library of australia did it:
>
> http://catalogue.nla.gov.au
>
> On Oct 29, 2008, at 7:58 AM, Tim Prettyman wrote:
>
>> Has anyone devised a way to allow a user to move from record to
>> record in the full display?

--
Mark Triggs
Systems Administrator
Business Systems Support, The National Library of Australia
<[hidden email]>

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Vufind-tech mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/vufind-tech

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Vufind-tech mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/vufind-tech
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Next record

Tim Prettyman
I've been playing around with this for the last few days.  I'm saving the
list of recordIDs for the current result page in a cookie, and using these
recordIDs to generate nextRec and prevRec links in the record display page.
When you try to go past the first or last record of a set (which doesn't
have a previous or next recordID, respectively, a link is used which
re-executes the search, gets records for the previous (or next) page of
results, gets the id for the last (or first) record in the set, and
redirects to the record page for that id.  So, the search only needs to be
re-executed every 20 records or so.

-Tim

Timothy Prettyman
University of Michigan Library


On 11/4/08 10:32 AM, "Andrew Nagy" <[hidden email]> wrote:

> Thanks Mark for jumping in.  I was hoping to devise a similar approach but
> with out "uglifying" (as you put it :) ) the urls.  I haven't done much work
> with it, but I think I might be able to use the search history cookie to
> retrieve the search results and get the next and previous record.  This of
> course fails when you use tabs and have multiple searches going at once.
>
> Andrew
> ________________________________________
> From: Mark Triggs [[hidden email]]
> Sent: Wednesday, October 29, 2008 6:19 PM
> To: [hidden email]
> Subject: Re: [VuFind-Tech] Next record
>
> I'd hoped nobody would notice :o)  Personally I prefer to open a bunch
> of records in tabs, but popular opinion here eventually won out so we
> added the next/previous buttons to the record view.
>
> The approach we took was pretty simplistic: we just pass the original
> search string, the page of results and the number of the result they
> clicked, and just repeat the original search every time they click the
> 'next' or 'previous' link, jumping them to a particular record in the
> result set.  We could have been cleverer and cached a list of docids,
> but the naïve implementation was fast enough so we didn't bother.
>
> I'm not really sure it was worth uglifying the pristine record URLs, but
> such is life...
>
> Cheers,
>
> Mark
>
>
>
> Naomi Dushay <[hidden email]> writes:
>
>> nat'l library of australia did it:
>>
>> http://catalogue.nla.gov.au
>>
>> On Oct 29, 2008, at 7:58 AM, Tim Prettyman wrote:
>>
>>> Has anyone devised a way to allow a user to move from record to
>>> record in the full display?
>
> --
> Mark Triggs
> Systems Administrator
> Business Systems Support, The National Library of Australia
> <[hidden email]>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Vufind-tech mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/vufind-tech
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Vufind-tech mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/vufind-tech


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Vufind-tech mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/vufind-tech
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Next record

Delis, Christopher
In reply to this post by Andrew Nagy-2
On Tue, Nov 04, 2008 at 10:32:55AM -0500, Andrew Nagy wrote:
> Thanks Mark for jumping in.  I was hoping to devise a similar approach but with out "uglifying" (as you put it :) ) the urls.  I haven't done much work with it, but I think I might be able to use the search history cookie to retrieve the search results and get the next and previous record.  This of course fails when you use tabs and have multiple searches going at once.
>


Since it's an election day (in the U.S.), let me cast my vote :-)

  Q. If "Next Record/Prev Record" functionality is added to VuFind,
  how should we implement it?

     [X] Use an "ugly" URL to preserve state.

     [ ] Use cookies to preserve state (which will break simultaneous
         search per session functionality).

Chris

P.S., An argument could be made that the type of person who uses
Next/Prev buttons wouldn't run simultaneous searches, but I still
stand by my vote.  (Personally, I'm the type who'd launch different
records into their own tabs, but that's me.)



> Andrew
> ________________________________________
> From: Mark Triggs [[hidden email]]
> Sent: Wednesday, October 29, 2008 6:19 PM
> To: [hidden email]
> Subject: Re: [VuFind-Tech] Next record
>
> I'd hoped nobody would notice :o)  Personally I prefer to open a bunch
> of records in tabs, but popular opinion here eventually won out so we
> added the next/previous buttons to the record view.
>
> The approach we took was pretty simplistic: we just pass the original
> search string, the page of results and the number of the result they
> clicked, and just repeat the original search every time they click the
> 'next' or 'previous' link, jumping them to a particular record in the
> result set.  We could have been cleverer and cached a list of docids,
> but the naïve implementation was fast enough so we didn't bother.
>
> I'm not really sure it was worth uglifying the pristine record URLs, but
> such is life...
>
> Cheers,
>
> Mark
>
>
>
> Naomi Dushay <[hidden email]> writes:
>
> > nat'l library of australia did it:
> >
> > http://catalogue.nla.gov.au
> >
> > On Oct 29, 2008, at 7:58 AM, Tim Prettyman wrote:
> >
> >> Has anyone devised a way to allow a user to move from record to
> >> record in the full display?
>
> --
> Mark Triggs
> Systems Administrator
> Business Systems Support, The National Library of Australia
> <[hidden email]>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Vufind-tech mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/vufind-tech
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Vufind-tech mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/vufind-tech

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Vufind-tech mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/vufind-tech
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Next record

Andrew Nagy-4
Hmmm ... Can I abstain?  I don't really like either option at this point.  I want to go with the cookie option - but need to determine a better way of preserving history.

Andrew

On Tue, Nov 4, 2008 at 1:02 PM, Chris Delis <[hidden email]> wrote:
On Tue, Nov 04, 2008 at 10:32:55AM -0500, Andrew Nagy wrote:
> Thanks Mark for jumping in.  I was hoping to devise a similar approach but with out "uglifying" (as you put it :) ) the urls.  I haven't done much work with it, but I think I might be able to use the search history cookie to retrieve the search results and get the next and previous record.  This of course fails when you use tabs and have multiple searches going at once.
>


Since it's an election day (in the U.S.), let me cast my vote :-)

 Q. If "Next Record/Prev Record" functionality is added to VuFind,
 how should we implement it?

    [X] Use an "ugly" URL to preserve state.

    [ ] Use cookies to preserve state (which will break simultaneous
        search per session functionality).

Chris

P.S., An argument could be made that the type of person who uses
Next/Prev buttons wouldn't run simultaneous searches, but I still
stand by my vote.  (Personally, I'm the type who'd launch different
records into their own tabs, but that's me.)



> Andrew
> ________________________________________
> From: Mark Triggs [[hidden email]]
> Sent: Wednesday, October 29, 2008 6:19 PM
> To: [hidden email]
> Subject: Re: [VuFind-Tech] Next record
>
> I'd hoped nobody would notice :o)  Personally I prefer to open a bunch
> of records in tabs, but popular opinion here eventually won out so we
> added the next/previous buttons to the record view.
>
> The approach we took was pretty simplistic: we just pass the original
> search string, the page of results and the number of the result they
> clicked, and just repeat the original search every time they click the
> 'next' or 'previous' link, jumping them to a particular record in the
> result set.  We could have been cleverer and cached a list of docids,
> but the naïve implementation was fast enough so we didn't bother.
>
> I'm not really sure it was worth uglifying the pristine record URLs, but
> such is life...
>
> Cheers,
>
> Mark
>
>
>
> Naomi Dushay <[hidden email]> writes:
>
> > nat'l library of australia did it:
> >
> > http://catalogue.nla.gov.au
> >
> > On Oct 29, 2008, at 7:58 AM, Tim Prettyman wrote:
> >
> >> Has anyone devised a way to allow a user to move from record to
> >> record in the full display?
>
> --
> Mark Triggs
> Systems Administrator
> Business Systems Support, The National Library of Australia
> <[hidden email]>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Vufind-tech mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/vufind-tech
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Vufind-tech mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/vufind-tech

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Vufind-tech mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/vufind-tech


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Vufind-tech mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/vufind-tech
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Next record

Mark Triggs-2
Hi all,

This was pretty much the situation we found ourselves in too.  We had to
implement next/previous links, weren't willing to break tabbed browsing,
and couldn't quite stomach the work required to refactor everything into
a more complex cookie-based approach.

When we thought about extending the cookie-based approach, we decided we
really wanted a data structure that looks like this:

  [ Query1 => [docid1, docid2, ..., docidN],
    Query2 => [docid1, docid2, ..., docidN],
    ...
  ]

Then you immediately hit the problem of what the "QueryN" key actually
is.  Keying it on the original query string doesn't quite work because
the user might get their results, open the first ten pages under new
tabs, and expect next/prev buttons to work.  It seems that the key
really needs to be some combination of the query string, the filters and
the page they were looking at.

The only straightforward way I could see if getting those bits of
information from the record view was to pull them out of the
HTTP_REFERER header.  At this point we decided it was all too much and
just sacrificed our nice URLs :o)

Cheers,

Mark


Andrew Nagy <[hidden email]> writes:

> Hmmm ... Can I abstain?  I don't really like either option at this
> point.  I want to go with the cookie option - but need to determine a
> better way of preserving history.

--
Mark Triggs
Systems Administrator
Business Systems Support, The National Library of Australia
<[hidden email]>

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Vufind-tech mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/vufind-tech
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Next record

Mark Triggs-2
... I should add that I'm not suggesting that VuFind sacrifice *its*
nice URLs.  Maybe the HTTP_REFERER option isn't actually that bad, or
maybe there's some JavaScript magic that could be done instead.  I just
thought I'd share the anguish we went through when making the decision
;o)

Mark


Mark Triggs <[hidden email]> writes:

> The only straightforward way I could see if getting those bits of
> information from the record view was to pull them out of the
> HTTP_REFERER header.  At this point we decided it was all too much and
> just sacrificed our nice URLs :o)

--
Mark Triggs
Systems Administrator
Business Systems Support, The National Library of Australia
<[hidden email]>

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Vufind-tech mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/vufind-tech
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Next record

Delis, Christopher
In reply to this post by Mark Triggs-2

Even if someone does come up with a reliable way to store this
information in a cookie, let's not forget that there is a 4K cookie
limitation.  Currently VuFind uses cookies to save search history,
which uses quite a bit of that precious space as it is.  Sure, you
could probably somehow make efficient use (share data between history
and prev/next info) of this space, but still...  Maybe there's a
reason cookies have this limitation?  ;-) Perhaps that is a hint that
maybe we shouldn't put so much session data into them.  (BTW, One of
the first things I did in customizing my VuFind implementation is to
REMOVE catalog login information, i.e., username and password, from
them!  Not a good place to store such information IMHO! ;-)

Chris




On Wed, Nov 05, 2008 at 07:35:59AM +1100, Mark Triggs wrote:

> Hi all,
>
> This was pretty much the situation we found ourselves in too.  We had to
> implement next/previous links, weren't willing to break tabbed browsing,
> and couldn't quite stomach the work required to refactor everything into
> a more complex cookie-based approach.
>
> When we thought about extending the cookie-based approach, we decided we
> really wanted a data structure that looks like this:
>
>   [ Query1 => [docid1, docid2, ..., docidN],
>     Query2 => [docid1, docid2, ..., docidN],
>     ...
>   ]
>
> Then you immediately hit the problem of what the "QueryN" key actually
> is.  Keying it on the original query string doesn't quite work because
> the user might get their results, open the first ten pages under new
> tabs, and expect next/prev buttons to work.  It seems that the key
> really needs to be some combination of the query string, the filters and
> the page they were looking at.
>
> The only straightforward way I could see if getting those bits of
> information from the record view was to pull them out of the
> HTTP_REFERER header.  At this point we decided it was all too much and
> just sacrificed our nice URLs :o)
>
> Cheers,
>
> Mark
>
>
> Andrew Nagy <[hidden email]> writes:
>
> > Hmmm ... Can I abstain?  I don't really like either option at this
> > point.  I want to go with the cookie option - but need to determine a
> > better way of preserving history.
>
> --
> Mark Triggs
> Systems Administrator
> Business Systems Support, The National Library of Australia
> <[hidden email]>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Vufind-tech mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/vufind-tech

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Vufind-tech mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/vufind-tech
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Next record

Mark Triggs-2
*grins* yep, the 4K limit is a bit of a pain.  Still, we could
automatically span the data structure across multiple cookies if need
be...

(Only joking ;o)


Chris Delis <[hidden email]> writes:

> Even if someone does come up with a reliable way to store this
> information in a cookie, let's not forget that there is a 4K cookie
> limitation.  Currently VuFind uses cookies to save search history,
> which uses quite a bit of that precious space as it is.  Sure, you
> could probably somehow make efficient use (share data between history
> and prev/next info) of this space, but still...  Maybe there's a
> reason cookies have this limitation?  ;-) Perhaps that is a hint that
> maybe we shouldn't put so much session data into them.  (BTW, One of
> the first things I did in customizing my VuFind implementation is to
> REMOVE catalog login information, i.e., username and password, from
> them!  Not a good place to store such information IMHO! ;-)

--
Mark Triggs
Systems Administrator
Business Systems Support, The National Library of Australia
<[hidden email]>

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Vufind-tech mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/vufind-tech
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Next record

wsgrah
Administrator
In reply to this post by Delis, Christopher
sessions++

I think you could easily envision a session var that gets set at the
time of the query that populates the record ids into an array. Pop on a
position iterator in the URL to determine which record to retrieve. If
you open a record in a new tab, it'll have that key in the URL and can
move to the next/prev record. There's very little in cookies (a session
id) and you can probably take an arbitrary length (like 100) to limit id
array to make it less expensive. Plus, you're really only adding in one
more variable to the URL, so it's still relatively neat.

Wayne

Chris Delis wrote:

> Even if someone does come up with a reliable way to store this
> information in a cookie, let's not forget that there is a 4K cookie
> limitation.  Currently VuFind uses cookies to save search history,
> which uses quite a bit of that precious space as it is.  Sure, you
> could probably somehow make efficient use (share data between history
> and prev/next info) of this space, but still...  Maybe there's a
> reason cookies have this limitation?  ;-) Perhaps that is a hint that
> maybe we shouldn't put so much session data into them.  (BTW, One of
> the first things I did in customizing my VuFind implementation is to
> REMOVE catalog login information, i.e., username and password, from
> them!  Not a good place to store such information IMHO! ;-)
>
> Chris
>
>
>
>
> On Wed, Nov 05, 2008 at 07:35:59AM +1100, Mark Triggs wrote:
>  
>> Hi all,
>>
>> This was pretty much the situation we found ourselves in too.  We had to
>> implement next/previous links, weren't willing to break tabbed browsing,
>> and couldn't quite stomach the work required to refactor everything into
>> a more complex cookie-based approach.
>>
>> When we thought about extending the cookie-based approach, we decided we
>> really wanted a data structure that looks like this:
>>
>>   [ Query1 => [docid1, docid2, ..., docidN],
>>     Query2 => [docid1, docid2, ..., docidN],
>>     ...
>>   ]
>>
>> Then you immediately hit the problem of what the "QueryN" key actually
>> is.  Keying it on the original query string doesn't quite work because
>> the user might get their results, open the first ten pages under new
>> tabs, and expect next/prev buttons to work.  It seems that the key
>> really needs to be some combination of the query string, the filters and
>> the page they were looking at.
>>
>> The only straightforward way I could see if getting those bits of
>> information from the record view was to pull them out of the
>> HTTP_REFERER header.  At this point we decided it was all too much and
>> just sacrificed our nice URLs :o)
>>
>> Cheers,
>>
>> Mark
>>
>>
>> Andrew Nagy <[hidden email]> writes:
>>
>>    
>>> Hmmm ... Can I abstain?  I don't really like either option at this
>>> point.  I want to go with the cookie option - but need to determine a
>>> better way of preserving history.
>>>      
>> --
>> Mark Triggs
>> Systems Administrator
>> Business Systems Support, The National Library of Australia
>> <[hidden email]>
>>
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
>> Build the coolest Linux based applications with Moblin SDK & win great prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> _______________________________________________
>> Vufind-tech mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/vufind-tech
>>    
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Vufind-tech mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/vufind-tech
>
>  

--
/**
  * Wayne Graham
  * Earl Gregg Swem Library
  * PO Box 8794
  * Williamsburg, VA 23188
  * 757.221.3112
  * http://swem.wm.edu/blogs/waynegraham/
  * http://www.liquidfoot.com
  */



-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Vufind-tech mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/vufind-tech
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Next record

Andrew Nagy-4
In reply to this post by Delis, Christopher
Yes - this is a bug in JIRA.  if you have a patch that works, would you mind submitting it to the JIRA bug on this?

On Tue, Nov 4, 2008 at 3:51 PM, Chris Delis <[hidden email]> wrote:

Even if someone does come up with a reliable way to store this
information in a cookie, let's not forget that there is a 4K cookie
limitation.  Currently VuFind uses cookies to save search history,
which uses quite a bit of that precious space as it is.  Sure, you
could probably somehow make efficient use (share data between history
and prev/next info) of this space, but still...  Maybe there's a
reason cookies have this limitation?  ;-) Perhaps that is a hint that
maybe we shouldn't put so much session data into them.  (BTW, One of
the first things I did in customizing my VuFind implementation is to
REMOVE catalog login information, i.e., username and password, from
them!  Not a good place to store such information IMHO! ;-)

Chris




On Wed, Nov 05, 2008 at 07:35:59AM +1100, Mark Triggs wrote:
> Hi all,
>
> This was pretty much the situation we found ourselves in too.  We had to
> implement next/previous links, weren't willing to break tabbed browsing,
> and couldn't quite stomach the work required to refactor everything into
> a more complex cookie-based approach.
>
> When we thought about extending the cookie-based approach, we decided we
> really wanted a data structure that looks like this:
>
>   [ Query1 => [docid1, docid2, ..., docidN],
>     Query2 => [docid1, docid2, ..., docidN],
>     ...
>   ]
>
> Then you immediately hit the problem of what the "QueryN" key actually
> is.  Keying it on the original query string doesn't quite work because
> the user might get their results, open the first ten pages under new
> tabs, and expect next/prev buttons to work.  It seems that the key
> really needs to be some combination of the query string, the filters and
> the page they were looking at.
>
> The only straightforward way I could see if getting those bits of
> information from the record view was to pull them out of the
> HTTP_REFERER header.  At this point we decided it was all too much and
> just sacrificed our nice URLs :o)
>
> Cheers,
>
> Mark
>
>
> Andrew Nagy <[hidden email]> writes:
>
> > Hmmm ... Can I abstain?  I don't really like either option at this
> > point.  I want to go with the cookie option - but need to determine a
> > better way of preserving history.
>
> --
> Mark Triggs
> Systems Administrator
> Business Systems Support, The National Library of Australia
> <[hidden email]>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Vufind-tech mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/vufind-tech

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Vufind-tech mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/vufind-tech


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Vufind-tech mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/vufind-tech
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Next record

Andrew Nagy-4
In reply to this post by wsgrah
Too bad Solr doesn't store search id's somehow in the cache.  It would be nice to be able to pull up a search id in solr rather than recreating the search again...

On Tue, Nov 4, 2008 at 5:04 PM, Wayne Graham <[hidden email]> wrote:
sessions++

I think you could easily envision a session var that gets set at the
time of the query that populates the record ids into an array. Pop on a
position iterator in the URL to determine which record to retrieve. If
you open a record in a new tab, it'll have that key in the URL and can
move to the next/prev record. There's very little in cookies (a session
id) and you can probably take an arbitrary length (like 100) to limit id
array to make it less expensive. Plus, you're really only adding in one
more variable to the URL, so it's still relatively neat.

Wayne

Chris Delis wrote:
> Even if someone does come up with a reliable way to store this
> information in a cookie, let's not forget that there is a 4K cookie
> limitation.  Currently VuFind uses cookies to save search history,
> which uses quite a bit of that precious space as it is.  Sure, you
> could probably somehow make efficient use (share data between history
> and prev/next info) of this space, but still...  Maybe there's a
> reason cookies have this limitation?  ;-) Perhaps that is a hint that
> maybe we shouldn't put so much session data into them.  (BTW, One of
> the first things I did in customizing my VuFind implementation is to
> REMOVE catalog login information, i.e., username and password, from
> them!  Not a good place to store such information IMHO! ;-)
>
> Chris
>
>
>
>
> On Wed, Nov 05, 2008 at 07:35:59AM +1100, Mark Triggs wrote:
>
>> Hi all,
>>
>> This was pretty much the situation we found ourselves in too.  We had to
>> implement next/previous links, weren't willing to break tabbed browsing,
>> and couldn't quite stomach the work required to refactor everything into
>> a more complex cookie-based approach.
>>
>> When we thought about extending the cookie-based approach, we decided we
>> really wanted a data structure that looks like this:
>>
>>   [ Query1 => [docid1, docid2, ..., docidN],
>>     Query2 => [docid1, docid2, ..., docidN],
>>     ...
>>   ]
>>
>> Then you immediately hit the problem of what the "QueryN" key actually
>> is.  Keying it on the original query string doesn't quite work because
>> the user might get their results, open the first ten pages under new
>> tabs, and expect next/prev buttons to work.  It seems that the key
>> really needs to be some combination of the query string, the filters and
>> the page they were looking at.
>>
>> The only straightforward way I could see if getting those bits of
>> information from the record view was to pull them out of the
>> HTTP_REFERER header.  At this point we decided it was all too much and
>> just sacrificed our nice URLs :o)
>>
>> Cheers,
>>
>> Mark
>>
>>
>> Andrew Nagy <[hidden email]> writes:
>>
>>
>>> Hmmm ... Can I abstain?  I don't really like either option at this
>>> point.  I want to go with the cookie option - but need to determine a
>>> better way of preserving history.
>>>
>> --
>> Mark Triggs
>> Systems Administrator
>> Business Systems Support, The National Library of Australia
>> <[hidden email]>
>>
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
>> Build the coolest Linux based applications with Moblin SDK & win great prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> _______________________________________________
>> Vufind-tech mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/vufind-tech
>>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Vufind-tech mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/vufind-tech
>
>

--
/**
 * Wayne Graham
 * Earl Gregg Swem Library
 * PO Box 8794
 * Williamsburg, VA 23188
 * 757.221.3112
 * http://swem.wm.edu/blogs/waynegraham/
 * http://www.liquidfoot.com
 */



-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Vufind-tech mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/vufind-tech


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Vufind-tech mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/vufind-tech
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Next record

Delis, Christopher
In reply to this post by Andrew Nagy-4
On Tue, Nov 04, 2008 at 05:19:51PM -0500, Andrew Nagy wrote:
> Yes - this is a bug in JIRA.  if you have a patch that works, would you mind
> submitting it to the JIRA bug on this?


I'm afraid my particular solution went beyond the scope of a patch.
(I added a new session management feature, albeit a simple crude one).
Eventually I will be upgrading to a post-1.0 version of VuFind.  And
in those efforts, I plan on developing a better session management
interface, one that can hopefully fit into the current trunk.

But for the time being, I'd recommend removing the following line from
web/sys/User.php:

                    // Set login cookie for 1 hour
                    $user->password = $password; // Need this for Metalib

I could send a patch, if you'd like :-)

--Chris



>
> On Tue, Nov 4, 2008 at 3:51 PM, Chris Delis <[hidden email]> wrote:
>
> >
> > Even if someone does come up with a reliable way to store this
> > information in a cookie, let's not forget that there is a 4K cookie
> > limitation.  Currently VuFind uses cookies to save search history,
> > which uses quite a bit of that precious space as it is.  Sure, you
> > could probably somehow make efficient use (share data between history
> > and prev/next info) of this space, but still...  Maybe there's a
> > reason cookies have this limitation?  ;-) Perhaps that is a hint that
> > maybe we shouldn't put so much session data into them.  (BTW, One of
> > the first things I did in customizing my VuFind implementation is to
> > REMOVE catalog login information, i.e., username and password, from
> > them!  Not a good place to store such information IMHO! ;-)
> >
> > Chris
> >
> >
> >
> >
> > On Wed, Nov 05, 2008 at 07:35:59AM +1100, Mark Triggs wrote:
> > > Hi all,
> > >
> > > This was pretty much the situation we found ourselves in too.  We had to
> > > implement next/previous links, weren't willing to break tabbed browsing,
> > > and couldn't quite stomach the work required to refactor everything into
> > > a more complex cookie-based approach.
> > >
> > > When we thought about extending the cookie-based approach, we decided we
> > > really wanted a data structure that looks like this:
> > >
> > >   [ Query1 => [docid1, docid2, ..., docidN],
> > >     Query2 => [docid1, docid2, ..., docidN],
> > >     ...
> > >   ]
> > >
> > > Then you immediately hit the problem of what the "QueryN" key actually
> > > is.  Keying it on the original query string doesn't quite work because
> > > the user might get their results, open the first ten pages under new
> > > tabs, and expect next/prev buttons to work.  It seems that the key
> > > really needs to be some combination of the query string, the filters and
> > > the page they were looking at.
> > >
> > > The only straightforward way I could see if getting those bits of
> > > information from the record view was to pull them out of the
> > > HTTP_REFERER header.  At this point we decided it was all too much and
> > > just sacrificed our nice URLs :o)
> > >
> > > Cheers,
> > >
> > > Mark
> > >
> > >
> > > Andrew Nagy <[hidden email]> writes:
> > >
> > > > Hmmm ... Can I abstain?  I don't really like either option at this
> > > > point.  I want to go with the cookie option - but need to determine a
> > > > better way of preserving history.
> > >
> > > --
> > > Mark Triggs
> > > Systems Administrator
> > > Business Systems Support, The National Library of Australia
> > > <[hidden email]>
> > >
> > > -------------------------------------------------------------------------
> > > This SF.Net email is sponsored by the Moblin Your Move Developer's
> > challenge
> > > Build the coolest Linux based applications with Moblin SDK & win great
> > prizes
> > > Grand prize is a trip for two to an Open Source event anywhere in the
> > world
> > > http://moblin-contest.org/redirect.php?banner_id=100&url=/
> > > _______________________________________________
> > > Vufind-tech mailing list
> > > [hidden email]
> > > https://lists.sourceforge.net/lists/listinfo/vufind-tech
> >
> > -------------------------------------------------------------------------
> > This SF.Net email is sponsored by the Moblin Your Move Developer's
> > challenge
> > Build the coolest Linux based applications with Moblin SDK & win great
> > prizes
> > Grand prize is a trip for two to an Open Source event anywhere in the world
> > http://moblin-contest.org/redirect.php?banner_id=100&url=/
> > _______________________________________________
> > Vufind-tech mailing list
> > [hidden email]
> > https://lists.sourceforge.net/lists/listinfo/vufind-tech
> >

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Vufind-tech mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/vufind-tech
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Next record

Ross Singer-2
In reply to this post by wsgrah
On Tue, Nov 4, 2008 at 5:04 PM, Wayne Graham <[hidden email]> wrote:
> sessions++
>

+1 to that.

-Ross.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Vufind-tech mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/vufind-tech
Loading...