in reply to Re^3: Review: CGI::Prototype
in thread Review: CGI::Prototype

I don't think this will work very well. Often, mainscreen() itself took input from some other form. Now I'll need to pile on yet more logic inside mainscreen() to know which runmode it's being called by.

Well, it depends on your mainscreen(). My mainscreen() is always the very first page, which by definition doesn't take any input.

In my years of cgiapp development, I actually haven't needed it any other way. That's probably b/c I don't develop the more complex structures, but I've done countless e-commerce and complicated database applications in this "simple" manner.

Now that I think about it, there are a few other options. Remember in each runmode you got access to the $self (cgiapp class), which you can call its get_current_runmode() to see what runmode it's being called by. You also have access to the CGI object within. You can also stuff/access something inside the cgiapp object with its own param() method. Lastly, you can also pass along arguments to the various runmodes.

You have to put that logic somewhere... ;)

Replies are listed 'Best First'.
Re^5: Depends...
by hardburn (Abbot) on Dec 02, 2004 at 16:30 UTC

    You have to put that logic somewhere... ;)

    Yes, and where I don't want it is in an if statement. I'd rather put the logic as a simple method call via polymorphism.

    "There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.

      I'm not sure what to say here... probably nothing. ;) I cannot grasp what you're really talking about and my cynicism meter goes up when people start throwing out large CS words. What's wrong with an if statement?

      Can you elaborate more on what you're trying to do? It sounds like:

      A (mainscreen) -> B (some dynamic data) -> C (data entry) -> B|C

      That right? If so, what does B do differently when it doesn't come from A?

        What's wrong with an if statement?

        The main problem with an if statement versus polymorphism is where the logic resides. The former leaves the logic in the routine with the if, so we have something like this:

        *isa=*UNIVERSAL::isa; sub with_the_if { ... if (isa($foo,'Type1')) { return $foo->method1 } elsif (isa($foo,'Type2')) { return $foo->method2 } else { return $foo->method3 } }

        This is problematic because it makes thing hard to extend later on. The OO way to do it puts the logic on the OUTSIDE of the routine with the if. So now we do:

        sub Type1::generic_method { $_[0]->method1 } sub Type2::generic_method { $_[0]->method2 } sub TypeX::generic_method { $_[0]->method3 } @Type1::ISA=@Type2::ISA=qw(TypeX); sub with_the_if { ... return $foo->generic_method }

        Now code in with_the_if() doesnt have to change when a new type gets added to the framework. It-just-works because whichever type $foo is there will be a generic_method defined that knows what to do. (Or there should be if its work properly). Now to change the behaviour of the system the outside user never has to touch with_the_if(), he just needs to define Type9::generic_method().

        BTW, this isnt meant to add anything to the C::P vs C::A debate, I know neither well enough to say anything, but just an answer to the one question.


        In my case, "mainscreen" would be misnamed. For one of my projects, it went:

        A (mainscreen) -> B (data entry) -> C (dynamic entry in a loop) -> D (preview, with option to go back and edit) -> E (finish, with all data being saved to database)

        I'm not saying that C::A can't do this (far from, for I did indeed write the above in C::A), but that the result isn't very clean.

        What I want is a subroutine call which decides which state the application is in and returns an object. You don't care what the object actually does, but you are guarenteed that it has certain methods. You take that object, call the methods as perscribed in the API, and eventually get back some HTML to display to the user (or maybe the object did that on its own). Meanwhile, the object takes care of parameter checking and saving things to databases and such.

        That's polymorphism. The logic is take care of by having the right objects in the right place, not by conditionals.

        "There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.