Re: Blocks Everywere, Navbar control

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
leingang-c2Vpf+SSmYbWs/[email protected]



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