[geeklog-devel] Plugin layout

[Vincent Furia]

Tony,

The entire point of the "getPage" method in the plugin interface was
so that both procedural and MVCnPHP plugins could operate off the web
tree.  Procedural plugins could generate their web pages from that
function (or functions called from their) and MVCnPHP plugins could
instantiate their controller from that point.

That way everything except Geeklog-2's "index.php" will lie off the
web tree.  Even images and files could be fetched via plugin so that
access to them can be restricted without resorting to obfuscated names
and such (which is bad security anyway, just ask gallery).

-Vinny


On Tue, 21 Dec 2004 17:27:14 -0600, Tony Bibbs <tony at tonybibbs.com> wrote:
> Right now I'm working on the EventManager which has obvious ties to the
> plugins that may be installed.  We need to agree to some sort of
> directory structure for plugins.  Here is what I am proposing:
> 
> For any using MVCnPHP and Propel, here is what I suggest:
> 
> /path/to/Geeklog-2
>     /public_html/
>         /<plugin_name>
>             /commands
>             /sql
>             /system
>                 /Propel
>                     /<propel_package_name>
>                     /NamedQueries.xml
>                     /<propel_package_name>-conf.php
>             /themes
>                 /default
>                 /<themeName>
>             /views
>         /index.php
>         /mvcconfig.php
> 
> You'll notice that looks almost exactly like the Geeklog-2 directory
> structure
> 
> For plugins not using MVCnPHP and Propel:
> /path/to/Geeklog-2
>     /public_html/
>         /<plugin_name>
>             /sql
>             /system
>             /themes
>                 /default
>                 /<themeName>
> 
> Only thing I don't like is I'd prefer a way to move all code outside of
> the web tree.  This would be very easy for MVCnPHP-based applications,
> however, for 1.3.x style plugins, I don't see how this is possible.
> 
> One thing I do know is I want all plugin code in one place.  This makes
> installation and upkeep simpler.  However, it does potentially expose
> code...something I think we can manage effectively since we know about
> it ahead of time.  Anyway, by having it in one place, we could expose
> some "pear install"-like behavior which would definitely have some big
> benefits.
> 
> --Tony
> _______________________________________________
> geeklog-devel mailing list
> geeklog-devel at lists.geeklog.net
> http://lists.geeklog.net/listinfo/geeklog-devel
>