We are considering purchasing DotNetNuke (or Sitefinity) on pretty short notice and there are is a question I have that I am having trouble finding a quick answer to. (I have a separate but similar post with Sitefinity as the focus, if you can answer that better or in addition.)
We are currently not using any CMS at all and we have some custom development that will not go away just because we go with a CMS for some or most of our site.
Our custom development is c# ASPX with Site Master and nested Site Master pages. These custom apps do not own their own top level in our web site, but are part of a branch, typically one or two levels down (for example, http:www.contoso.com/branch/app/default.aspx).
How is DotNetNuke typically configured in a CMS/Custom “mixed mode”? For example, is DotNetNuke installed at the “top” of the web site, or “where needed” down in the web site.
How does this relate when mixing CMS and custom web applications?
Does the CMS interface allow for adding these custom apps or do you just go to the web server and add them to the structure?
It appears from reading other posts, we can create our own custom c# modules and have CMS editors “drop in” the modules on the pages. Can someone confirm that for me?
If I did not provide enough detail, please feel free to ask for more.
DNN is most commonly installed at the root of the website, but that is not required. It is sometimes run as an application in a virtual directory that is part of a larger site.
It is possible to add .aspx pages at the correct location within the DNN. The UrlRewrite handler will initially look at all such requests, and assuming that existing pages, and friendly url handlers don't think they "own" the .aspx page, DNN will stop processing the request and hand it to your page. There is no specific way to "register" these pages with DNN. I wouldn't generally recommend this approach, but it does work and can make sense in specific situations.
Alternately, you can write your own DNN modules. Existing code, can usually be quite easily be adapted by converting the code to work in .ascx user control that inherits from PortalModuleBase. Code that wants to take advantage of core DNN features e.g. membership or permissions will of course need to be modified to use the DNN APIs.
The DNN module approach is generally the best option. But the details of your situation may make one of the other approaches more appropriate for you. Basically as long as your site is layed out so that it is clear which requests are destined for DNN and which are not, you can mix and match with other asp.net code as needed.
One thing that causes trouble in a mixed configuration is configuration inheritance.
If DNN is the root application, you'll either have to remove problematic http modules and handlers in the application's web.config or disable inheritance with a location setting in the DNN's (root) web.config:
<location path="." inheritInChildApplications="false">
<system.web>
...
</system.web>
</location>
Maintaining the inheritance between application's web.config and DNN web.config is fragile.
Changes in DNN web.config can cause the application in the virtual directory to fail. In addition to removing each http module and handler, you'll need at least to add DNN's App_Code directories to the application configuration.
On the other hand, location setting does not always play well with DNN modules, especially if they have aspx pages in addition to controls inheriting from PortalModuleBase. Personally, I've never got the location setting work well enough with DNN.
See also
How to disable web.config Inheritance for Child Applications in Subfolders in ASP.NET?
How do I stop web.config inheritance
Avoid web.config inheritance in child web application using inheritInChildApplications
Related
How can I manipulate other modules without editing them ? very the same thing that wordpress modules do .
They add functionality to core system without changing the core code and they work together like a charm.
I always wanted to know how to implement this in my own modular application
A long time ago I wrote the blog post "Use 3rd party modules in Zend Framework 2" specifically about extending Zend Framework 2 modules. The answer from Bez is technically correct, it could be a bit more specific about the framework.
Read the full post at https://juriansluiman.nl/article/117/use-3rd-party-modules-in-zend-framework-2, but it gives you a clue about:
Changing a route from a module (say, you want to have the url /account/login instead of /user/login)
Overriding a view script, so you can completely modify the page's rendering
Changing a form object, so you could add new form fields or mark some required field as not required anymore.
This is a long topic, but here is a short gist.
Extensibility in Zend Framework 2 heavily relies on the premise that components can be interchanged, added, and/or substituted.
Read up on SOLID principles: http://en.wikipedia.org/wiki/SOLID_(object-oriented_design)
Modules typically consists of objects working together as a well-oiled machinery, designed to accomplish one thing or a bunch of related things, whatever that may be. These objects are called services, and managed by the service locator/service manager.
A big part of making your module truly extensible is to expect your developers to extend a class or implement a certain interface, which the developer register as services. You should provide a mode of definition wherein the developers can specify which things he wants to substitute, and/or add their own services to -- and this is where the application configuration comes in.
Given the application configuration, you should construct your machinery a.k.a. module services according to options the developer has specified i.e., use the developer defined Foo\Bar\UserService service as the YourModule\UserServiceInterface within your module, etc. (This is usually delegated to service factories, which has the opportunity to read the application configuration, and constructs the appropriate object given a particular set of configuration values.)
EDIT:
To add, a lot can be accomplished by leveraging Zend's Zend\EventManager component. This allows you to give developers the freedom to hook and listen to certain operations of your module and act accordingly (See: http://en.wikipedia.org/wiki/Observer_pattern)
I own a Play 2.1 application.
Initially, I used the default template mechanisms from Play 2.1 until I .. learned AngularJS.
Now, I clearly want my client side to be an AngularJS app.
However, while surfing the net, I find there are no clear way to achieve it:
Letting Play behave as a simple RESTful application (deleting the view folder) and making a totally distinct project to build the view (AngularJS app initialized by grunt.js).
Advantage: Likely to be less messy, and front and backend teams would work easily separately.
Drawback: Need another HTTP server for the AngularJS app.
Try to totally integrate AngularJS app with the traditional Play's workflow.
Drawback: With a pretty complex framework like AngularJS, it would lead to a confusion of templates managementfor instance : scala.html (for Play) / tpl.html (for Angular) ... => messy.
Making a custom folder within the play project but distinct from the initial folders created by the Play scaffolding. Let's call it myangularview instead of traditional view for instance. Then, publish static contents generated by grunt.js into the Play's public folder, in order to be reachable from browser through Play's routing.
Advantage: SRP between components is still fairly respected and no need to use another light HTTP server for the client-side like in 1.
I pointed out my own views of advantage and drawbacks.
What would be a great way to achieve the combination of Play with Angular?
Yes, I'm answering to my own question :)
I came across this way of doing:
http://jeff.konowit.ch/posts/yeoman-rails-angular/
Rails?? No matter the framework is, the need remains exactly same.
It advocates a real separation between APIs (backend side), and front-end side (in this case making AJAX calls to backend server).
Thus, what I've learned is:
During development phase, a developer would use two servers: localhost on two distinct ports.
During production phase, the front-end elements would be encompassed into the whole backend side (the article would deal with a kind public folder, aiming to serve static contents: HTML, angular templates (for instance), CSS etc... Advantage? => dealing with a one and unique serving server's APIs exposition as well as static assets for the UI.
With this organization, some tools like Yeoman would be able to bring some really awesome handy things to developers like for instance: the livereload feature. :):)
Of course, during development phase, we end up with two different domains, (localhost:3000 and localhost:9000 for instance) causing issues for traditional ajax requests. Then, as the article points out, a proxy may be really useful.
I really find this whole practice very elegant and pleasant to work with.
There was an interesting discussion on the play mailinglist a couple of days ago about frontend-stack/solution, could be something in it for you, quite some people using angular it seems: https://groups.google.com/forum/#!searchin/play-framework/frontend/play-framework/IKdOowvRH0s/tQsD9zp--5oJ
while developing GWT apps we ran into lots of problems with project configuration. Let me explain... As usual in development, we have few environments for our application: local, demo, preview and live. Of course they are running on different machines, some are using SSL while others don't. But most importantly - all of them have different URLs.
Now, in few places in our application we need specify some URLs. Usually we would use *.properties files stored on server, and tools like Spring taglibs and it's <spring:message /> tag. But since GWT does not have such tools, we ended up in leaving hard coded URLs and performing code replacement on different SVN branches. As you can imagine - this is the worst possible scenario, causing us much problems.
So, my question is:
how one could build proper, flexible mechanism of storing config properties shared for both client and server side in GWT application. This properties have to be available for server-side handlers, client app (compiled JavaScript), UiBinder, other code running on server (workers, Spring, etc.).
The preferred way would be to avoid gwtc build if we change value of some property, but I guess it will be hard to achieve. So I will accept any reasonable alternative.
How about using relative URI references (e.g. absolute paths, without scheme or authority; i.e. /path/to/foo instead of http://example.com/path/to/foo)?
And in the few places where you absolutely need an URI (with scheme and authority), then use another property to store the "prefix" (e.g. http://example.com), and then concatenate with the above path.
Those places where you need a full URI should all be on the server, which means you don't have to recompile your GWT project when you change the "prefix", so everything is only runtime configuration and you can deploy the same artifacts in all environments.
That being said, if you ever need something configurable at runtime in GWT, then use a dynamic host page and JSNI (or a com.google.gwt.i18n.client.Dictionary); see http://code.google.com/webtoolkit/articles/dynamic_host_page.html
I'm a bit puzzled about Zend Framework modules.
I mean - I understand that you would usually want to have frontend and backend module... right?
But - What else would you separate out into modules?
can someone who uses Zend Framework professionally give an example of what modules they have in their application?
In the Zend MVC lingo a module is an independent part of your application. For example if you want to write a Content Management System you will probably have different modules like
Main application (user login, application bootstrap etc.)
Blog
News
Admin panel
Image gallery
Basically each of these modules could act as a separate application (although they will eventually be interconnected). The module approach also gives you an easy way for permission management (e.g. users can only pay for using certain modules).
As addition to Daffs answers we could try to figure out some guidelines for deciding between choosing a 'controller' or a 'module' to implement a certain bundle of functionality. Please help making this list comprehensive by commenting or editing:
When to use a 'controller':
when there is a considerable degree of dependency on different models of the same module
when there is a considerable degree of interaction with other controllers of the same module
when the functionality can be covered with a few methods/actions
when the functionality is clearly just a bundle of subordinated functionality of the given module
when the functionality can be easily maintained together with the rest of the code (versioning, deployment, ...)
When to use a 'module':
when there are no or almost no dependencies with the main modules controllers and models
when the bundle of functionality can be seen as a separate (sub)application
when the functionality can't be covered with a few methods/actions and thus has to be broken down into several controllers
when versioning and deployment needs independence from main module
In a MVC application, what are some of the components that make up the application. What tools and functionality is missing that you would like to have. Regardless of the server-side language, what would you want?
I see a lot in my code where I code some much functionality that it seems should already be there. I looked at Google web toolkit and they seem to get it right. Widgets are widgets and you simply add them to your application.
For example. I work with J2EE apps but in other languages, the components are the same.
Controller Objects
Controller handlers, defined by methods in the controller objects.
Configuration files defining the URL mapping and settings.
Template server page files (e.g. JSP/ASP files).
Configuration files defining O/RM mapping between application objects and the database.
Configuration files defining the database connection properties.
JavaScript libraries (e.g. jQuery)
Logging configuration files
Resource message bundle files
Validation configuration files or code
Middleware components and objects (EJB configurations, JMS/Messaging configurations, etc).
Credit Card or other middleware connectivity APIs and libraries.
Anything else you can think of?
Built-in Unit Testing Component
I think one thing you're missing from that very exhaustive list is the automatic binding of request properties to form objects, and the saving of these objects to the session where appropriate. Form objects here being the object on the server that represents the current state of the HTML-based for displayed to the user.
I think scaffolding and automatic admin interfaces are very nice features too, that I dont want to miss ;)
You've made the assumption that all MVC applications are websites. MVC is widely used for more than just web apps so things like URL mappers, template server pages and "Server side" languages are not associated with the MVC pattern, so much as a particular implementation and adaptation of the MVC for use in web apps.