SitePoint Sponsor

User Tag List

Results 1 to 6 of 6
  1. #1
    SitePoint Zealot
    Join Date
    Jul 2005
    Posts
    124
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Hrm, would this be a job for the flash?

    #rubyonrails is pretty much worthless, so I figured I would ask here. In short, the question is how would you paginate search results? Pagination nor searching is the problem, there is a catch: There are roughly 30 parameters. I'm basically rewriting a PHP application, it uses a get request and with all of the options selected the URL is damn near 500 characters and it uses cryptic values such as:

    http://www.example.com/index.php?p1=v1&p2=v2&p3=v3

    I would like to be more elegant if possible, so get is a last resort. With the pagination_links helper you can pass the get information from one page to the next, that doesn't seem to be the case with post. Then it hit me, what about using the flash? After all, Agile Web Development with Rails calls it "Communicating between Actions", but I have a feeling that's not what they meant. There are also sessions, but as I understand it the flash stores it's information in sessions, so it could go either way.

    I'm going to attempt to simplify the form a tad, perhaps using get will not be so bad, but how would you go about this? Any opinion on the mentioned methods, any methods that I left out? Thanks for any information, it's appreciated.

  2. #2
    SitePoint Zealot
    Join Date
    Jul 2004
    Location
    Oklahoma
    Posts
    119
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by IAIHMB
    #rubyonrails is pretty much worthless, so I figured I would ask here. In short, the question is how would you paginate search results? Pagination nor searching is the problem, there is a catch: There are roughly 30 parameters. I'm basically rewriting a PHP application, it uses a get request and with all of the options selected the URL is damn near 500 characters and it uses cryptic values such as:

    http://www.example.com/index.php?p1=v1&p2=v2&p3=v3

    I would like to be more elegant if possible, so get is a last resort. With the pagination_links helper you can pass the get information from one page to the next, that doesn't seem to be the case with post. Then it hit me, what about using the flash? After all, Agile Web Development with Rails calls it "Communicating between Actions", but I have a feeling that's not what they meant. There are also sessions, but as I understand it the flash stores it's information in sessions, so it could go either way.
    The flash is really more use as temporary storage for the duration of one request. The way I understand it, you can redirect/render a new action, use the flash, but on the next request it's gone. THat would mean that each action would need to reload the flash with the correct data, pretty much simulationg a session.
    I'm going to attempt to simplify the form a tad, perhaps using get will not be so bad, but how would you go about this? Any opinion on the mentioned methods, any methods that I left out? Thanks for any information, it's appreciated.
    GET has it's advantages. It keeps the browser's back button working for one, and that's a big one in search result usability. It's also long term, much simpler than POST, as it will allow you the option of using links for the next page "button" in the search results, without resorting to an AJAX call to do it. If you look into any search engines out there, they all work on GET because it's "the right thing" to do.
    [start soap box]
    Technically any form that you send to the application, that only fetches data, and makes NO changes, should be GET. POST is designed only for sending requests that may modify data on the server, and are thus "unsafe" to repeat. This is why the browser prompts you constatly when you go back to a posted page.

    [/end soap box]

  3. #3
    SitePoint Zealot
    Join Date
    Jul 2005
    Posts
    124
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Thanks for the response, I think I was a bit out there at the time. If you're not aware of it, flash data can be retained with keep, but I agree with you on the whole HTTP bit. Don't some browsers choke on really long URLs, or was it just domain names?

  4. #4
    SitePoint Zealot
    Join Date
    Jul 2004
    Location
    Oklahoma
    Posts
    119
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by IAIHMB
    Thanks for the response, I think I was a bit out there at the time. If you're not aware of it, flash data can be retained with keep, but I agree with you on the whole HTTP bit. Don't some browsers choke on really long URLs, or was it just domain names?
    Oh it's highly possible some browsers could choke on massive urls, but we're probaby talking unsigned integer length URLs.

  5. #5
    SitePoint Addict
    Join Date
    Mar 2005
    Posts
    251
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    There's two ways around this, as mentioned before you could use the query string to pass parameters, another way I have solved this before, in the interest of keeping cleaner urls is to serialize the parameters and store them in the database. you can then simplify your url to, http://yourapp.com/controller/search/1234 - where 1234 represents a row in the queries table in the db.

    All you have to do is look up the row and unserialize the parameters and use them to search. The upside is that an original query can be passed around and even linked to a user so they could see their recent searches. Obviously there will be a bit of a performance hit and you will need to expire the queries eventually and clean them out of the db - which is a downside if you want the urls to be permanent.

  6. #6
    SitePoint Zealot
    Join Date
    Jul 2005
    Posts
    124
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    That's a good idea, I like it. Thanks!


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •