MasterViewBase vs. ViewBase vs. SimpleView

I'm finding conflicting documentation and samples and am getting confused.

I have a custom module, and am creating a widget that will show master/detail pages for the content of the module.

If, in Visual Studio, if I add a "Sitefinity Widget with Designer", I end up with a class that inherits from ViewBase

When I look in the SDK and examine the RealEstate sample (whose "MasterListView" is very close to the functionality I require), MasterListView is inheriting from ViewBase, exposing some additional properties which I'm not sure if I need or not (eg "this.EvaluateUrl").

When I look in the online documentation for creating the master list view for the Products module (which also seems very close to what I require) at:

www.sitefinity.com/.../creating-the-master-list-view

you have the class inheriting from "MasterViewBase".

First and most important: as a developer, where am I supposed to find out about the differences between these things? I have to say, I feel like I'm missing some piece of documentation or something. Is there an API map that can be printed out? I now have the API help file, but of course there is basically *no* added commentary to the classes.

Second, what is the difference between these classes? and why are the RealEstate masterpage and the Products masterpage inheriting from different base classes?

Thanks

Jonathan

Second

Is there some reason why you can't use a custom module builder type?  It'd drastically simplify the ENTIRE process.  Like that master\detail widget you want gets generated for you...

My lack of knowledge around Sitefinity will come through here... I've watched *tons* of videos, but I have to say I'm often confused about what the current best practices are, as videos that are only a few months old seem to contradict newer videos...

Anyway, my understanding of the module builder was that it was good for smaller, single-deploy type scenarios, and that it's not portable. In this case, I am creating a module that will have to be transitioned through a dev-test-prod landscape. It also has a taxonomy that is populated from Sharepoint (maybe can still accomplish this with module builder?). It also has intra-module connections (2 modules / content-types that reference one another). It also has email notifications sent out on a schedule.

Maybe I would still develop the core content-type and forms stuff in module builder, and then do the other in custom module? I haven't seen a description of why you would go one way over the other (or at least, in what cases one way is superior to the other).

Thanks a lot for your input

Jonathan

Module builder is FANTASTIC to go from having nothing to a complete working module in < 5 minutes.

The only way I'd do a custom coded one is if I maybe wanted to squeek out a bit more performance like if it was a complex model with millions and millions of records (because it doesn't go through the dynamic type system)....but even then I don't know the metrics on if it's even a measurable number, this is just me guessing.  I've never noticed a performance difference from blogs to any module builder type I've ever made.

Personally I only know the difference from experience....my experience on custom coded is they suck to build from scratch, and are confusing to setup....while my mom can use the module builder and end up with something that seems native to sitefinity.  Since the MB ones can be extended however you want, I see no reason to ever realistically go back.

You can create any db field type you want and create your own javascript selector to populate the data when you edit a MB item. 

Also out of the box in the UI you can have parent->child linked content types (think blog->blog post or list->list item).  Or use Sitefinity Thunder to just auto-generate your content selector field controls in a couple clicks.  So in that case you create a new field on your MB type to store a GUID.  Then you use thunder to essentially say "This guid should be populated by X other module type".  So thunder generates you a complex content selector control, but int he backend all it's going is being a cross-content Guid (or guid[]) selector.

I ramble too much...

I just think the time you've burned trying to do a custom coded version you could be WAY into actually being done an MB one.

**EDIT** Also since its done in the UI and generated automatically it's less likely to break.  Unlike a custom type where they might perhaps change a method or implementation and that hoses your code.

Don't worry about the rambling, this is all *really* good info, and thank you! Since I've got a warm body, several specific questions:

What about portability? If I build up in MB on dev, how do I move it into prod? What about source control / revision control?

In my current custom module, I override the "Install" method in my "ContentModuleBase", and have a method that builds up a custom taxonomy. How would I do this in MB?

Thanks

1) Module builder type is defined in an external .config file in app data with all the other config files....so feel free to check it in our out of tfs at will.  I have NOT tried to copy it up to live to see if changes are applied properly though (just never needed to modify a type yet). 

2) Its a SF custom taxonomy that you're adding taxons to?  Module builder has a classification field type...just select your taxonomy.  Then perhaps in the global.asax sitefinity bootstrapper just run your method. 

Setup a test instance and play with it, trust me you wont go back to hunting through tons of code and documentation :)

Thanks again

1) OK, the more I look, the more I think the "correct" workflow for this will be to build up in dev and document my steps, and then basically redo everything in prod. That doesn't sit quite right with me as a developer; however, I think that it will *still* be much much quicker than the custom module route.

2) alright, I see this in there now. I think maybe I'll still have my custom module, and wire into initialize with my taxonomy creation stuff (one flat, one hierarchical), and any other little bits and pieces. And then simply register my module before building up the custom module. Then my taxonomy will be available. The point being, any Model / content-type stuff will be done via module builder rather than custom module

Like I said...try it...

The time and headaches you'll save will be will worth the price of admission :)

Am doing right now :)