Language wars...

[Ed W <..hidden..>]

OK, I have inadvertently helped fan the flames of a language war.  My 
apologies

I think to get things back on track that the only people who have a say 
here are those doing the development, so to be fair I think that anyone 
not contributing gobs of code should probably take a backseat now...

If I might add one last comment though.  I would personally love to hear 
that all the key developers took a close look at the new breed of MVC 
type frameworks and nicked some ideas, such as Nitro, Catalyst, Rails 
(and whatever the Python one is called?  Brain gone blank).

I won't mention the one I use because it's not relevant.  However, some 
of the things which I found useful are (and I agree these are not 
features only of the toolkit, but I found it helpful that the toolkit 
made it easier to add these things)

- Test driven development.  Basically you write a bunch of test cases 
and then build the code to implement it.  Great for debugging and 
because the tests remain there forever it's very helpful to avoid 
introducing regressions.  Perl has had this for years, but in *general* 
it's usually only done in a superficial and after the fact kind of way 
(at least that's how *I* use it!  :-)

- MVC decomposition.  Feels funny at first, but a more rigid 
decomposition is very helpful in terms of keeping the architecture 
sane.  In my own mind I break out the model code and the view code and 
everything else gets called "controller".  I guess others would have a 
different way, but whatever you do it's quite helpful I think

- Multiple toolkit options for the view code.  I think Catalyst makes 
this easy as well, but it's very cool that once you have abstracted the 
View code that you can then with a flick of the wrist make the output 
XML, JSON, HTML, PDF or whatever!

- REST.  Once you have broken out the controller code and the view code 
it suddenly becomes reasonably simple to add a REST or SOAP or whatever 
kind of translation layer to the app!  Cool!

- AJAX.  Most toolkits seem to have it.  Don't go nuts though...  Often 
causes as many problems as it solves and stops me using Links as my 
browser...

- Encapsulation of the Model logic.  Whilst I take Joshua's point that 
one size does not fit all with ORM models - the point of the model code 
is really to get all the SQL in one place.  This *doesn't* have to mean 
an ORM to SQL mapper and in fact a decent model could be simply a bunch 
of functions which call a bunch of stored procedures.  I'm not familiar 
with all the toolkits out there, but certainly I don't believe that 
Catalyst even requires that you have an SQL database on the backend of 
the model object...  This encapsulation makes is soooo much easier to 
write new reports and the like though - simply instantiate a model 
object and start plugging away with it until you have all the data that 
you need (although don't disagree with the opinion that most of the 
business logic might want to go in the stored procedure layer either)


I'm only a novice SMB hacker, but actually most of the code looks like 
it could be reasonably easily dragged into an MVC style architecture - 
there is a point where the SQL is created, then a point where a bunch of 
controller logic is done, and then finally the HTML is generated...   

Anyway, please treat these as suggestions only.  I have no right or 
desire to dictate how other people should write their code

Good luck

Ed W