I'd like some suggestions on how we deal with the issue of this: http://aur.archlinux.org/packages.php?do_Details=1&ID=6978&O=0&L=&C=&K=&SB=&SO=&PP=&do_MyPackages=&do_Orphans=&SeB= I've seen suggestions of mod_rewrite but really nothing further, I'll start us off but I really want opinions from at least a few different people. To begin I'm not really thrilled with the idea of mod_rewrite at all and I can't find much of a point to using it, I've been told it will be amazing because then we can have urls like /search/foo/ but so what? People don't search using urls they search with the search form and the fact we can start going /package/1337/ instead of say packages.php?id=1337 is so incredibly minor why should we bother? I propose that at the very least (that is even if we decide to use mod_rewrite for some crazy reason) we change the variable names to something that's actually descriptive and try get rid of as many variables as possible. If you take a look at tardo's repo you can see the details page now only requires the package id variable and nothing else which is a great step in the right direction, we can also get rid of the sorting options in the search form because you can already sort via the links in column names and the variables do_Search is just as pointless as do_Details. With just these changes we get something like O=0&L=&C=&K=&PP=&SeB= which we could probably make even smaller and nicer if we changed variable names to be descriptive. Anyway, most of all I want to hear what other people have to say about this because I think choosing the right names and issues like backwards compatibility are pretty important. -- Callan 'wizzomafizzo' Barrett
First of all look at how many of those variables are empty. Make the code not put empty variables into the URL and make the code that gets the variables deal with unset/empty variables. I was working on this at some point. 1. On the search page you could use a function for processing variables when sorting results in various ways (eg. by name, maintainer, repo, etc) There's a lot of repeated code there... I'm not sure if I committed any change there 2. For details page I was thinking of storing search parameters into a cookie so you could still go back to the search page to resume looking at previous search results. 3. Separate package search code from package details code. (If it hasn't already been done) $do_Details doesn't actually mean anything. I could set do_Details=gramma and it'll still show me the pkg details, the only requirement seems to be that it is set. so make packages.php only show details and get rid of that variable. It won't hurt existing URL links if you get rid of it either. Make another page like search_packages.php for searching packages. You might want to bug people to get those previous patches applied before getting too ahead hehe. Cheers. On Jan 5, 2008 9:05 AM, Callan Barrett <wizzomafizzo@gmail.com> wrote:
On Sat, Jan 05, 2008 at 12:16:33PM -0500, Loui wrote:
I don't think this is possible. The code has nothing to do with what the browser sends to the server. The way it works is that the browser requests the search page from the server. The PHP script does it's thing and outputs the HTML page, which gets downloaded and displayed to the user. The user inputs whatever keywords the user wants and submits. The _browser_ then parses the form and sends the appropriate GET/POST headers (and content). Since some fields are empty (I assume this is why empty variables show up) the browser sends these empty variables in the GET request. The only solution to this that I see is by using JavaScript to dynamically remove any empty fields from the form on an onSubmit event, though I'm not sure that this would actually work.
I'm saying deal with it in the current AUR code. Of course it's possible. There's nothing you can do about outside links other than make sure that the code can deal with that properly. You'd have to do that anyways if you want to omit variables and let them default to something if they're unset. On Jan 5, 2008 1:06 PM, Sebastian Nowicki <xilonmu@gmail.com> wrote:
On 1/5/08, Callan Barrett <wizzomafizzo@gmail.com> wrote:
I recommend something similar to what Loui said. Split packages.php into separate files, such as search.php and details.php. Then the long ugly url goes away in the search result package links (just a ?pkgid=100 or whatever). The search page will still have a marginally ugly url when you click a column to sort, but that can certainly be reduced. As to reasoning behind 'pretty urls', they are generally used for two reasons: 1. Search engine results 2. Human readability Search engines give a higher page rank to urls that are descriptive regarding the page. So /packages/exaile would have a higher rank than /packages.php?pkgname=exaile. They may disregard get args, but I don't know. As for #2, that one is obvious. If someone types a url in by hand, they may have a chance at going right to the page they want. I don't know if we care about #1, and #2 may be a non issue in our case...because people are using the system just fine now.
On Jan 6, 2008 4:24 AM, eliott <eliott@cactuswax.net> wrote:
The only reason the result links are so long is because there is a link on the details page for "going back to search results" which we can probably achieve the same result by getting rid of the link and providing information about the browser's back button. If we do that this problem is solved and ?pkgid=100 is all we need in this case, too (not saying splitting packages.php is a bad idea, just that we don't *need* to do it to achieve this). I think top priority is fixing how much stuff the search form has to submit, it's a pretty big form for what it does and who knows why it still uses the post method. Also I guess making the AUR use mod_rewrite is pretty minimal to do so we could easily do it on top of changing the normal variable names. Loui: Yes, we could use a function to make the urls based on what we actually have but that is sort of minor compared to actually changing the names to something readable, they're not just ugly because they're long they're ugly because they make absolutely no sense. What patches exactly are you referring to? -- Callan 'wizzomafizzo' Barrett
lol... look in my git repo, i've already done all of the above (with the exception of empty vars and seo).
On Jan 6, 2008 11:19 AM, tardo <tardo@nagi-fanboi.net> wrote:
lol... look in my git repo, i've already done all of the above (with the exception of empty vars and seo).
I know, I wrote exactly what you just typed in the original email. -- Callan 'wizzomafizzo' Barrett
participants (5)
-
Callan Barrett
-
eliott
-
Loui
-
Sebastian Nowicki
-
tardo