[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.
--Tony
More information about the geeklog-devel
mailing list