As often happens, I have a nice solution to one problem, which unfortunately causes another.
We have an app that provides services to members of various organizations, parts of a larger parent. The organizations require custom URLs. So, members of org A access the URL https://server/vdir/OrgA, and members of org B access the URL https://server/vdir/OrgB.
Both of these would map to the exact same area, controller, and action in the app, although they might look different to the end user due to some custom view content.
Because the list of organizations using this app is dynamic, and because not all organizations will start using it at the same time, I started out setting up the route mapping programmatically. In the target Area, I override the RegisterArea method, pull the active organizations from the database, and execute a custom context.MapRoute call for each.
Doing it this way avoids another problem, which was that the the URLs that have the organization sitepath ("OrgA") in them look exactly like those that have a meaningful area name in them, which actually does map to an area. Treating the organization sitepaths as virtual area names and explicitly mapping them to the target Area avoided certain misdirections.
And this works, nicely. But: it's all executed at Application_Start. If we add an organization, it doesn't become active until we restart the app, which would be highly disruptive to anybody who was using it at that time.
So my questions are two:
Is there a better approach than mine for doing this? I did research the problem, but the relevant keywords are so ubiquitous that it was a bit of a needle-and-haystack situation.
If there isn't one, is there a way to refresh the route mappings without restarting the app?
Phil Haack wrote an article dealing with exactly this problem.
The really, really short version of which is that you place your route registrations in a file other than Global.asax and cache the contents of that file. The cache has the file as a dependency and calls a method when the cache is invalidated (read: file is altered) that re-registers your routes.
Related
So I'm trying to build an app that has two different kind of users, namely customers and sellers. The app is designed in such a way that both of them will have different kind of navigation bars and access to different kind of pages via routes. As such, I'm trying to see what is the best way to achieve this? I'm thinking of either of the following solutions:
1. using compose binding or areas in my shell.html and by having a container and based on a certain condition, the correct specific view (partial view)will be injected and the default binding context will be a common shell.js. However, the nav bar and each navigation panel displayed is determined by the routes that have
nav:true
and both seller and customer will have different routes that are marked nav:true. Is there a way to work around this limitation if we use this approach?
2. using compose binding but having two different views and viewmodels that we bind to our shell.html and shell.js. In other words, there will be two routers. However, I've read a number of posts about having two routers and apparently having multiple main routers in an app is not suggested. Is there another way I should approach this?I was having thinking of having multiple SPAs but I figure that would not be efficient since this is a mobile app. Any help or suggestion is greatly appreciated!
You could simply develop two separate SPAs, but have them share much of the same codebase. With this approach, there's nothing special going on, other than your responsibility to modularize your code for reuse.
This approach would also eliminate the need to incorporate extensive logic throughout to curtail, trim, or augment the web app based on the user currently logged in.
I just started with Joomla 3.x and I'm writing a component for Joomla v3 which is supposed to create new usergroups for creating 'groups'- the design requirements being:
An organisation may set up a group to offer access to some set of services -including communication but also also other types of services - to their members
(the other services is the reason why I believe the community and forum joomla extensions are not suitable- they mostly focus at fora and social media services, not the services I will implement.)
Other persons/members of the organisation may register to this group, which allow him/her to access these services
ps: it is also possible for person to set up a personal account and get access to the set of services. This person may also join one or more groups at a later stage
How to do code the creating of new usergroups? I noticed a possible suggested solution at How to create custom User Group Programmatically in Joomla 3.x, but I struggle to understand how to use the suggested JTableUsergroup class because of the limited documentation at http://docs.joomla.org/API17:JTableUsergroup(?) Does creating an instance of JTableUsergroup results in the creation of a new customer user group?
Another question: how to add users to a customer usergroup? The only hint I found was at http://api.joomla.org/cms-3/classes/JUserHelper.html - using the method addUserToGroup of class JUserHelper.
Many of the Joomla development concepts are well document but I could not find one for managing custom user groups...
Appreciate your help;-)
First, overall, the best consistent documentation of Joomla APIs is in the docblocks for the classes. Then to be honest what I do a lot of times is to search for where in the core the API is used. There are some great pieces of narrative documentation in the wiki, but on the whole I always start with the docblocks which are very complete. However in this case it's pretty simple.
You need to do something along the lines of
$newrow = JTable::getInstance('Usergroup');
//code to add your data
$newtable->save(); // Shortcut for check, bind, store
However, if I were you I would look carefully at UsersModelGroup because there are a lot of other things that should normally happen in this process such as running the user plugins. So I might include and extend that model (which manages the table class) rather than going to the table class directly. In fact your whole component might even be able to extend almost all of the users component or it might also be possible that you could do what you want with plugins rather than reinventing the whole thing.
In terms of assigning users to groups that is trickier because of some legacy things in the code. I think the setter followed by a $user->save() ($user being a JUser instance) is probably the way to go when adding to groups. What I probably would do is to write a custom JFormField that would manage opt-in groups because the core usergroup field includes everything. You could extend that and exclude the groups that you want to have only managed by admin.
I had thought about decorating various control items with attributes to declare group ownership, but this seems a bit onerous and not very extensible/maintainable (I'd have to subclass the controls and decorate them by hand).
Another policy would be to have a white list of groups a control is visible for persisted away against a form id in a db. A check for the visiblity could then be done in a base class from which all my forms inherit, thereby ensuring my class code wasnt muddied with this "adminsitration"
Just seems a lot better than having to write case/if statements based on role to determine what should be visible to users depending on their privileges, in situ.
This seems a pretty common problem and wondered if there were any good patterns to employ.
Thanks
Consider Drupal for building a web-based application whereby GUI capability is governed by user role. The Drupal (an general open source content management system and web framework) has powerful user management whereby each user can be allocated one or more roles. You could then make use of a role to determine the behaviour of a web form and the availability of certain fields for that role. User's with that role would see certain GUI items, whereas others would not.
Some links to follow as a starting point:
http://www.drupal.org
http://drupal.org/project/webform
I should add that Drupal can do many things and not just this specific problem area. Drupal is a broad ranging framework for builing your own websites on your own hosting.
I don't even know if this is even possible, but I thought I'd ask.
I am creating a small CRUD application but I have multiple sites. Each site would use the CRUD. The application would have common CRUD methods and style, but each individual site would apply different forms. I want to avoid creating multiple CRUD applications that varied only in specific content (just different forms).
I want to have something like this:
mycrud.website1.com
mycrud.website2.com
mycrud.website3.com
I can create a subdomain for each individual site no problem. But is it feasible to point all the subdomains to one MVC application directory? And if it is possible any suggestions for how I might go about restricting users from website1 from seeing website2 or website3 content? Is that something "roles" could take care of (after authenticating user)?
Thanks.
There are a lot of websites that do this, not just with MVC. Some content farms point *.mydomain.com to a single IP and have a wild card mapping in IIS.
From there, your application should look at the URL to determine what it should be doing. Some CMS systems operate in this manner, using the domain as a key to deciding what pages to load.
I've built a private labelable SAS application (Software as a Service) that allows us to host all of our clients in a single application. Some clients have customizations to pages or features. We are able to handle that by creating custom plugins for each client that over-ride the Controllers or Views when needed.
All clients share a common code base and aside from each clients custom theme/template they are the same. Only when a client had us customize one feature did we need to build out their plugin DLL. Now, this is advanced stuff so it would require heavy modifications to your code base but in the end if it's what your application needs it is 100% possible.
First - the easy part is having one web site for all three domains. You can do that simply with DNS entries. No problem. All three domains should point at the same ip.
As far as the content, you could do that in a number of ways. I think your idea of roles is pretty solid. It also leaves open the possible of a given user seeing content from both site1 and site2, if that would ever be necessary.
If you don't want to force users to authenticate, you should look at other options. You could wrap your CRUD logic and data access logic into separate libraries and use them across three different sites in IIS. You could have one site and display content based on the request URL. There's probably a lot of other options too.
I'm from a non-computing background and I'm struggling to getting my head around MVC design approaches and frameworks in general. I "get" code re-use, and separation of logic from display, and I "get" encapsulation and decoupling, but I don't get this.
At the moment I simply put everything in root, a separate subfolders for images, cfcs, and _includes, all database interaction via cfcs. I do all my processing at the top of the page, then a comment line then display/page layout below that.
Most of the frameworks I have looked at seem to favour a front controller, so my simplistic version of a top controller MVC design would be a subfolder for cfcs, controllers, and views and a big switch statement in index.cfm
<cfif not IsDefined("URL.event")>
<cflocation url="index.cfm?event=home" addtoken="No">
</cfif>
<cfswitch expression="#url.event#">
<cfcase value="home">
<cfinclude template="controllers/home.cfm"/>
<cfinclude template="views/home.cfm"/>
</cfcase>
<cfcase value="about">
<cfinclude template="controllers/about.cfm"/>
<cfinclude template="views/about.cfm"/>
</cfcase>
</cfswitch>
.. but what real advantage does that give me over a page controller design? Unless it's just the kind of sites I write, I always seem to find that the controller logic is specific to a view, its not like one controller could fit several views or several controllers could output to one view, so what would be the point of separating them?
The light hasn't come on for me yet, any pointers?
By "top" controller, I think you mean "front" controller, a single point of entry for requests into an application. As #bpanulla wrote, most ColdFusion frameworks use this design pattern. This becomes particularly interesting with URL rewriting, where it becomes easy to have search engine safe URLs by intercepting the a URL (e.g. domain.ext/i/am/friendly.ext) and routing it to some standard file such as index.cfm while making the requested URL a parameter (often as a request header). This also makes site redesigns where URLs change easier because it lends itself well to aliasing or redirects.
As far as controllers are concerned, they are usually tightly coupled to a particular URL or URL pattern. It's possible be more loosely coupled with controllers, but in practice I find that's an emergent property after multiple refactorings. What should be underlying the controller is one or more calls to a service layer that talks to the database, executes business process, creates stateful entities, etc... Then the controller receives the service layer's outputs and places them into whatever mechanism (e.g. an event object) is used to pass data to the view(s).
It's the service layer that's meant to be reusuable not the controllers. The controllers are merely an extension of whatever framework an application works within. The idea being that you should be able to switch frameworks with very little impact to the views and service layer. The piece that needs to be touched are the controllers.
So a given service object in a service layer should be able to service multiple controllers. For example, consider showing a logged in users' information as a widget on a site. There might be different pages served by different controllers, but each would call the same service object to get logged in user data that presumably might be given to the same view that renders the widget.
Update: Front Controller Advantages
Security: centralized authentication and authorization.
i18n & l10n: inject the right language pack into the request globally
Process Orchestration: think multi step checkout process for a shopping cart where you don't want the back and forward buttons to work - by routing everything through the front controller you're able to enforce what step (i.e. the state)
Logging & Tracking: easily add Google Analytics or other request tracking to a site by making the addition in just one place
Error Handling: centralized behavior
Now many of these items can also be done using <cferror> and Appplication.cfc, but I find it easier to have one centralized point.
Useful Links
http://java.sun.com/blueprints/corej2eepatterns/Patterns/FrontController.html
http://msdn.microsoft.com/en-us/library/ff648617.aspx
You actually implemented the crux of Fusebox (http://www.fusebox.org/) with what you wrote. There's nothing wrong with that, and most of the ColdFusion community used something similar to that for many years - Fusebox was the most-used CF framework (in my experience) until just a few years ago when ModelGlue, Mach-II and the other second generation CF frameworks came about.
One thing I can point out is that your approach to controllers (as .cfm files) actually does not enforce encapsulation in the typical OOD fashion, with specific arguments going to an object method call. Unless you are extremely dilligent, over time your .cfm controllers may wind up accumulated a large number of undocumented parameters that alter behavior to solve one problem or another.
With the various frameworks you also get nice features like Application, Session, and Request specific code (onApplicationStart, onRequestEnd, etc). But you can always get those through a simple Application.cfc.