Greg Brown wrote
The main problem with these two was that they were (are) pretty limited in what you could build - they could only generate basic form/display modules. You could build so much more in Xmod or OWS. They ended up being basically the same thing as the core forms/Lists (UDT) module.
That kinda "hits the nail on the head". Over the years the purpose of any "DNN Builder" was to create the code needed to implement the DotNetNuke DAL. With Linq to SQL (or Linq to Entities) it is hard to justify the time and complexity to implement the DotNetNuke DAL in custom modules.
For example, look at the source code for ADefHelpDesk:
http://adefhelpdesk.codeplex.com/SourceControl/BrowseLatest
There really is not a lot of code. I pounded out the first version in only 4 weekends. If I created it using the DotNetNuke DAL and stored procedures it would have taken months not weeks.
So I hope that DNN Builder programs start to concentrate on allowing developers to use Linq to SQL or Linq to Entities and concentrate on allowing users to design more types of modules.
For example, If I could use a DNN Builder to create a 'Wizard" that gathered information on forms I could design in the builder, that would be very useful. It could then allow me to design the "Admin" page to get the results. For each page I could indicate what roles should see the page.
If I could drop a control on a page and it enabled File Uploads or sent emails. This would provide a reason to exit Visual Studio, open up the DNNBuilder, drag, drop, and click a few options, save and return to Visual Studio.