Jesse, Thanks for the reply.
> Ultimately, no matter which you choose, you still have a > mapping of 1:1 > between requests and output. Same decisions, pushed around! > Net gain: > Zilch. No doubt about it. A decision is a decision is a decision. Now, why did you write CGI::App to use function ref lookups instead of a big if-then-else tree? I like it because it's simple, elegant, and programmatic, but these may not be the same reasons you chose this particular solution. In any case, I never have liked if-then-else trees from an aesthetic point of view and I have always been partial to table driven FSMs (like CGI::App). In any case it's mostly personal and no more or less right or wrong. As you noted, it's still a decision. However, it is almost certainly more wrong than right to write the same decision tree over and over in each new method to figure out where to go next. This is why a FSM is the best answer for navigational decisions based on history. And this is why I love CGI::App - the most appropriate solution for the problem at hand! > The short version: My recommendation! > > If I understand your situation, you have some run-modes in an > application > which require login, and other run-modes in the same > application which do > not. Now, let's back up a step. The particular login/security example which the rest of this posting addresses belongs to Christopher and not myself, so I'm not going to comment on either his pariticular problem or your solution for the moment. In fact, I would like to avoid all specific examples and details entirely for now and address the general issue first. <climb up on soapbox> CGI code needs to do primarily two things: process data and generate html. I have to process basically the same stuff as everyone else - forms, logins, database queries, etc. and I have to generate the appropriate html in response to user requests just like everyone else. What Christopher and I have both observed is that the processing is not always tightly coupled (on a 1:1 basis) to the html generation. CGI::App has a very simple and elegent view that the indiviual programmer always knows best and should be able to decide exactly which method to run when using whichever parameters the programmer wants to use to make the decisions. With one exection. CGI::App insists that the programmer must always without fail print something every time. It would seem that everyone could gain by decoupling the action (processing) from the output (html). In fact, my programming experience has taught me to always decouple whenever possible to maximize future flexibility and reusability. So here is my $64,000 question. Granted that the original intent was for each run_mode to generate it's own output, when you really think about it, why is this necessary? Note that I'm not trying to eleminate the printing - I just want to use the run_modes to help me do some housecleaning and make some other decisions first. The idea would be to split run() into it's two logical sections as private subs, say action() and output(). This is a little more modular, and then anyone who wanted could override run() to turn the output() call on and off as needed. Let me say one more time that I really love this module and would not have thought to include at least half of the really cool stuff that it supports. So, it's not that I think I know better - I just don't see the downside. What I would really like now is to get at least a little feedback on why this is idea is a bad one before further discussion of alternatives. Christopher and I have already gone over several together with Mark. We readily admit that there is more than one way to skin a cat, but would still like someone to comment on this particular method of skinning. Thanks and look forward to hearing from you, Elizabeth --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
