BugNET

donker wrote Hi Davin, Sorry for not getting back to you sooner, but you are now part of the team. If you look at the project you'll see 5 files: BugInfo and -Controller, ProjectInfo and -Controller, and 'Others'. The latter file holds the same classes for the other objects in your data layer. I have left them in there and maybe one day we'll split them out. As you'll see I've started by generating the CRUD methods for every object in the various controller classes. Obviously at this stage we don't need everything. For now I'd like to concentrate on the Bug and Project classes as they will be central in our effort. As I see it, it is up to you if you want to use SQL or web services to access bugnet. DNN comes with the Enterprise Library from MS which includes the SqlHelper class. DNN has some nice helper classes as well that you could hook into. If you want to investigate this line then I'd advise to download the source version of the Announcements module, for instance. It's a nice reference to see how DNN can be leveraged to do data access. Check out the SqlDataProvider class and the Info and Controller classes. The Info class implements a bunch of DNN interfaces some of which can help us in the future (like hydrating an object). Let me know what you think and if I can do something. Peter

Hi Peter,

I had a chance to poke around yesterday I think it was in the source and take a brief look at it.  Looks pretty straight forward and I will start to implement the bug and project webserivces and then hook up some calls from the  controller objects.  This weekend is a long weekend for me and I will be away but I may have some time on Monday to work on this.

Cheers,

Davin Dubeau
BugNET - Core Developer

donker wrote Hi Davin, Any luck yet? About the implementation: the advantage of using web services for your calls is that you can keep this quite stable over time. The disadvantage may be that it will be a lot of work to make. I'm not sure. The alternative is to build a DAL for this component: SqlDataProvider and scripts. This could be faster (I have code crancking templates that would pump the basic CRUD implementations) but it would mean you'd have to keep this in sync with the main project. It's up to you how you want to implement this. One last note on this: I think we should assume that people merge the bugnet and DNN into one database (so there is no benefit with web services regarding the ability to have the websites remote, IMO). To me it doesn't make much sense to keep them seperate as you'd miss the great benefit of having unified user accounts. Unless you want to build synchronization for that. But I'd be wary of going there. Peter

Hi Peter,

Unfortunatly I was away all weekend and haven't had any time this week yet to sit down and do anything.  Your comments make sense to me and it sounds like you have a good process for churning out DNN code.   Lets go with your suggestions, it may be a bit harder to keep in sync but we will be able to develop it faster and use the full potential of integration between the two systems.

I will eventually work on the webservices for external integration, SVN, issue capture etc.

Davin Dubeau
BugNET - Core Developer

Just when I thought things couldn't get better...

I have been really fond of DotNetNuke as a framework.  Lately, I have also been looking at project/issue applications and I had already decided that I liked BugNet the best. 

And then, what do I see but a codeplex project with both.  Hmmm.  Can't wait to take a look.