[geeklog-devtalk] Re: geeklog-devtalk digest, Vol 1 #330 - 1 msg

[Wim Niemans ri]

Tony,

Having the layout_index fall into the security scheme of GL, one may 
see it hierachical, AND the rights, or OR the rights, even XOR them. 
It's not really important how it's done, as long that it is done in 
an apprehensive way. Anyway, the feature of mapping things to things 
within security and a japanese-like look at it (ie. never go the 
trivial way; try the unexpected and see), opens up a whole new view 
of building a page. What's in the name layout_index...?

Nowadays, GL builds a page from header, right blocks, center part, 
left blocks and footer. This makes necessary that GL builds from the 
*named* things like topics, statis pages, plugin elements etc.
Access to the database follows this method of building.

However, a single access to the layout_index gives the complete page 
content with security properly applicated. In this way everything 
turns into an object. GL just has to render the objects as they are 
found and than determine where they must be fitted: left, right, or  
center. These page-layout attributes could be separate classes, and 
the objects are handed over to these classes.

My dream of the result is a very variable page, completely different 
per topic, event, plugin AND variable per individual user or group.
In this case we don't need to code an access validation in a script. 
No, it's granted by design.

Reading the comments on geeklog.net about items shows me you are on 
your way. Great !!

Cheers,
wim niemans



On 12 Jul 2004 at 12:00, geeklog-devtalk-request at lists.geeklog.net wrote:


> 

> Wim,

> 

> I had suggested a similar associative table earlier but yours is unique 

> in that it includes permissions at the associative level.  That is an 

> interesting addition worth noting, however, is before the block-level 

> security would be applied, the topic level security would come first 

> (i.e. if you don't have access to the topic, you won't have access to 

> any of the blocks).  Anyway, that is an interesting idea worth considering.

> 

> --Tony

> 

> Wim Niemans ri wrote:

> 

> >Hello,

> >

> >To my opinion, to implement a many to many relationship from block to 

> >topic and vs, is to add an extra table to GL. Any other solution will 

> >show only bugs and more bugs. An extra table opens up a nice extra 

> >effect, that the same multiple select, or whatever comes up for the 

> >user interface, can be included on topic level *and* on block level.

> >

> >GLtable 'layout_index'

> >tid, bid, user_rights, group_rights

> >

> >Reflecting more on this feature, more beautyfull options can be 

> >added: add a 'category' and let anything belong to a 'category': 

> >event, plugin, contact, static page, user groups, and on, even 

> >several topics or articles could belong to the same category.

> >Think of colors when referring to categories.

> >Look at the comment engine to see that anything can be linked to 

> >anything.

> >

> >In this way, GL can group the information in articles, events, 

> >plugins in a better and more effecitive way. I like the idea of 

> >having the announcement (calendar) of the first geeklog seminar for 

> >some time *automaticly* displayed within the 'about geeklog' topic.

> >Or find the articles on 'security' under the event 'third network 

> >security congres'. Find also a route drawing block as a left side 

> >block to the calendar (and only there). Not that anybody has to 

> >implement that, but it is possible, and community websites will use 

> >that.

> >

> >Anyway, just dreaming I guess. 

> >

> >Cheers,

> >wim niemans

> >