Re^5: Review: CGI::Prototype

[hardburn]

Why would mainscreen() change its appearance a lot based on where it was called from?

It may or may not change it's appearance. It may very well change what it does underneath based on where it's called from.

For instance, I often create a set of forms for a user to go through to enter data that eventually ends up in a database. I have a second set that allows them to edit that information later. Really, the second set is exactly the same as the first set, just with the existing data pre-filled into the same forms, and we write our SQL to do UPDATE instead of INSERT.

Since they're really the same thing with minor differences, and taking to heart the idea that copy-and-paste is the lowest form of reuse, we'll want to code things so that the same runmodes and templates can be used again.

Certainly, C::A can do this (I've coded it to do just this many times). But I think a different approach (specifically, using polymorphic objects) could be a lot cleaner.

[Joost]

I'm not sure how much cleaner the code would end up if you used polymorphism. I'm probably sceptic because of some experiences using Java Struts, where we ended up with an enormous class hierarchy trying to get at least *some* code reuse in the different actions (in Struts an Action is an object roughly equivalent to a run_method run_mode in CGI::Application).

It's been noticed before that inheritance is often not the best way to handle code reuse, but Java and Struts don't give you much choice (if you want a reasonably simple API). In any case, spreading your code out over many classes that are all somehow related, even disregarding code reuse issues, makes the code hard to understand and adapt IMHO.

I can see some potential in using Class::Prototyped (and hence, CGI::Prototype) in that regard, but I would have to try it "in the wild" to see if it really holds up.

Right now, I like the fact that you can just group a bunch of related runmodes into one CGI::Application subclass: it makes their relationship explicit and you can make a shared base class to for bigger applications if you need that.

updated: fixed typo

[hardburn]

Polymorphism doesn't strictly mean using inheirtance--just that the objects have the same interface.

I, too, will have to see C::P in the wild before making a firm determination. I am optimistic, as I was thinking along the same lines before I heard of it (though I hadn't thought of marrying it to Class::Prototyped).