BugNET

donker wrote Hi Davin, Sounds good. I can do the DNN part and take care of CodePlex. Now about the DAL. The web service is architecturally the 'neatest', IMO. But then I'm blocked until we have something fleshed out. The alternative is a separate assembly. I have spent about 4 hours yesterday converting your DAL to something I can refernce with my module (i.e. rewiring connection strings etc) and ripping the old code out of my module. The hard part (and what makes it less preferable) is that you use a different design pattern than DNN. You already use a lot of objects in the same methods that handle data access. This means I also had to import all your BLL classes. There is the advantage that I can then use the rich object of course. But often in module development, I'd also like to use IDataReaders for speed and flexibility. So I end up having to write maybe double methods for this as there is no base class that outputs the data readers. In all I end up with quite a big BugNET library (all DAL and BLL) and this is not a good idea for future maintenance. Conclusion: let's use web services for all transactions and I'll use my own data readers when I feel that is better. Do you have some idea on how we can go about the web service? What are your thoughts on the issue of authentication integration? Like I said earlier I merged the databases and set your app ID to 'dotnetnuke' to make this work. But it'll only work in BugNET if some adjustments are made to the SPROCS as well to make sure the right users are being pulled from the aspnet tables. We should also provide scripts for people to migrate from regular BugNET to this IMO. Peter

Web Services it is.  It is up to you how you would like to proceed. I can make some time to create methods that you need or if its easier for you to do it and submit patches or I can give you write access to the repository.  There is a webservice class already created in the project  where all the methods can be added.

I agree with you about the authentication, BugNET currently assumes you are only using one application id with the authentication so work is needed here to make it more flexible.  This is probably best done anyways for the future of the project.  Your ideas of using a sproc or function to get the current application good.   I believe someone logged this issue before, probably doing similiar integration work.

Again if you think you can make these changes faster than I can your welcome to.  I can handle the final installation or change script if you want as I have the sql redgate tools which makes it easy to do so.

Davin Dubeau
BugNET - Core Developer

Davin,

Giving this some more thought I believe we should be doing it this way: lets maintain a library which you hook up to your webservice and I keep DNN compliant. This dll would be used in any project that wants to use BugNET from within DNN. I have created a project for this called 'BugNETLib' and it is on Codeplex:

http://www.codeplex.com/bugnetlib

If you give me a codeplex login I'll add you to the developers. Then you can work on this as well.

The current code that's in there today

The code that's there was generated from Codesmith templates and is just a reflection of the objects you have in the db. Importantly we now have all objects as 'ObjectInfo' with a bunch of core interfaces implemented, and the ObjectControllers. The latter will be your department. You get to hook these up with the web service. The ObjectInfos will implement IHydratable for efficiency and we can extend the column list that it implements to include the columns like StatusName.

The interfaces like IPropertyAccess will allow people to use token replace on all your objects. Great for rendering to screen or email.

If you want we can inherit the Info classes from your regular object classes. Let me know what you think is best here.

Peter

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