Am 17.02.2007 um 22:18 schrieb Christian Schaffner: > Hi Max > > On 16.02.2007, at 19:06, Max Horn wrote: > >> Hi Chris, >> >> just wanted to let you know I made some mods: browse.php now has >> working dist/tree queries, and I also changed it to use a table for >> the results (IMO that's more readable than the old list, and should >> be easier to customize with CSS. > > Great! Thanks so much! I went ahead and committed your changes to cvs > (on the branch). (BTW, feel free to commit whenever you want). I > agree that a table makes much more sense. The CSS formatting should > probably have minimum table width in order to reduce the re-rendering > of the table during loading all packages.
Indeed. I was tempted to look into this when I made that change, but I think it's better to wait with this until we have the "backend" done. After that, we need to give the whole user interface a major overhaul anyway, I'd say :-). >> I also fixed package.php. And I think that code there could stand a >> big overhaul. > > Thanks. I also committed these changes. I agree that it could need > updating. I tried to stay as close as possible to the old code at > first, but we could do more changes now that everything is working. Good. And after all, everything is in CVS so nothing is completely lost (err and we are on a branch anyway *g*). > >> In particular, I wonder -- do we really have to accept all these >> params to the page? What are those used for? I.e. is anything ever >> calling the package with an arch or dist set? If so, please tell me >> where we do so. > > Right now, no. Why I had it like this is to have more readable links, > e.g. > > http://www.finkproject.org/pdb/package.php/fink?version=0.26.1-31 > > makes a lot more sense than: > > http://www.finkproject.org/pdb/package.php/fink?pkg_id=9999 > > I like having urls that "mean" something to the end user. That's true, although I wonder what the advantage of that would be? This might encourage users to play with the URL and try inserting versions there manually, but that wouldn't work in general, of course. What other advantage is there to the user being able to "decypher" the URL in this way? > But, as you > said, I am not sure if it is worth it. On the other hand, the queries > into the db don't seem to be that bad as it is right now. Well, they sure are fast enough. However, when using pkg_id, the code would become a lot shorter, and hence easier to maintain (and less likely to contain bugs). BTW, note that with either approach, problems could occur if the user bookmarks one of these URLs, and the pkg later is updated in the PDB. Hence we must catch this case, and handle it appropriately (probably by ignoring the params in this case). > >> If there is no such code, I propose that we remove all existing >> params, and instead add a single new one: pkg_id. The hyperlinks in >> the version table on package.php would then simply encode the >> pkg_id. As a result, the queries could be simplified considerably. >> Doing it this ways just "feels" much more natural to me ... :) > > See comments above. > >> I also added a TODO farther below: I added a $pkg_release which is >> not yet used, but would allow getting rid of several other local >> vars, and at least one auxiliary query (which I also marked with a >> TODO). > > We definitely should do that. These local variables are there for > historical reasons. What you propose is a lot nicer. I implemented and commited this change. Just had another idea: We should consider limiting the number of packages displayed on a page. After all, listing 7000 packages generates a fairly big page, which is slow to load. Instead, how about restricting to 100 pkgs per page or something like that?. Bye, Max ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Fink-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/fink-devel
