tags:

views:

50

answers:

1

Here's the challenge: depending on the incoming URL I want to display a specific landing page and, upon login, a specific user experience based on the identity of the user.

For example, both www.abc.com and www.xyz.com point to a single Grails instance providing a common portal experience. If the user arrived via www.abc.com, I want to display the ABC splash page with login form. If the user arrived via www.xyz.com, I want to display the XYZ splash page with login form.

Once the user logs in, I'll need to keep the original "brand" context as determined by the incoming URL. For example, even through all the GSPs, controllers, etc. are shared by all users, ABC users will pick up their own CSS, resource bundles (or entries), etc. and the user will have a very different visual experience than XYZ users.

Is this possible? Or do I need to branch the application codebase and host multiple independent portal instances?

+7  A: 

http://www.grails.org/Views+and+Layouts

take a look, I think it can solve 90% of your problems. Have a specific layout for each domain. The layouts are loaded for each view and can assist in defining the look and feel

you can can set variable in a filter, based on the URL, which could then be read in the layout http://www.grails.org/Filters

class MyFilters {
   def filters = {
        myFilter(controller:'*', action:'*') {
            after = {
              if (request.requestURI == "xyz") {
                session.layout = "layout1.gsp"
              } else {
                session.layout = "layout2.gsp"
              }
           } 
        }
   }
}
Aaron Saunders
Thanks Aaron. I was planning on using layouts, but what I haven't figured out is (a) how to have initial landing pages based on incoming URL, and (b) how to set a context variable based on the incoming URL so that I can programmatically determine which layout to use on each page. (I was sorta thinking I'd have to do something like this: <meta name="layout" content="<x:layoutFromBrand/>" />)
ecodan
updated the code to show alternate approach with filter
Aaron Saunders
Aaron- your comment sparked some creative thinking on this end, and we were able to solve the problem by using filters (as you suggested), taglibs, and i18n. Thanks!
ecodan
That filter definition is a bit off since it doesn't declare 'before', 'after' or 'afterView'. It may break in future versions because the behaviour is undefined. For these situations I prefer to use an 'after' filter from which I can put extra values into the view/layout model.
Peter Ledbrook
@Peter Ledbrook thx, edits made
Aaron Saunders