[geeklog-devel] Blocks in GL2 as Plugin?

Tony Bibbs tony at tonybibbs.com
Thu Dec 16 09:59:25 EST 2004

Blaine Lang wrote:

>I may be out of sync but let me ask these questions:
>Will the core not have a fundamental underlying layout control facility for 
>formatting common site components ?
Yes it will

>Does there not need to be some core component or set of operations that 
>control the site layout?
> - header, footer, blocks which are the basic building blocks of the site.
I think the question is more a logistical one.  Just how atomic do we 
want the kernel to be?  There are two scenarios I seen playing out with 
respect to blocks.  The first is that blocks aren't implemented as 
plugins and all related code exist in files within the kernel.  That's 
essentially no different than 1.3.x today.  The other school of thought 
would be to move it to a plugin and and leave it up to the other plugins 
to mark it as a dependency.

I don't think philosophically I have an opinion.  However, 
architecturally, I think the plugin route makes things harder.  For 
example, take the sample application I wrote.  The abstract class in 
BaseViewFlexy.php exposes the showHeader() and showFooter() methods 
allowing all children to reuse that code.  So if we applied this same 
technique to blocks, there maybe a getBlock() method in this abstract 
class which is a part of the kernel source.  Now assume the block 
features are implemented in a plugin.  Immediately you can't have the 
equivalent of the getBlock() method on the BaseViewFlexy class because 
we can't assume the block plugin is installed.  So in this case any 
plugin wishing to use blocks would probably end up creating their own 
abstract class that extends the BaseViewFlexy class and would add the 
getBlock() method.  Then all their views would use that new class.  
While that is feasible, the problem is that I think you'll have nearly 
every plugin in GL2 wanting to use blocks and so you'll have a copy of 
this sort of new abstact class in each plugin implementation which seems 
like a duplication of code.

So I think I am back with Blaine in that the block code needs to be in 
the kernel.  The beauty of this is plugins still have the option of 
overriding anything in our classes because of the new OO-design so the 
plugins still maintain ultimate control over their use of blocks.

>Are blocks just an item in GL2 or do they need to be identified and stand on 
>their own ?
Uh, how about both.  I'm not sure what you are asking but let me give my 
two cents to see if this answers this question.  I do see a record for 
every block in GL2 in the gl2_item table.  This is because the item 
table includes some already important things a block will want to track 
(ACL's, owner, creation date, etc).    Then you'll have a gl2_block 
table that has all the block specific data.


More information about the geeklog-devel mailing list