Products

Solutions

Resources

Partners

Community

Blog

About

QA

Ideas Test

New Community Website

Ordinarily, you'd be at the right spot, but we've recently launched a brand new community website... For the community, by the community.

Yay... Take Me to the Community!

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

HomeHomeOur CommunityOur CommunityGeneral Discuss...General Discuss...to DNN or not to DNNto DNN or not to DNN
Previous
 
Next
New Post
10/30/2006 10:35 PM
 

Let's do some hypotheticals.  Say I am hired to build an ecommerce store that will be run as a hosted "ASP" model.  Naturally the client has specific requirements for the project, in addition to the standard requirements of membership, permissions, etc.   As a developer, there are at least 2 options:  1) build it all from scratch which allows me all the flexibility I need but a longer development timeline, 2) use DNN which should cut my development time because I can use some of the built in controls but may limit my flexibility.

The question then is whether DNN is flexible enough to allow a full featured application like a hosted ecommerce store to run in its framework?    Can modules share their logic across different portals?  For example, let's say a merchant signed up for a store account and someone purchased from them and created a login account, could I persist that user's login information so that if he wanted to purchase from a different merchant who also used my store (on a different portal perhaps), he would not have to register again?

I guess the general question is how flexible is DNN in terms of hosting truly robust applications within the framework?

Is it worth it to build into DNN for the time savings which will be realized from being able to reuse common components like login and membership?  Or is better to just build from scratch so that we don't risk the possibility of running into programmatic limitations down the road?

 
New Post
10/31/2006 12:59 PM
 

 

DNN is very flexible and extensible.  The key component in your hypothetical is that you are a developer. What you get from DNN is full source code. You can also get full source code to major e-commerce applications that run as modules inside DotNetNuke.  So starting there you will be way ahead of the game.

Modules sharing logic across portals is built in.  You install one module, but it can be added as seperate instances in many portals.

Sharing users across portals is not built-in, but it would be easy enough to change DNN to support any specific use case. 


DotNetNuke Modules from Snapsis.com
 
New Post
10/31/2006 11:51 PM
 

Thanks for the reply.  So I guess the real question is -- and maybe this is the wrong place for an objective response :) -- but are the built in framework, modules and potential time savings that DNN provides enough to make it worth developing a true hosted multi-user platform within DNN?   Or are the potential limitations of having to fit within the DNN module structure too restrictive to consider DNN as the platform?

My fear is that I will reach a point in developing the system where I simply cannot do what I need to do within the constraints of the DNN module paradigm, and will need to start digging into the DNN source -- something I do NOT want to do.   I know it's a hard question to answer without knowing full details, but perhaps someone can point me to a few examples of some very robust, multiuser, scalable, hosted services and applications that run entirely within DNN.

Any help would be appreciated.

Thanks

 
New Post
11/1/2006 1:21 AM
 

 >As a developer, there are at least 2 options:  1) build it all from scratch which allows me all the flexibility I need but a >longer development timeline, 2) use DNN which should cut my development time because I can use some of the built >in controls but may limit my flexibility.

DNN is a framework thus you have a third option - if option 2 above limits your flexibility then add what ever flexibility you require into the framework.

Basically the only real restriction in the use of DNN is that you must have a content pane - apart from that all apperant or believed restrictions can be recoded to suit your exact requirements.

In the situation you describe - the framework would be used to cut down on development work in displaying and administrating a web site. Your time would be spent in designing an ecommerce solution unless you took some thing like Catalook and modified that to your exact requirments. Such things as having a user signin and updating not only the DNN database but say some merchant databse is minor programming.

DNN may not provide your required Ecommerce procedures but it sure covers all the hack work around them

 

 
Previous
 
Next
HomeHomeOur CommunityOur CommunityGeneral Discuss...General Discuss...to DNN or not to DNNto DNN or not to DNN


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.
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out