SitePoint Sponsor

User Tag List

Results 1 to 7 of 7
  1. #1
    Resident OCD goofball! bronze trophy Serenarules's Avatar
    Join Date
    Dec 2002
    Posts
    1,911
    Mentioned
    26 Post(s)
    Tagged
    0 Thread(s)

    Question MVC controller naming in re: to more complicated routes?

    Since this isn't really a discussion on the mvc framework itself, I started a new thread.

    The default method of naming controllers seems to be, as evidenced by samples and default code, NounController.VerbOrOtherOneWordDescription. For example, the IndexController may expose Index, About, Contact, Support and other one shot documents.

    While there's a lot of discussion on this in the past, especially in the php forums, the way in which the mvc framework instantiates controllers in regards to the route definition is a bit more rigid.

    What if you need a variable amount of routing? The standard is controller/action/param, and in most cases this is fine, but what if, in addition the the preceeding, you have the need for something like module/controller/action/param? A good example of this is an admin utility for a site.

    There are times when names can conflict. For example, users, moderators and admins may all need a route named ThreadController.Edit (I.E. /thread/edit/42).

    What is the best way to handle this?

    - Create a separate admin project?
    - Let the use the same controller action and use different code paths within it, returning specialized views?
    - Create separate controllers within the same project?

    For some reason, I don't like tacking on the term 'Admin' or 'Mod' to a controller name and route (I.E. ModThread.Edit and /ModThread/Edit/42) for example. I would rather it read /Mod/Thread/Edit, but I see no easy way to integrate logic into the app to really allow this.

    Comments and advice?

  2. #2
    ALT.NET - because we need it silver trophybronze trophy dhtmlgod's Avatar
    Join Date
    Jul 2001
    Location
    Scotland
    Posts
    4,836
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    This might be what you are looking for: http://haacked.com/archive/2008/11/0...aspnetmvc.aspx

  3. #3
    Resident OCD goofball! bronze trophy Serenarules's Avatar
    Join Date
    Dec 2002
    Posts
    1,911
    Mentioned
    26 Post(s)
    Tagged
    0 Thread(s)
    Thanks, I just looked it over and will try extending my view engine to fill this need as well. Though my urls will now look like this:

    {locale} / {theme} / {area} / {controller} / {action} / {id}

    While certainly doable, isn't that getting a little TOO url / route dependant?

  4. #4
    SitePoint Author silver trophybronze trophy
    wwb_99's Avatar
    Join Date
    May 2003
    Location
    Washington, DC
    Posts
    10,627
    Mentioned
    4 Post(s)
    Tagged
    0 Thread(s)
    Personally, I think theme and locale probably don't belong in the url, but rather in configuration or user settings. Really depends on requirements though.

    For the serious admin tasks, I'd probably separate out an admin control panel with separate views and controllers. For the shared stuff, I think one could handle it using a view that populates the appropriate shared views for fuctionality based on some user context.

  5. #5
    Resident OCD goofball! bronze trophy Serenarules's Avatar
    Join Date
    Dec 2002
    Posts
    1,911
    Mentioned
    26 Post(s)
    Tagged
    0 Thread(s)
    Yeah. Normally, I'd agree. Here's what I'm facing though. The application needs to 100% skinnable and localized.

    Since the Mvc.ViewPage class doesn't have any direct access to culture, I cannot set things in code easily. I could write a helper class but I wanted to see if I could make it such that I could simply copy and past an existing theme into a new locale folder and run. The only thing I'd update is all the culture and uiCulture settings in the @Page directives for the new theme's views. I originally tried a web.config globalization at the theme level, but that didn't work. I can't just store it in the main web.config though because users need to be able to click-and-switch.

    That's not what this is about though. It's about controller and action organization and naming in regards to differing areas of the app that might cause naming conflicts (hence the above article on namespaces). I'm still looking into things and trying to decide what's best for my app.

  6. #6
    SitePoint Author silver trophybronze trophy
    wwb_99's Avatar
    Join Date
    May 2003
    Location
    Washington, DC
    Posts
    10,627
    Mentioned
    4 Post(s)
    Tagged
    0 Thread(s)
    If you need culture info and/or theme info at the page level, you should be passing them down into the View's Model. No matter from whence it came be it Url, web.config or divine inspiration.

  7. #7
    Resident OCD goofball! bronze trophy Serenarules's Avatar
    Join Date
    Dec 2002
    Posts
    1,911
    Mentioned
    26 Post(s)
    Tagged
    0 Thread(s)
    I totally agree. However, I couldn't find a reasonable way to implement it View side. Let's say I've passed something on using ViewData("locale") and set it to "en-US". How do I actually change the culture using that info in the view? We don't have access to the settings needed, at the right place.


    <% Page.Culture = "en-US"%> <!-- this won't work here -->
    <asp:ContentID="indexContent"ContentPlaceHolderID="BodyContent"runat="server">
    <% Page.Culture = "en-US"%> <!-- this won't work here either -->

    There needs to be a better way to set this so that <%=Resources.Locale.MyString %> works correctly.


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •