"William McKee" <[EMAIL PROTECTED]> wrote: >On 25 Oct 2002 at 1:25, James G Smith wrote: >> This module can be used for some of the same applications as >> CGI::Application. It can also be used outside the web environment. >> It does not handle sessions and other application-dependent >> data management. > >Hi James, > >I've been following your posts about Gestinanna because I currently use >CGI::Application and really like it. Can you give any reasons why someone >would want to use your module instead? I'm all for having choices but like >to know the rationale behind the different distributions of similar >modules.
No problem. Almost all (just in case there are some that aren't, especially in Acme::) modules on CPAN are there because they solve some problem. Even modules that do essentially the same thing are solving slightly different problems. I think this is the case with CGI::Application and my module. We have essentially the same problem, but slightly different requirements. I'm concerned more with certain security and OO aspects than with initial ease of use. CGI::Application is good at what it does, from what I can tell, but doesn't address those two sufficiently for me to be comfortable using it where I am working. Thus the difference in design. I'm working on an application framework for an account/system administration web interface. I'm having to think reliability and security. At the same time, I'm having to consider ease of use for those developing applications within the framework. I chose to follow the MVC paradigm (discussed some time ago on this list) to accomplish this. The controller is basically a state machine. It looks at what comes in from the client, decides what needs to be done and what view needs to be sent back. Thus StateMachine::Gestinanna. It manages state based on the data from the client (instead of relying on the client to tell it the next state) with minimal requirements for how the application does views or manages persistance (sessions and contexts) and client interaction. I'm also trying to develop a system that allows applications to be distributed on CPAN and installed as any module on CPAN would be installed. Uttu is the basis for that system, but the idea spilled over a little into this module and drove the development of the object-oriented features. I can write an abstract state machine that has holes in it, but has enough there to guide the development of a useful state machine. For example, we have a process for activating an account on one of our systems. It involves providing sufficient information to convince us you are who you are, agreeing to the terms of services, selecting usernames and a password, and confirming that you want what you selected. I would not distribute the finished state machine, but one that described the general flow and provided the edges for terms-of-service->edit and for confirm->done. The others depend on what information is required for a given system. The code would need to also be written that needs to run when the state transitions. An example making fairly good use of inheritance is account creation. If there are several account types that are essentially the same except for some details in types of data required, then a basic state machine can be written that manages the data required for all account types. Then a set of child classes can be developed, one per account type, with the information/code specific to that account type. These can then all be combined in one class using HASA relationships to make one account addition application. Adding an account type is then trivial. Hopefully that helps a little. I probably should polish it up some, expand on a few things, and submit it as an article somewhere :/ -- James Smith <[EMAIL PROTECTED]>, 979-862-3725 Texas A&M CIS Operating Systems Group, Unix
