Re: [Phpslash-devel] Blocks Everywere, Navbar control
Brought to you by:
joestewart,
nhruby
From: Matthew L. <lei...@ma...> - 2003-10-02 17:31:54
|
On Thu, 2003-10-02 at 04:24, Joe Stewart wrote: > On Thu, Oct 02, 2003 at 11:17:04AM -0400, Mike Gifford wrote: > > Hello psl folks, > > > > I'm writing mostly to find out when the new block feature that you've > > been working on is likely to get released. I'm not sure when the next > > release is planned, but am planning to put out a new release of Back-End > > CMS very soon. > > > > Glad to see Back-End development proceeding. I've been busy moving our > office. So hopefully will get cranked back up soon. Giving up your view of the parthenon? :-) I need to get playing with the development code because I have ideas and I might as well put them in the new stuff. [snip] > > I also wanted to know if there was any attempt to extend the ability to > > turn on/off navbar links from the config.ini.php file. I do think it > > would be useful to allow the more detailed control over what appears in > > the navbar than by simply turning on/off a module. Certainly for things > > like the links. > > > > I'd like to see some patches for this, or a web management interface. > > I stalled on it with what seemed to be a limitation of the "ini" array > stuff being limited to one level rather than having nested arrays. I once thought that using dotted keywords in the ini file would work almost as well as a nested array. I still think it does from the installer's standpoint. You could just put something like navbar.items.login.title = "Login" navbar.items.login.link = "login.php" navbar.items.login.perms = "nobody" navbar.items.glossary.title = "Glossary" navbar.items.glossary.link = "glossary.php" navbar.items.glossary.perms = "nobody" navbar.items.admin.title = "Administration" navbar.items.admin.link = "login.php" navbar.items.admin.perms = "user" and then even stuff like navbar.perms.write = "someNewPermissionName" (more on that idea later) >From a programmer's standpoint, I guess it's worse because you have to do strange searches on the keys of $_PSL, but maybe that could be done once and $_PSL sessionized, as we've been threatening. OTOH, a web interface is more like what the rest of psl is about. Probably a lot of the topic bar code could be reused. The one drawback is that generating the navbar that way would add a database call. But perhaps it can be sessionized or cached. 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 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. I want to add the ability to upload stuff and make it available for download through a web interface, but I don't want to lose the plain-old scp uploading that I do now. It seems like it would be good to accept RDF metadata, too, rather than my naive config-file which looks like LDIF. The module should also generate whatever metadata it can on its own, but where does this all get stored? That, and I would like to assign read/overwrite privileges to certain groups...you can see why all I've been doing is thinking about this. Finally, I'm wondering about ways to expand permissions. I guess I've been reading too much about Zope, but it seems like there ought be a way to assign permissions to everything, and permissions not set can be acquired. Like a story can have read permissions set to a certain group, or if it belongs to a section with read permissions set, the story's permission would default to the section's permission. That's what I'm thinking about. What do you all think? Later, Matt -- Matthew Leingang Harvard University Department of Mathematics lei...@ma... |