[geeklog-devtalk] geeklog-devel digest, Vol 1 #467 - 9 msgs
geeklog-devel-request at lists.geeklog.net
geeklog-devel-request at lists.geeklog.net
Wed Dec 22 00:05:01 EST 2004
Send geeklog-devel mailing list submissions to
geeklog-devel at lists.geeklog.net
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.geeklog.net/listinfo/geeklog-devel
or, via email, send a message with subject or body 'help' to
geeklog-devel-request at lists.geeklog.net
You can reach the person managing the list at
geeklog-devel-admin at lists.geeklog.net
When replying, please edit your Subject line so it is more specific
than "Re: Contents of geeklog-devel digest..."
Today's Topics:
1. Plugin layout (Tony Bibbs)
2. Today's GL2 Accomplishment (Tony Bibbs)
3. Re: Plugin layout (Vincent Furia)
4. Re: GL2, Default Plugin (Vincent Furia)
5. Re: Custom user attributes in GL2 (Vincent Furia)
6. Re: GL2 Login works (Vincent Furia)
7. Re: Plugin layout (Tony Bibbs)
8. Re: Plugin layout (Vincent Furia)
9. Re: GL2, Default Plugin (Tony Bibbs)
--__--__--
Message: 1
Date: Tue, 21 Dec 2004 17:27:14 -0600
From: Tony Bibbs <tony at tonybibbs.com>
To: geeklog-devel at lists.geeklog.net
Subject: [geeklog-devel] Plugin layout
Reply-To: geeklog-devel at lists.geeklog.net
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
--__--__--
Message: 2
Date: Tue, 21 Dec 2004 17:44:56 -0600
From: Tony Bibbs <tony at tonybibbs.com>
To: geeklog-devel at lists.geeklog.net
Subject: [geeklog-devel] Today's GL2 Accomplishment
Reply-To: geeklog-devel at lists.geeklog.net
I've got GL2's Geeklog_EventManager.php fully implemented The only
method I have had time to test so far was registerListener(). The name
of the file will change to ActionManager.php to represent the decision
Vinny and I agreed to on not calling them events (this was mainly for
support questions since plugins will more than likely have the concept
of an event in one of them such as the calendar).
Speaking of testing, I need to spend some time with PHPUnit2 and figure
out how to fit that in. I don't think we need to test everything we
have but covering the most critical code would be nice. And, in my
Eutopia, we'd even do a bit of test-first programming but that would be
biting of too much at this time.
--Tony
--__--__--
Message: 3
Date: Tue, 21 Dec 2004 22:26:57 -0500
From: Vincent Furia <vfuria at gmail.com>
To: geeklog-devel at lists.geeklog.net
Subject: Re: [geeklog-devel] Plugin layout
Reply-To: geeklog-devel at lists.geeklog.net
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
>
--__--__--
Message: 4
Date: Tue, 21 Dec 2004 23:01:16 -0500
From: Vincent Furia <vfuria at gmail.com>
To: geeklog-devel at lists.geeklog.net
Subject: Re: [geeklog-devel] GL2, Default Plugin
Reply-To: geeklog-devel at lists.geeklog.net
Tony,
For a "no plugin" installation I'd suggest that we default to a user
preferences page (if logged in) or else a log in page. Since both
components need to be part of the core, there shouldn't be an issue in
having either one. Clearly we'll need a mechanism so that the default
could be changed (and even the shipped Geeklog-2 could/should have
different defaults set).
-Vinny
On Sun, 19 Dec 2004 22:33:59 -0600, Tony Bibbs <tony at tonybibbs.com> wrote:
> Well, for testing purposes, we should have a kernel default homepage.
> It will allow for a no-plugin installation...which is clearly useless
> but may serve some useful testing or diagnostic services (ala
> phpinfo()). Obviously we'll ship GL2 with the necessary plugins to make
> it feature complete when compared to a stock 1.3.x but, I hope, nothing
> more.
>
> --Tony
>
> Vincent Furia wrote:
>
> >I think clearly we're going to need a "frontpage" plugin. However I
> >don't see any harm in allowing the user (admin) to select what the
> >default plugin is (presumably on most pages this will be the
> >"frontpage" plugin).
> >
> >-Vinny
> >
> >
> >On Sun, 19 Dec 2004 19:39:21 -0600, Tony Bibbs <tony at tonybibbs.com> wrote:
> >
> >
> >>Ok, given that all real work in GL2 will be done by plugins, after a
> >>user logs in where do we send them? Do we simply send them to a plugin
> >>homepage marked as the default?
> >>
> >>--Tony
> >>_______________________________________________
> >>geeklog-devel mailing list
> >>geeklog-devel at lists.geeklog.net
> >>http://lists.geeklog.net/listinfo/geeklog-devel
> >>
> >>
> >>
> >_______________________________________________
> >geeklog-devel mailing list
> >geeklog-devel at lists.geeklog.net
> >http://lists.geeklog.net/listinfo/geeklog-devel
> >
> >
>
> _______________________________________________
> geeklog-devel mailing list
> geeklog-devel at lists.geeklog.net
> http://lists.geeklog.net/listinfo/geeklog-devel
>
--__--__--
Message: 5
Date: Tue, 21 Dec 2004 23:08:00 -0500
From: Vincent Furia <vfuria at gmail.com>
To: geeklog-devel at lists.geeklog.net
Subject: Re: [geeklog-devel] Custom user attributes in GL2
Reply-To: geeklog-devel at lists.geeklog.net
I just wanted to remark somewhere permanent that we need to keep in
mind that a plugin selected for uninstall may be depended upon by
other plugins. Before an uninstall is begun, we need to determine the
reverse dependencies for the plugin (what plugins, if any, rely on the
availability of the plugin to be uninstalled) and deal with those
appropriately.
This also suggests that, like PEAR packages, we allow a plugin to
specify requried dependencies, recommended dependencies, and optional
dependencies.
Geeklog-2 (or whatever we call) should be a dependency of all plugins,
though the version number could vary.
Again, none of these things are issues we'll need to worry about in
the short term, I just want them documented somewhere and right now
this list seems like the best place (especially since I can search it
using Gmail :)
-VInny
On Thu, 16 Dec 2004 01:30:24 -0500, Blaine Lang <geeklog at langfamily.ca> wrote:
> I like the idea of a flexible table driven set of site-defined userprofile
> fields that could be used for registration or for extending the user
> profile.
> This could be a plugin as it could be a plugin today in 1.3.X
>
> I recently developed a formEditor plugin that allows you to create a form
> that has any number of fields from a wide array of field types.
> I used one table to define the fields for all forms where fieldtype is just
> a varchar that is one of the plugin defined types.
> When I display the form, I either use a default layout or a custom template
> if assigned.
>
> We can do the same and it's pretty flexible.
> Fields would need to include:
> - id
> - field_type (varchar 32)
> - field_attributes - if we are using a default layout, you need this
> - field_order
> - label (or linked to language independant feature)
> - required_for_registration
> - is_manditory
>
>
> ----- Original Message -----
> From: "Tony Bibbs" <tony at tonybibbs.com>
> To: <geeklog-devel at lists.geeklog.net>
> Sent: Wednesday, December 15, 2004 5:41 PM
> Subject: Re: [geeklog-devel] Custom user attributes in GL2
>
> Your saying the same thing I am. I was bit confused by Vinny's response
> which sounded a bit like (put everything in there) which I am guessing
> he didn't mean but I wanted to be perfectly clear on. I think your
> table will be more complicated...you'll probably want things like
> min/max values, required indicators, etc. That's in addition to the
> ability to choose from a finite set of values.
>
> The more I think about it, the more I think we might want to delay doing
> anything with customer user attributes until we get to a point where the
> kernel is up and plugins are being written. Thoughts?
>
> --Tony
>
> dwight at trumbower.com wrote:
>
> >Ok, I'm confused. I don't see username and password as custom attributes.
> >
> >Custom attributes are usually used to enhance the base package and allow
> >customers to add a few fields of data to customize a screen. The old days,
> >you just created 5-10 fields, called user1, user2,...user10. So every
> >table had 10 extra fields.
> >
> >The new way puts only the fields you want in a combined table, just like
> >your List Of Values(LOV) table.
> >
> >The hard part is displaying these fields. The easiest way is to have them
> >all grouped together at the end of a screen. Know when people want to move
> >them around in different places, it gets tricky.
> >
> >Also if you need to handle select option fields, radio fields and check
> >box fields there will need some more supporting tables.
> >
> >
> >Dwight
> >
> >
> >
> >
> >
> >>I'm fine with data driving the custom user stuff..l
> >>
> >>I would still say, though, you'd want real columns in the GL2 user table
> >>for thing we know we need (i.e. username, password, etc) for performance
> >>reasons alone, right? Regardless, going this route will make the use of
> >>Propel a little bit messy as the user class generated by propel won't
> >>know anything about the custom attributes in the database.
> >>
> >>Also, for clarity, are you suggesting we do this for all plugin specific
> >>user attributes? I don't think you are and if you are we probably want
> >>to discuss the pros/cons between that and having a plugins specific user
> >>table with a one-to-one relationship with the kernel user table.
> >>
> >>--Tony
> >>
> >>Vincent Furia wrote:
> >>
> >>
> >>
> >>>I'm with Dwight. This way all user data is in one place (and the
> >>>plugins can put user data there as well).
> >>>
> >>>-Vinny
> >>>
> >>>
> >>>On Wed, 15 Dec 2004 16:16:44 -0500 (EST), dwight at trumbower.com
> >>><dwight at trumbower.com> wrote:
> >>>
> >>>
> >>>
> >>>
> >>>>The easiest way I know of, one table.
> >>>>
> >>>>column name - String
> >>>>column type - specifies, long, int, string ect
> >>>>column data - data as a string
> >>>>
> >>>>Might need xref table to show where it is used. At least this is how
> >>>>would
> >>>>start.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>Anybody have any input on how to best address providing the community
> >>>>>with fairly easy way to add custom attributes for users in GL2?
> >>>>>
> >>>>>I don't I have a good idea on how to do this. My hopes are that
> >>>>>plugins
> >>>>>would have their own one-to-one mapping from the core user table to
> >>>>>their own user table with addition information. Assuming that is OK,
> >>>>>how do we handle things the site admin simply wants to add (e.g. msn
> >>>>>id,
> >>>>>pgp key, etc).
> >>>>>
> >>>>>--Tony
> >>>>>_______________________________________________
> >>>>>geeklog-devel mailing list
> >>>>>geeklog-devel at lists.geeklog.net
> >>>>>http://lists.geeklog.net/listinfo/geeklog-devel
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>_______________________________________________
> >>>>geeklog-devel mailing list
> >>>>geeklog-devel at lists.geeklog.net
> >>>>http://lists.geeklog.net/listinfo/geeklog-devel
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>_______________________________________________
> >>>geeklog-devel mailing list
> >>>geeklog-devel at lists.geeklog.net
> >>>http://lists.geeklog.net/listinfo/geeklog-devel
> >>>
> >>>
> >>>
> >>>
> >>_______________________________________________
> >>geeklog-devel mailing list
> >>geeklog-devel at lists.geeklog.net
> >>http://lists.geeklog.net/listinfo/geeklog-devel
> >>
> >>
> >>
> >
> >_______________________________________________
> >geeklog-devel mailing list
> >geeklog-devel at lists.geeklog.net
> >http://lists.geeklog.net/listinfo/geeklog-devel
> >
> >
>
> _______________________________________________
> geeklog-devel mailing list
> geeklog-devel at lists.geeklog.net
> http://lists.geeklog.net/listinfo/geeklog-devel
>
> _______________________________________________
> geeklog-devel mailing list
> geeklog-devel at lists.geeklog.net
> http://lists.geeklog.net/listinfo/geeklog-devel
>
--__--__--
Message: 6
Date: Tue, 21 Dec 2004 23:09:25 -0500
From: Vincent Furia <vfuria at gmail.com>
To: geeklog-devel at lists.geeklog.net
Subject: Re: [geeklog-devel] GL2 Login works
Reply-To: geeklog-devel at lists.geeklog.net
Tony,
Slightly off topic, but do we plan to still use the
PEAR::HTTP_Session2 class(es) for session management?
-Vinny
On Mon, 20 Dec 2004 15:51:21 -0600, Tony Bibbs <tony at tonybibbs.com> wrote:
> Pretty soon here I will be checking in a version of Geeklog 2 which
> successfully authenticates a user. I have taken care to factor the code
> in such a way that the means by which one manages a user account can be
> changed by simply implementing one class and changing a setting in the
> config file.
>
> Being that noone has looked into the code yet (hint, hint) I'll take
> this time to discuss the basic design:
>
> The most basic part of the account management equation is the
> Geeklog_AccountManager (in AccountManager.php). It's job is to read the
> Account Manager it needs to create from a value in the configuration
> file ($glConf['account_manager']), and generate an instance of that
> class which is responsible for doing the work.
>
> All account managers must implement the Geeklog_AccountManagerInterface
> (AccountManagerInterface.php) which provides methods for creating
> accounts, deleting accounts, authenticating users and changing
> passwords. Other method will probably be added to this interface (i.e.
> update account, etc) but I won't bother with them until we establish the
> need.
>
> As such, I have created default AccountManager...named
> Geeklog_DefaultAccountManager in DefaultAccountManager.php (see the
> pattern?).
>
> All this said, one could, for example, create a LDAPAccountManager,
> IMAPAccountManager, etc to have GL2 authenticate to any datastore. I'd
> like to see LDAP and IMAP bundled in with GL2 (any takers?).
>
> So, have a look in CVS and let me know what you do/don't like about what
> I have so far.
>
> --Tony
> _______________________________________________
> geeklog-devel mailing list
> geeklog-devel at lists.geeklog.net
> http://lists.geeklog.net/listinfo/geeklog-devel
>
--__--__--
Message: 7
Date: Tue, 21 Dec 2004 22:55:26 -0600
From: Tony Bibbs <tony at tonybibbs.com>
To: geeklog-devel at lists.geeklog.net
Subject: Re: [geeklog-devel] Plugin layout
Reply-To: geeklog-devel at lists.geeklog.net
Vincent Furia wrote:
>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's fine, the only thing I want to try and honor is URL rewriting.
Thus a URL like:
http://www.example.com/index.php/article/PreSeasonDeer/
Should serve up fine.
The 'getPage' idea is nearly in-line with what I was expecting, I just
didn't see how it would work for procedural plugins.
>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).
>
>
I don't argue this at all, again, it was more an issue of thinking
through the procedural plugins. I'm still fuzzy how this would work for
them, though, I don't doubt it possible. We just have to "make it so".
--Tony
--__--__--
Message: 8
Date: Wed, 22 Dec 2004 00:02:46 -0500
From: Vincent Furia <vfuria at gmail.com>
To: geeklog-devel at lists.geeklog.net
Subject: Re: [geeklog-devel] Plugin layout
Reply-To: geeklog-devel at lists.geeklog.net
Basically I was thinking that only index.php have an "echo" statement.
Everything else should pass around HTML strings. That would allow us
to do cool stuff like apply post-processing filters on all pages (or
just some pages).
URL rewriting should be easy, if we just let the plugins deal with it.
Just so long as the first parameter in a rewritten URL is a plugin
name so that index.php knows what to do. Implementing something more
complex would (obviously) require more effort and complexity.
-Vinny
On Tue, 21 Dec 2004 22:55:26 -0600, Tony Bibbs <tony at tonybibbs.com> wrote:
> Vincent Furia wrote:
>
> >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's fine, the only thing I want to try and honor is URL rewriting.
> Thus a URL like:
>
> http://www.example.com/index.php/article/PreSeasonDeer/
>
> Should serve up fine.
>
> The 'getPage' idea is nearly in-line with what I was expecting, I just
> didn't see how it would work for procedural plugins.
>
> >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).
> >
> >
> I don't argue this at all, again, it was more an issue of thinking
> through the procedural plugins. I'm still fuzzy how this would work for
> them, though, I don't doubt it possible. We just have to "make it so".
>
> --Tony
> _______________________________________________
> geeklog-devel mailing list
> geeklog-devel at lists.geeklog.net
> http://lists.geeklog.net/listinfo/geeklog-devel
>
--__--__--
Message: 9
Date: Tue, 21 Dec 2004 23:03:01 -0600
From: Tony Bibbs <tony at tonybibbs.com>
To: geeklog-devel at lists.geeklog.net
Subject: Re: [geeklog-devel] GL2, Default Plugin
Reply-To: geeklog-devel at lists.geeklog.net
I think no-plugin scenarios will be far and few between. I think if a
user does login during that setup, they are probably an admin. We
should check if they are an admin and, if so, simply give them admin options
Giving non-admins access to just the preferences makes sense.
-Tony
Vincent Furia wrote:
>Tony,
>
>For a "no plugin" installation I'd suggest that we default to a user
>preferences page (if logged in) or else a log in page. Since both
>components need to be part of the core, there shouldn't be an issue in
>having either one. Clearly we'll need a mechanism so that the default
>could be changed (and even the shipped Geeklog-2 could/should have
>different defaults set).
>
>-Vinny
>
>
--__--__--
_______________________________________________
geeklog-devel mailing list
geeklog-devel at lists.geeklog.net
http://lists.geeklog.net/listinfo/geeklog-devel
End of geeklog-devel Digest
More information about the geeklog-devtalk
mailing list