Mark Hedges wrote:
- a lot of times people use references to
other structures when they should subclass... these
references function only to re-map arguments to other
modules, which is ridiculous.
Careful on the should. It can seem extra and possibly confusing but
isn't always. Delegation is a valid pattern that is cleaner than
inheriting at times, particularly when you're mixing in a few different
modules at the same time to do something. If you're merely extending an
existing, then yes, inheritance is good. Multi-directional
multi-inheritance can get really messy... (as I dug myself out of in
development recently myself) if you haven't read, at least scan...
http://www.perldesignpatterns.com/?MixIns
http://www.perldesignpatterns.com/?DelegationConcept
http://www.perldesignpatterns.com/?CompositePattern
And forgive me if I'm too talky on the subject. :)
On Tue, 30 Dec 2008, David Ihnen wrote:
Yes. But timtowdti on how that information is
distributed. In my opinion any *framework* must not
depend on the *application* having established a
persistent backstore of shared session data, so that it
can persist put/posts. You're *significantly*
constraining the parameters of the implementations
utilizing the framework by requiring this, which I
consider to be exactly what frameworks shouldn't do. We
may disagree. :)
Oh no, the framework doesn't depend on using a session at
all. Just this particular auth module depends on plugging
in the session beforehand.
So I have to have a persistant backstoring session in order to use the
auth module?
It requires server storage to know what usernames are
available in this situation *yes*. But that is merely at
authentication time - not during the lifetime of the
session. An auth service is not a session service.
It does not require server session storage inherently to
associate a session cookie with a user - the cookie has
plenty of storage to do that itself.
Hrmm. I'll think about that... maybe the only thing
necessary is that a database handle is available from
Apache2::Controller::DBI::Connector.
I'd think 'implementation subclass must implement a method that returns
validity of username' would be more flexible and concise. You could use
apache environment variables and other request state information to pass
extra data to that function based on what <file> or <location> or
<directory> its in, as a forinstance.
That way you wouldn't attempt to corral the user into using a particular
method of acquiring user data. I mean, think of the directive
proliferation that impends from trying to configure all the DBI stuff.
Sure, perhaps your connector subclass defines the connection string and
all that hooey (hopefully THAT stuff isn't in the directive
proliferation...) - but how do you query in this database once you have
the connection? Do you define table, column, where conditions, joins?
An arbitrary SQL string (language in language, ack!) What if I did
things way differently... and had an external service providing the data
that doesn't even require a query, as such, but of course I could layer
through DBI if I wanted/had to (SELECT openid_identifier FROM USERS
WHERE username = ? translating into a json-rpc call to my user store
service {id:1, method:'get_users', parameters:[?]) that really does do
the same job as a query, conceptually, but does not utilize the
assumption that we have a database backed store available at all?
Example code could show how a dbi connection could be used and
concisely, but is that part of the requirements of utilizing the framework?
David
