tags:

views:

146

answers:

6

I have a difficulty with a statement on the DotNetNuke pages about the documentation only being available when you pay $2000 or more for a professional or higher license. The forums are flooded with questions, many duplicated, many unanswered, despite the hard work of the DNN community to keep up with demand.

I've tried the books, but they didn't provide the answers I looked for either and while the enthusiasm of the writers is clear, the verbose printing of large boiler plate examples and the lack of information or coverage of newly introduced keywords did not give me the deeper understanding that I longed for as a module developer.

On one hand I'm feeling about DotNetNuke as a great place to be in, but on the other hand, every time I need that one-liner of information on a method, I end up looking for it for ages, and stepping through the code and reverse engineering is then my best friend.

I'm curious, why is a product that's been around for so long, so poorly documented on the count of the API? After all, there's a rather large commercial company behind it and it thrives by the product's expandability. Am I correct in understanding that you only get this documentation if you pay dearly? Or do module development companies have special access?

A: 

I believe they do not publicly document the core code on purpose, because they only want you to work within the constraints of the system they provide for creating modules, as they document in the module creation guide. Thus, they encourage you consider the core code as private. I've seen this with other CMS software in the past.

JasonMichael
The consider classes like `PortalSettings` part of the core, but they are not documented. Of course, the constraints of the framework must be obeyed, good point, but the public methods are there to be used by module developers. How else would you be able to, say, get the current login provider? But the `PortalModuleBase` (used for all modules) is equally badly documented..., heck, I can't even find a documentation of the XML Schema for the `*.dnn` xml files...
Abel
+3  A: 

For the moment, I'll avoid the argumentative tone that is most likely driven towards the writing style of my book and give you a few pointers on this.

  1. API documentation is available, although from a true API perspective the documentation is not 100% yet. The DotNetNuke reference team is working to improve the quality of this documentation, but as you can imagine it is going to take a long time to get something that did not have much, if any, API documentation to be fully documented, but that is the end goal.

  2. The books that are out there right now are some of the best overall documentation on DNN development, BUT they only cover a certain part of the process. For example my book has one of the only items that document the new DNN 5.x manifest format, but since the book has been out for over a year, items have been added to the manifest that are not covered in the book.

  3. DotNetNuke corporation is trying to improve the quality and availability of the documentation out there by creating the new Wiki project and getting the API documentation up to snuff, but it is a step-by-step process.

But to finish this up, let me give you a quick word of advice, there are many of us in the DotNetNuke community that bust our butts to help others get an understanding of DNN and spend all the time that we do here on StackOverflow, DotNetNuke.com, and even our own personal forums. If you take a bit less of an argumentative approach, you might get some better answers, and at minimum you will not run the risk of irritating the people that truly can answer your questions for you.

Mitchel Sellers
Hi @Mitchell: thanks for taking the time to respond. My apologies about the argumentative approach: the site states that if you pay you get full documentation, that's what frustrated. I've left several times several questions (totally neutrally) on the DNN forums and in a few cases I received answers. I usually end up there after all other resources have been exhausted and feel like hitting a white (friendly) wall. I'm glad that work on the API documentation is in process, actually: I highly welcome that! Maybe I can help, I'll have a look.
Abel
A little note on your book, but maybe that discussion is better suited elsewhere. I bought it to help with module development, but unfortunately -- and I'm sorry to say -- it didn't answer the questions I had and the provided examples lack deep coverage. An example on my little grudge with the index: just try to find a manifest keyword, like `supportsPartialRendering`. It's not there. By going through the book page by page I found it. Try *roles*: it doesn't point to the pages on RoleProvider and the latter isn't there either. But in all honesty, your book also saved me on a few occasions ;)
Abel
@Mitchell: I took your note about the tone to heart, guess it was a long day and night getting AJAX to work with a new AJAX lib (didn't work, doesn't work) and revised my question.
Abel
@abel - Trust me I understand! I was the same way 4 or so years ago when I got started with DNN, and there was FAR less documentation then. The Index issue is something that I am very interested on, as I didn't actually create the index, and you are not the first person to complain about it. I also believe that a much "deeper" dive book is needed on DotNetNuke Module Development, but I'm not sure if it will get enough support to move forward.
Mitchel Sellers
@Mitchell: I'll be glad to assist and proofread, but deeper books take a long time to write and mature (see Jon Skeet, how much time his excellent books have taken and still take).
Abel
+1  A: 

While there is a lack of easily obtainable documentation that explains the API in details that may meet your immediate needs and or standards, as Mitchel states DNN has one of the best "communities" of designers and developers that go out of their way to help each other out.

There are many books out there that are authored with the purpose of getting a programmer or IT minded person going with DNN, although they may not give you the detail you are looking for in a particular area I am sure there is not one author that would not do their best to answer a question that was not answered after reading the book if you contacted them . There are numerous blogs and websites that are full of information and forums with people that willingly share their knowledge with those trying to learn. I have gone the root of hiring some of those who have been working with DNN since the beginning on an hourly basis for customized training (as in I ask the questions and they answer them not a classroom with a "predesigned" course). Most of the sites that sell modules also have forums and those developers also will go out of the way to help others learn.

In short time and persistence will pay off as with any other Framework or language. And as Mitchel noted 'You can catch more flies with honey than with vinegar'

By the way was there something in particular you were looking for?

Dan Rowe
@Dan: you raise a good point. Normally I'd be very hesitant in contacting authors or core open source product developers, considering they have better things to do with their time. At the other hand, if I don't ask, they'll never know there's a question. I removed the vinegar, but it isn't honey yet ;)
Abel
http://www.dotnetnuke.com/Community/Blogs/tabid/825/EntryId/2758/Help-How-do-I-do-THIS-in-the-DNN-API-Part-3-of-3.aspx
Dan Rowe
+3  A: 

I am posting a second answer here as with the revised question there is an entirely different way to look at things.

With regards to the DotNetNuke professional edition user manual, I think it is very important that you understand exactly what the manual is. It is NOT a developers guide, or API documentation, it is User Interface documentation. How to add a page, how to add a module to a page, how to install a skin, things of that nature. Yes, that book is a "PE Feature", right wrong or indifferent though, it isn't going to help a developer with the understanding of the DotNetNuke platform.

I think this is an important distinction as really the PE feature set is driven towards business implementations, not necessarily developer implementation. The whole movement to improve developer documentation and developer functionality is being driven by the community and not necessarily the PE customers.

There are other reasons for this as well, PE comes with a few modules that were recently acquired by DotNetNuke corporation, those modules must have documentation as well, which I'm guessing is another part of the UI document that is referenced by your link within the post.

As for the forums, yes, I agree they can be frustrating. It is one of the reasons that the forums on my site (http://www.mitchelsellers.com) are frequented as they get a bit better exposure. Another item that might be great for the community is my recently proposed DotNetNuke StackExchange site. If you haven't done so already, I'd go out and show your support!

Overall though I do feel your pain, I've been an active member in the DotNetNuke community for over 4 years now, and it can be tough at times, but in the end, it always is worth it.

Mitchel Sellers
+1 again, this makes things a bit more understandable and I wasn't aware of the other forums, I'll sure have a look. (I'll switch accepted answers, I believe this one answers my original intend better, even though my original q. was poorly and misleadingly worded).
Abel
+1  A: 

The DotNetNuke user manuals are now available online here. I believe an update for 5.5.0 is coming soon.

As the newest member of the DotNetNuke Corp. development team (about 2 months now), I can assure you that there is no secret API documentation. I have a copy of the same API docs that are on codeplex. It's no surprise that API documentation is limited, the vast majority of DNN was written by volunteer developers who would rather code than write comments, this problem is not rare among open source projects. My only advantage over the rest of the DNN developer community is easy access to some of the long time core team members who know how things are meant to work.

There is a project to extend the API documentation underway, DNN corp is taking part and as always community contribution is highly encouraged. Ernst Peter Tamminga has being blogging about it recently here.

ScottS
+1, this is a good addition to this discussion, and I'm glad to hear that the reference receives more and more attention.
Abel
A: 

When I'm looking for public API calls within DotNetNuke, I use .NET Reflector. If you haven't used it before, I think it might be exactly what you're looking for (or more). It allows you to search for classes, methods, and properties. You can preface the search with DotNetNuke to filter out non-DNN stuff. When you do find something that looks right, it lets you view the exact code. It's free and you never have to worry about it going out of date as you can always reference the latest DNN dll.

EfficionDave
Reflector allows you to reverse engineer a compiled assembly. While it's extremely useful (and the registered version allows you to debug through the decompiled assembly) and while it saved me many hours, even with BCL assemblies, it is no substitute for good documentation.
Abel