Welcome to the DNN Community Forums, your preferred source of online community support for all things related to DNN.
In order to participate you must be a registered DNNizen

HomeHomeDevelopment and...Development and...Building ExtensionsBuilding ExtensionsModulesModulesReady to quit, Developing "real" things for DNN7seems next to impossibleReady to quit, Developing "real" things for DNN7seems next to impossible
Previous
 
Next
New Post
3/29/2014 2:25 PM
 

I've been asking for debugging information, nothing. Looking for written information (that's accurate), next to nothing. All I can seem to find is hours of videos, and it's not realistic to view hours of videos looking for reference information. I been through them, plus the DNNHero videos, and I've yet to find anything that discusses a module that actually does anything. One table, Two fields, woop-de-do.

At least in the DNN4/5 days there were some books what discussed creating modules that worked, not just the theoretical implementations of possibilities that might work if you hold your mouth just right.

So what I have found is the only thing that actually works in the "DAL for the new century" is simple single table actions with a one column integer key, where the column names all match the object names, and there aren't that many of them. If something doesn't work, there's ZERO information about how to find out what happened. DAL2 is certainly not ready for prime time, and I guess the only way to get a real module working is going back to DAL where things have some stability.

After days of working on an exact replica of the time module created from the Cristoc template I'm pretty much at square zero. I find out after DAYS of tracing that the DNN Petapoco layer will simply log something to the event log and not error, and what's logged pretty much tells you nothing. Don't do follow all the undocumented parameters perfectly, no SQL, no error, no nothing. The only way to debug anything in DAL2 is to load the entire DNN source and use that with SQL Profiler, and then pray. Either debug the entire core yourself or throw in the towel. What progress.

To be frank, this is bullshit, it's not like I just started coding yesterday. I've been a DNN user since the DNN2 days, and DNN7 development process is about to knock me off the platform quicker than a buzzard off a shit-wagon. I guess only cash paying customers get any help anymore, and those of us that paid by being users for the last decade+ don't count. The module I'm working to convert I wrote in 2005, the templates I originally did for DNN4 I was planning on upgrading to DNN7, but at this moment I'm angry enough to just walk away. I don't have time to waste.

 

 
New Post
3/29/2014 5:34 PM
 
I'm somewhat anti stored procedures - they seem like pure busy work to me. I have no need to support the prefix name - whatever it's officially called.

I abandoned DAL in favour of Entity Framework long ago - I won't even look at DAL2.

Come in from the cold!

Best wishes,
- Richard
Agile Development Consultant, Practitioner, and Trainer
www.dynamisys.co.uk
 
New Post
3/30/2014 5:11 PM
 

To add insult to injury I used the VB DAL template set up a folder structure and basic working module. Copied the old VB code into the appropriate folders and added that to the project. Fixed up a new namespaces and imports to deal with some DNN stuff that moves, and I have a compilable module. Install it, and the default view works (with nothing, since there was nothing on it), but the "real" view won't even load, module load exception. Wonderful. More DNN7 "magic". Try all manner of things, no joy, nothing will get past the load exception. I compare to SimpleArticle, force all names spaces to match. Same load exception. 

So I decide to add to the working view page. I add one label, an asp:label, to say Hello World. Guess what, soon as I add a regular asp.net form to the page, I get the joy of module load exceptions. A do nothing at all page with one control fails, so apparently you cannot compile a VB.NET module with DNN7 and have it work.

I guess you can only develop in C#, and if you want anything other than very simplistic database controls you stay with DAL or anything besides DAL2. 

DNN7 is really a leap back in the gutter, and I'm really regretting upgrading my sites to it. This is really a hose job, since DNN6 is a one-off so developing for it is a dead end, and DNN5 doesn't get security patches. This means I'm stuck doing a straight-up conversion of the DAL code to C# to get something to work. I wanted to get to c# anyway, but it's not really worth the effort if it's only to get a module that exactly the same as the old one. 

I guess my next priority is finding a CMS that's developer friendly that doesn't kick the legs out from under it's developer base. There's hardly any traffic here, and very little on other sites like DNNHero, so I guess all the developers have already bailed.

 

 

 
New Post
3/30/2014 6:03 PM
 
VB works fine for module development.

You cannot have a form. Technically you are developing a asp.net WebForms user control. They are not allowed forms and never have been. Your 2005 code could not have had a form init.

Best wishes,
- Richard
Agile Development Consultant, Practitioner, and Trainer
www.dynamisys.co.uk
 
New Post
3/30/2014 9:05 PM
 
Richard Howells wrote:
VB works fine for module development.

You cannot have a form. Technically you are developing a asp.net WebForms user control. They are not allowed forms and never have been. Your 2005 code could not have had a form init.

I added one line with an <asp:label> to the previously working just fine view.ascx (that did nothing) and it broke. You are correct that I misstated the term, but not the fact it doesn't work. Yes, my 2005 code didn't have a form init, but the fact remains code that did work no longer does when it's recompiled with the latest version. That in and of itself isn't surprising. I've been at this since the 70's so I understand the upgrade issue better than most. 

The point is while I may have had to go through the source code of the OS to find a problem in the 70's I shouldn't have to do it now. At least until recently there was viable reference material available so if something didn't work, you RTFM and figured it out. That hasn't been a possibility since DNN5, and if the social options amount to someone telling you "well it worked for me so you're a dufus" the real-time opportunities don't really sound like they're worth the trouble either.

 
Previous
 
Next
HomeHomeDevelopment and...Development and...Building ExtensionsBuilding ExtensionsModulesModulesReady to quit, Developing "real" things for DNN7seems next to impossibleReady to quit, Developing "real" things for DNN7seems next to impossible


These Forums are dedicated to discussion of DNN Platform and Evoq Solutions.

For the benefit of the community and to protect the integrity of the ecosystem, please observe the following posting guidelines:

  1. No Advertising. This includes promotion of commercial and non-commercial products or services which are not directly related to DNN.
  2. No vendor trolling / poaching. If someone posts about a vendor issue, allow the vendor or other customers to respond. Any post that looks like trolling / poaching will be removed.
  3. Discussion or promotion of DNN Platform product releases under a different brand name are strictly prohibited.
  4. No Flaming or Trolling.
  5. No Profanity, Racism, or Prejudice.
  6. Site Moderators have the final word on approving / removing a thread or post or comment.
  7. English language posting only, please.

Content Layout

Subscribe to DNN Digest

DNN Digest is our monthly email newsletter. It highlights news and content from around the DNN ecosystem, such as new modules and themes, messages from leadership, blog posts and notable tweets. Keep your finger on the pulse of the ecosystem by subscribing.  


Copyright 2017 by DNN Corp Terms of Use Privacy
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out