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 ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Ledger-smb-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
