Re: [Phpslash-devel] Blocks Everywere, Navbar control
Brought to you by:
joestewart,
nhruby
From: Mike G. <mi...@op...> - 2003-10-03 17:08:52
|
Hi Matthew, On Fri, 2003-10-03 at 12:48, Matthew Leingang wrote: > On Fri, 2003-10-03 at 10:18, Mike Gifford wrote: > [snip] > > I'm often concerned about system resources & load times.. That first > > page needs to pop up as quickly as it can.. Would be faster if it > > loaded from the file system I think.. But I do like the flexibility of > > having this data just stored in the database too.. > So how do you do both? I was thinking you could use the DB to write an > INI file, and update when you change the DB. That brings up other > issues, of course, like the fact that the INI file must be overwriteable > by the web user. I guess it depends on what stuff you are writing to a cached "INI" and where it is.. We've developed a javascript addon to domMenu which allows us to have dynamic javascript menus.. It's a fun little addon we needed to cache.. I suppose some could hack in & write over it, but it would only affect the navigation for a short period of time as it is written over daily (all user controllable).. There isn't any reason why it couldn't be cached below the root level as well so that an external source wouldn't be able to overwrite it. > > > > Also, I've been toying with the idea of how to best develop a download > > > > module (or do I mean file publication module?). I've got something at > > > > my latest PSL install (sorry for the less-than-creative skin) > > > > http://www.math.harvard.edu/~leingang/math1b/index.php?section_id=18 > > We've developed some upload tool for Back-End. It shouldn't be too hard > > to integrate them back into PSL.. Would be nice to see some of the > > modules we've been developing migrate back into PSL since they are > > developed on a very similar code base. > Cool. I'll take a look at your code. Do you have a CVSweb interface or > do I have to download and "more" it? The latest tarball is here: http://back-end.org/snapshots/ It's all in a sf.net cvs which should be browsable, but I've found it less useful these days (though right now it seems fairly up-to-date): http://cvs.sourceforge.net/viewcvs.py/back-end/back-end0.5.x/class/ BE_Upload.class BE_XUpload.class BE_XUploadDB.class BE_XUploadForm.class Btw, this code was largely hacked together by me, but it's open to enhancements.. so if you've got ideas, feel free to send me the code.. > > > > The block of downloads is generated automatically by scouring a given > > > > directory. Dates and document names are generated automatically (either > > > > by prettying the filename or parsing LaTeX files), and different formats > > > > of the same document are recognized. There's a config file to override > > > > defaults. To add an item, I install the files and edit the config file > > > > if need be. > > > Looks nice. > > We haven't integrated the multi format tool like you did.. That's a > > neat feature. it also isn't something that we really set up as a > > download tool. Would be very useful to be able to assign a section to a > > particular uploaded file so that the files could be grouped together and > > each download logged. > The multi format stuff may not be necessary. I've never tracked but I'm > sure 90% of my downloads are the PDFs. But think about gzipped and > bzipped tarballs; much metadata about one is the same for the other. > RDF + Dublin Core has the vocabulary to say all this. Cool.. > > We set it up so that all files in the updir sub-directory can be deleted > > through the admin interface. They can also be uploaded either through > > scp or through our upload interface. It's nice to have that > > flexibility. > If I upload something with scp I have to make it world-writeable so that > I can delete it from the web, right? How does that work? > [snip] I do think that is correct.. Would be more secure to move it below the root directory for sure. > > > One other thought I've had lately, what kind of interest is there in the > > > option to generate a static site? Write html files to the drive to be > > > published however. > > I'd think that it could be quite useful to be able to export it all as > > an html file. Certainly for archiving purposes it is useful. wget is > > great and all, but would be nice to be able to produce a static version. > Is there a wget one-liner that slurps a PHPSlash site to static html? I > tried it once but got lost. I think these work: wget --convert-links --mirror http://www.slashdot.org wget -r -k -R .pdf -Dslashdot.org http://www.slashdot.org wget -r -l5 -k -Dslashdot.org http://www.slashdot.org > I have archiving needs where the "interactivity" of my course web sites > dies after the semester. So I'd rather just save it all to HTML and I > don't have to worry about supporting the database anymore. So metoo on > this feature. Yup.. > > Could also help to set the home page or even certain articles to be > > static if they get slashdotted. jpcache helps a lot with this, but it > > still causes a lot more load than a good old html file. > Jpcache can cache to html files, right? Does that make it better or > still not as good as you want? It's good for making a snapshot of the html which is generated by your dynamic site. But it grabs all of the dynamic elements just as they were if the site were actually dynamic.. Not sure there are many applications where you would want to isolate the static files you want saved as a .html file and the html you want just cached so that it loads faster... Mike -- Mike Gifford, OpenConcept Consulting Free Software for Social Change -> http://www.openconcept.ca Fair Vote Petition - http://www.fairvotecanada.org/petition.php The master's tools will never dismantle the master's house - A Lorde |