I managed to simplify the complexity from DNN and reduced the number of screens from 6 to 2, and saved a lot of the moving back-and-forth between different screens.
The Laboratory Technician is very happy, she told me that speed was improved by at least 3-4 times. Now, you can do the math for 1300 staff.
I will post later the screen shots of the old application (under DNN).
Originally, about 1.5 years ago, the Clinic Application was developed as Traditional Web ASP.NET Applicaiton. Then my colleague took this application, and converted it to DNN becuase it has nice skinning features and saves you a lot of time to get you website with nice portal-like layout and Integrated Windows Authenticaiton out of the box. The application was used for one year under DNN.
During this period, Laboratory Staff complained like hell about the usability of this application, and they begged us to change how Data Entry is implemented.
Also, I noticed the following regd. DNN:
1. The work done inside DNN could not be reused elsewhere,
2. The code is tightly liked to DNN Classes,
3. Very rigid layout that cannot be changed easily,
4. You have to do a lot of steps to implement a small change.
For the new requirements, we had to use Ajax and 3rd party Grid Control (EO.Web). And, to implemented the new required features, I decided to re-build the entire application from ground-up based on User Controls and CSLA .NET Business Objects to make all the work fully reusable in all .NET Supported Platforms.
Now, I have a Traditional Web Application (not liked to Umbraco) where I can test the modifications, and then deploy the changes under Umbraco.
For the first time, it took me 2 days to deply the completed application under Umbraco, this is becuase I faced some minor conflict with Ajaxtoolkit & ASP-LinkButton under Umbraco. But for new changes, all you have to do is to copy/paste some files.
Your screenshots outline that you have a databaund application than a document management solution only. In this case DotNetNuke is the best platform IMHO. And you also can develop and your pages as a separate ASP.NET controls and integrate them on DotnetNuke site pages. There are many developer oriented modues for the dot net nuke that allow you ti reuse ASP.NET stuff. I develop such a module - XsltDb. This module offers web-based development using XSLT, database access and ASP.NET controls creation. Development environment offers a syntax highlighting and code completion. the module is opensource and free, you can review module features at http://xsltdb.codeplex.com. You also be surprised but DotNetNuke 5.2+ goes with Telerik ASP.NET controls. This is a mature ASP.NET UI library that allows developer to create excellent complex UI in hours. And it's also free.
I can see your point. As a mater of fact, when I first examined DNN, I was really impressed. Usually, I do extensive research before I use any product. As a result of the research I did on the Internet, I decided to stay away from DNN.
Also, based on the internal experience using DNN in our workplace, I realized that there are issues with frequent customizations to the deployed application. Also, at the end of the day, you will find issues every where though.
I checked XsltDb, and it seems very powerful. However, its relatively new with about 170 downloads since the beginning of the year.
When I investigated about using User Controls with DNN before I converted the Clinic Application, and based on my research, I found a lot of users reported issues in that regard, and also you have to buy special module to allow User Control integration with DNN.
Why you did not tell me about this XsltDb before I started converting the Clinic Application ? LOL ! Maybe I would have considered using DNN also for the new improvements.
XsltDb is a very young module. I started with it in the end of 2009 and it still has a lot of features to be done. Lack of development tools and techniques in DotNetNuke is obvious for the moment. I tested an Open Web Studio and XMOD modules that allows coding inside them. But they have custom poor programming models and uncomfortable coding environments.
Initial goal for the XsltDb was to provide a flexible integration platform that allows combining existing technologies as ASP.NET, XML/XSL, SQL, jQuery, etc. without serious deployment overhead. AND (!) the environment must provide safe usage for portal admins when any particular admin can't harm DotNetNuke host.
And, after all, why not to have a module development environment inside DotNetNuke!
Ok, I will tell you why is vital to develop the application functionality based on User Controls.
Based on history and expereince at our work, technology and deployment options might change overnight. This is a bad thing, but this is the case. In the end, I decided to go that way, ie, develop the application using base technology that can be reused easily in other platforms. For example, Standard .NET User Controls can be easily redeployed in SAP Portal Framework. We have tested it, and it works.
I think, with the DNN Architecture, this kind of re-deployment option is not that easy.
So, I first developed Standard .NET User Controls, deployed them inside a standard Web Project, and things are working fine. Now, under Umbraco, all what I did is the minor extra effort (copy/past) to deply the same exact functionality without any changes to the coding/layout.
As per my research, this kind of flexibility is not possible, though, you can do some tricks to make it work, which I think will complicate your job.
My first project: Convert a DNN application to Umbraco.
Ref. to this thread:
http://our.umbraco.org/forum/templating/templates-and-document-types/6707-Using-Document-Types-vs-Database
I have migrated all the functions of the Clinic Application which was developed under DNN, all migrated to Umbraco.
I have just deployed the Umbraco Site to the production server, and all seem to be working fine until now.
Now I am working on building the Navigation and Style. Becuase in DNN it was ready out of the box.
Following is a couple of screen shots (naked screens of course !):
Data Entry with AutoComplete Ajax in action: http://bit.ly/c7ExXy
Search Screen (on click, will navigate to Entry Screen): http://bit.ly/d2mR9y
I managed to simplify the complexity from DNN and reduced the number of screens from 6 to 2, and saved a lot of the moving back-and-forth between different screens.
The Laboratory Technician is very happy, she told me that speed was improved by at least 3-4 times. Now, you can do the math for 1300 staff.
I will post later the screen shots of the old application (under DNN).
Tarek.
Hi Tarek.
What reasosn made you switch from DNN to Umbraco? Umbraco is a great system, I'm just curious what shortcomings you ran across in DNN...
Thanks,
Scott
Originally, about 1.5 years ago, the Clinic Application was developed as Traditional Web ASP.NET Applicaiton. Then my colleague took this application, and converted it to DNN becuase it has nice skinning features and saves you a lot of time to get you website with nice portal-like layout and Integrated Windows Authenticaiton out of the box. The application was used for one year under DNN.
During this period, Laboratory Staff complained like hell about the usability of this application, and they begged us to change how Data Entry is implemented.
Also, I noticed the following regd. DNN:
1. The work done inside DNN could not be reused elsewhere,
2. The code is tightly liked to DNN Classes,
3. Very rigid layout that cannot be changed easily,
4. You have to do a lot of steps to implement a small change.
For the new requirements, we had to use Ajax and 3rd party Grid Control (EO.Web). And, to implemented the new required features, I decided to re-build the entire application from ground-up based on User Controls and CSLA .NET Business Objects to make all the work fully reusable in all .NET Supported Platforms.
Now, I have a Traditional Web Application (not liked to Umbraco) where I can test the modifications, and then deploy the changes under Umbraco.
For the first time, it took me 2 days to deply the completed application under Umbraco, this is becuase I faced some minor conflict with Ajaxtoolkit & ASP-LinkButton under Umbraco. But for new changes, all you have to do is to copy/paste some files.
Tarek.
Here are few snapshots about the Clinic Application:
Under DNN:
http://bit.ly/aeMmv3
http://bit.ly/9ACXvj
Under Umbraco:
http://bit.ly/bPLJ4q
http://bit.ly/9D5syp
http://bit.ly/9nRrWg
Umbraco Back-Office:
http://bit.ly/ax9M00
http://bit.ly/cdCzF1
http://bit.ly/cfti4M
http://bit.ly/bjscaL
The applicatio is currently in English, and there is a plan to enable Arabic and French.
Tarek.
Hi Tarek,
Your screenshots outline that you have a databaund application than a document management solution only. In this case DotNetNuke is the best platform IMHO. And you also can develop and your pages as a separate ASP.NET controls and integrate them on DotnetNuke site pages. There are many developer oriented modues for the dot net nuke that allow you ti reuse ASP.NET stuff. I develop such a module - XsltDb. This module offers web-based development using XSLT, database access and ASP.NET controls creation. Development environment offers a syntax highlighting and code completion. the module is opensource and free, you can review module features at http://xsltdb.codeplex.com. You also be surprised but DotNetNuke 5.2+ goes with Telerik ASP.NET controls. This is a mature ASP.NET UI library that allows developer to create excellent complex UI in hours. And it's also free.
Anton Burtsev
Thanks Anton,
I can see your point. As a mater of fact, when I first examined DNN, I was really impressed. Usually, I do extensive research before I use any product. As a result of the research I did on the Internet, I decided to stay away from DNN.
Also, based on the internal experience using DNN in our workplace, I realized that there are issues with frequent customizations to the deployed application. Also, at the end of the day, you will find issues every where though.
I checked XsltDb, and it seems very powerful. However, its relatively new with about 170 downloads since the beginning of the year.
When I investigated about using User Controls with DNN before I converted the Clinic Application, and based on my research, I found a lot of users reported issues in that regard, and also you have to buy special module to allow User Control integration with DNN.
Why you did not tell me about this XsltDb before I started converting the Clinic Application ? LOL ! Maybe I would have considered using DNN also for the new improvements.
Tarek.
Tarek, thanks for reply!
XsltDb is a very young module. I started with it in the end of 2009 and it still has a lot of features to be done. Lack of development tools and techniques in DotNetNuke is obvious for the moment. I tested an Open Web Studio and XMOD modules that allows coding inside them. But they have custom poor programming models and uncomfortable coding environments.
Initial goal for the XsltDb was to provide a flexible integration platform that allows combining existing technologies as ASP.NET, XML/XSL, SQL, jQuery, etc. without serious deployment overhead. AND (!) the environment must provide safe usage for portal admins when any particular admin can't harm DotNetNuke host.
And, after all, why not to have a module development environment inside DotNetNuke!
Anton.
Ok, I will tell you why is vital to develop the application functionality based on User Controls.
Based on history and expereince at our work, technology and deployment options might change overnight. This is a bad thing, but this is the case. In the end, I decided to go that way, ie, develop the application using base technology that can be reused easily in other platforms. For example, Standard .NET User Controls can be easily redeployed in SAP Portal Framework. We have tested it, and it works.
I think, with the DNN Architecture, this kind of re-deployment option is not that easy.
So, I first developed Standard .NET User Controls, deployed them inside a standard Web Project, and things are working fine. Now, under Umbraco, all what I did is the minor extra effort (copy/past) to deply the same exact functionality without any changes to the coding/layout.
As per my research, this kind of flexibility is not possible, though, you can do some tricks to make it work, which I think will complicate your job.
Tarek.
is working on a reply...