Re: Blocks Everywere, Navbar control

On Thu, Oct 02, 2003 at 01:31:51PM -0400, Matthew Leingang wrote:
> 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? :-)
> 

Yeah, we've got a view of the projects now - but Yazoo Brewing is right down the
hall. :)   http://www.yazoobrew.com

> 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)
> 

That has worked well for some of the stuff in the -dev code.

> >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.
> 

Right.  That's why I kept it in the config file.

> 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.
> 

Looks nice.

> 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.
> 

Thanks.  Some web hosts still probably don't have uploads enabled. 

> 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.  
>

Let's expand on this sometime.  The permissions now can do the second
story example for sure, and I think the first one too ( maybe with a
little coaxing.)

> That's what I'm thinking about.  What do you all think?
> 

good stuff.

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.

Joe

> Later,
> Matt
> 
> 
> --
> 
> Matthew Leingang
> Harvard University Department of Mathematics
> leingang-c2Vpf+SSmYbWs/[email protected]


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf