Hi > I think you misunderstand the problem.
Possibly, but actually, it's neither here nor there because I *don't* wish to persuade someone else who is doing a bunch of work that they should do it *my* way! It's just that I am a fan of these kind of frameworks and just want to be sure that everyone tried one and borrowed the best ideas from them in order to build the code in whichever way you wish I still sense from the way you phrased your email here that you might want to have a play around with one or two just for a day or so? I honestly thing you would find it enlightening if you didn't already try one? This doesn't mean that you will use Catalyst for this project, but I would be suprised if you didn't use a couple of it's concepts? (In particular I would highlight the integrated test environment from the ground up to be a really super feature of most of these frameworks!) > It isn't that you can't do stored procedures via most ORM's but rather > that there are no extremely elegant ways to do what we want and still > avoid having to rely on ORMism's for database design. You see this is where I disagree. The "M" part is just that - a model. You are free to implement your load and save code anyway you wish. For example in Rails (just because that's what I am most familiar with) you can ditch the database layer altogether and use Model objects which have no load/save code at all - ie you have to instantiate them yourself and pump data into them yourself. In fact you can use anything you like as a model object it doesn't even have to inherit from any higher level object at all... It's simply a concept in your own head. ....In fact you can even not have an "M" layer at all in Rails and just have a 'VC system... Who cares? Well my point was that whilst there are many good reasons NOT to use Catalyst - I don't think it's a good reason just because you don't get any benefit from a DB to Object layer given to you for free! Basically it's fine to chuck out the whole database layer if you wish and just have completely dumb model objects where you implement your own save/load code I personally think that the model objects should be more modelled on how your View needs to consume data than how the DB stores stuff... Controversial, but I think that one of the key benefits of the model object is in marshalling data between HTML and the code. For example it's quite easy to have a complex form generated from "Invoice has many LineItems" and show this data to the user, accept changes and then programmatically marshal the data back into "Invoice" object + many "LineItem" objects. What you then do with those objects is up to you and it seems quite simple enough to call Invoice.save, which in turn calls a bunch of SP's to make changes to the DB. Honestly don't get hung up on using the DB mapping layers - as you already said they are not going to be a fit for this project - just write your own save/load code. The point is that using your own save/load code need NOT be a reason to chuck out an MVC framework (assuming you like the framework and it offers some other useful benefits, etc) > JMHO, of course, but so far everyone on the core team seems to agree. > Yes of course. Please don't see this as me trying to influence anyone to use Catalyst, despite how it obviously comes across! I just think that the ideas are good and are there to be borrowed. Also I don't feel that just because you don't get database mapping functions for free that you should chuck out the whole framework Good luck all 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
