well, it's definately vaporware at his point, but the plans for the next major release of the Repository module will be a dramatic change from it's current design as an extremely configurable 'list' of objects, to a full blown 'application generator'.

You will start by defining your application schema, then define custom forms including list view(s), detail view(s), data entry forms, custom linking of forms based on configurable business rules and hooks for a workflow provider. The cool part will be once you've developed and test your Repository Application, you will have the ability to 'export' your application ( schema, forms, etc ) into a Repository Application Package (single .zip file). There will be an application installer for the module so you can develop a full blown app, then export it to a .zip package file and share or sell it to others.

I expect a beta to be available in the April/May timeframe. So while not a 'true' code-generator, I think the new Repository module will go a long way to allowing people to build real applications using the dnn framework without having to write code. ( fingers crossed )

Brian,

One good thing of DNN is that it's all that you want it to be... if you can't see that, it's better that you buy yourself a framework and integrate it via IFrame (although you will find it a waste of money on the ROI territory).

On the other hand, I agree that DNN is not Large-scale development friendly... it misses allot of things to be that, and belive me (as I've developed really large scale dev. solutions on DNN) I know and see the lacking Core Team focus to the more advanced developers (I hope noone gets me wrong with this one, I am not complaining, merely stating the obvious), but it does give you a great starting point... from which you can grow wings if you like :)

One more thing, my 2 cents on the ExecuteSQL... ExecuteSQL is as rapid as the tools for generation are... if you have to code your statements manually (without a proper Query language, without a proper Domain model, etc...) it's completly the same where you code them.... using ExecuteSQL results just in less maintanence because you don't work with stored procedures (although by some that is questionable as well). -  But what it does is give you a chance to write your own parts that are missing and make it really rapid (combination of tools + code generation).

Yep... Entity Spaces is a nice example of Rapid dev. tool.... I personally prefer a different syntax and approach, but still... it's a nice solution.

Btw... Your Linq support... isn't this only querying objects in memory? Have developed any additional extenstion methods or something like that to bridge the gap between your query language and the Linq one?