Re: User authorization and design of larger web/intranet applications.

[pg]

This actually brings up a very interesting OO design question. For functionality that seems to be common among classes, whether it should be method(s) in the inherit structure, or should be a seperate class on its own.

Obviously the answer is "depend", lots of times "depends" on your perception. Let's look at two particular cases we have here: 1) authorization, and 2) DB connection.

If I design, I will have seperate classes for each of them.

For authorization, if the class should not be accessed, then it should not be "touched" at all. If the authorization functionality is a method of the class itself, obviously the class will be touched in order to to determine whether it should be touched, which is logically a loop hole. So a seperate class should be employed.

For the DB connection, this is a typical good opportunity for class factory. This class factory produces classes that wrap DB connections. For other classes in your application that access the DB , there is no need for them to know the details such as how to get DB connection, or what is the maximum number of connections allowed etc, even not through inheritance. All they care is to ask the class factory for a class that represents DB connection.

[techcode]

For authorization, if the class should not be accessed, then it should not be "touched" at all. If the authorization functionality is a method of the class itself, obviously the class will be touched in order to to determine whether it should be touched, which is logically a loop hole. So a separate class should be employed.

I guess you don't know and haven't used CGI::Application?

Anyway, the way it usually works is that you inherit from CGI::Application, and have methods in it that are runmodes (screens or however you would call it).

With it's plug-in CGI::Application::Dispatch that I'm using whole thing becomes nice M-V-C. Based on the path (such as /index.pl/Module/method - I'm using URL rewriting so it's actually /Module/method.perl) it creates creates the Module (can control it's prefix of name-space such as AppName::Runmodex::Module). And calls method.

Of course there are many things that are done before the method is actually called ... But in the end, one way or the other, that class is initialised ...

For the DB connection, this is a typical good opportunity for class factory. This class factory produces classes that wrap DB connections. For other classes in your application that access the DB , there is no need for them to know the details such as how to get DB connection, or what is the maximum number of connections allowed etc, even not through inheritance. All they care is to ask the class factory for a class that represents DB connection.

I'm using something like that : 491418. Altho I added support for multiple connections (to different DB's) and things like that. So in the end, anywhere in the application I just ask for $self->param('DB') and get DBIx::Handy object. Or I can just make new one (in case I'm in some other module so I wouldn't pass that param around the whole thing).