Im building a Grails app that will have multiple similar websites (each it's own domain name) with the same code but different design and configuration. (think of blogger)
What is the best method for using different view and even some different logic on a single app without too much hacking?
I'm new to Grails and the method I have in mind is to check all the time to see what the domain name is and to serve the right controller/view. Is there a better way?
I would have a go with the MultiTenant plugin. You mention that views and logic differ, but I'm guessing what will differ most is the data? Use MultiTenant to cleanly separate the data for each site without too much hazzle, and if you store the configuration of views and logic in the DB you get that unique per site as well.
I think MultiTenant is being updated to the latest Grails release, at least I've seen that mentioned in the Grails mail list. I think you need to use an 1.2 release until then.
I'm doing something similar to separate data using the Hibernate Filter plugin. My views are the same but I have per-site texts and messages by looking up message "SITE-A.hello.world" first and if not found the default message "hello.world" is retrieved. Just to give you an idea how views may be customized, though you probably need to take it further than that for your system...
Related
I been practicing developing an application in .NET and with other languages and server, and now I want to start sketching out an architecture I want to implement.
The reason why I want to separate the two is because I cannot focus on a specific thing when everything is Jumbled into one server. I would like to be able to have the freedom to offer features that would otherwise bottleneck one server and not another(ex. notification, chatting)
What brought me here to ask this question is because I am totally confused on why everything on the UI is always called MVC. When searching for solutions to a distributed architecture that I can implement I keep running across frameworks that use an MVC pattern.
How does this actually work when you already have your API models? Isn't an MVC pattern just going to duplicate all of the models on the API (ex django, asp.net mvc or ruby on the rails)?
One scenario that threw me off and brought me to research a whole lot more, is when I wanted to create a registration form that has steps, validating the username uniqueness was on one step and zip code was on another. I found myself wanting the tweak the API based on how I wanted to present my view and thought about having to do that for different types of clients(mobile, different user agents) and quickly backed off that idea. The problem is those fields need some sort of call to the back end and every view wont have that way of registering.
The main question is how do I implement a UI layer that I can customize toward certain views, without changing the way my API is structured?
You might be interested in this article from LinkedIn dev team.
https://engineering.linkedin.com/frontend/leaving-jsps-dust-moving-linkedin-dustjs-client-side-templates
I have been building multiple grails applications, which are basically just the different tabs (4) of my web dashboard. I had initially thought I could simply make a sidebar and use different views, their corresponding controllers and also their corresponding domain classes simultaneously in my final single grails application.
But, after reading the documentation I don't think this is feasible. Or am I wrong here?
So, I need to combine all of these and make one final grails application with a sidebar having 4 options there, wherein on clicking on each of the options - a different view is rendered.
But these different views are connected to different controllers and different domain classes.
Can these all be combined into one grails application? If yes, how do I go about accomplishing it?
I cannot find any documentation regarding these.
One useful link : http://javadeveloper.asia/grails-ajax-tutorial-remotelink-tag/
Any suggestions/approaches will be highly appreciated.
I am considering breaking my Grails app into two separate apps: admin and customer facing. The admin app would also do a lot of backend heavy lifting.
Has anyone done this? Lessons learned? I'm particularly wondering about the best way to handle domain objects as well as potential issues with concurrency.
You could run into race/locking conditions but I've seen this done on many occasions. My only suggestion is that you not maintain separate domain classes. Put common domain classes in a plugin and install said plugin in both applications.
If you really want to do that, the best way is to separate existing Domain classes too, instead of enable multiple direct access from all the apps. Keep each Domain class persisted by the app mostly closed to it. For other apps, they should access the data through RESTful service provided by the data-hosting app.
You might want to keep the domain classes exactly the same, therefore generating same db tables.
I don't think concurrency will be much of a problem, as modern dbms usually handle that really well.
I'm new to Grails and web development. I started doing a project on Schedule management website stuff. I came across the Service concept that is provided by Grails. I understood the concept, but still I have confusion on when to use services.
For example, I need to implement a search module, where the manager can search for a user to find his schedules. In this case it will be good to implement it as a controller or as a service?
So,
When and where should I use Service?
To add to Grooveek's answer;
It is also nice to use Services to keep your Controllers nice and clean.
So Views just render data to the screen, Domain objects store state, Controllers route the user around the application, and Services perform the work.
I don't have enough reputation to comment on an answer or vote up so I have to provide an answer that really should be a comment. Anyways...
+1 on #tim_yates answer. Gotta love thin controllers. 2 things that I would add to the description of a controller:
Would be to translate parameters from the browser before hitting a service (e.g. Date, number, etc.)
Would be to translate data returned from services into something consumable for the views.
For me, ideally, services would never deal with translating a String parameter to it's inherent type. Or deal with building a model to be displayed on a view.
What and where I should use Service?
When you want your controller do to something that may be reused by other controllers
In our application we're doing a functional separation of service. We have a CorePersistanceService, which provides method to create, delete, update and manipulate Core Domain Classes (core for us).
I think persistance services are a good way to reuse GORM code throughout Grails code. You can create method in domain classes, but I don't like that, it's way less maintanable I think
We have a PDFService class for our PDF creation, a SolrService which connect to Solr, a Statisticservice that gather all our methods which collects statictics on our datas
Services in Grails are a manner to gather methods around a particular functional theme, in order to give possibility to reuse them in controllers (I forgot to mention our SecurityService, which is a pretty good Cross-Applications Example)
I'm building a new SAAS application and was looking for some advice on the most appropriate framework to use. I realize that no single framework will likely be able to do all this, but I thought I'd ask the community and try to find one that solves the hardest problems.
Requirements
Single code source. (each customer will have either a subdomain, or a distinct domain, but everyone should be running off the same code base and same servers)
Should be able to update the programming source once and have all the tenants pick it up
Session information should either be kept in a cached store, or just in cookies (no shared state)
Multi-tenant database functionality built in. (Based on the domain used to reach the application, the framework should automatically use the database connection information assigned to that domain)
Each customer/domain may have their own template for the web pages. Templates need to be assignable on a per-customer basis and kept outside the application code
Security and rapid prototyping is more important than speed
There will be a lot of CRUD type screens, so simple built in functionality for this is desired
I have pretty lengthy Java and PHP experience, but would only consider PHP as a last resort for this. My Scala, Python and Ruby experience is a bit rustier, but I would not mind coming up to speed if they offer a significant advantage. I've looked at the Play! Framework and like it (fulfills #1, #2,#6 very well), but the multi-tenant aspects are not very strong. I've done several projects using Grails and it handles everything except #3 and #5, and can be hacked to do the rest.
I would say that the third point is rather independent of grails/play/whatever in general. If you need a shared cache there is a multitude of providers for this and there are plugins for most of them in Grails.
The multi-tenancy in grails is pretty mature and much less intrusive than the solution from the blogpost in Sebastiens answer. Whether or not you use single tenancy (multiple databases) or multi tenancy is more or less transparent to your code and most of the headaches are abstracted away. Do be aware that you need to do some smart indexing (like including the tenant id in a multi column index etc) to not get very sad speeds when your data starts to grow.
As for externalized views, you can either slap them in the database or symlink them into your webapp and just keep them in separate numbered folders. Then from the tenant plugin, you can use TenantUtils.getCurrentTenant() and simply render from the appropiate folder "/" + (tenantID ?: "default") + "/whatever/view/path". This way, layouts etc can be shared across tenants if you so please and you simply put tenant specific stuff in the tenant specific folders.
You can probably do this in play too, or , but I don't see anything hindering you from doing this just fine in Grails.
My $0.02 on this question.
Actually Play! fits well to what you'r looking for.
Read this post:
http://www.lunatech-research.com/archives/2011/03/04/play-framework-writing-multitenancy-application-hibernate-filters
It works great. You can even make this filter work so that you can expose the crud module to customers and they'll only get their own data...
For very large applications, sharding seems not supported yet (no hibernate shards handled yet i think).
There's a multidb plugin to work with multiple db, but it seems not working very well yet...
I've heard that Grails' Multi-Tenant plugin offers some good tooling for several different methods of multi-tenancy.
"Each customer/domain may have their own template for the web pages.
Templates need to be assignable on a per-customer basis and kept
outside the application code"
I assume you mean they each have their own layout/skin. There are several techniques to execute this:
You could manually assign layouts based on tenant. <meta name="layout" content="${tenantName}/main" />
Write your own tenancy aware LayoutDecoratorMapper and override the default GrailsLayoutDecoratorMapper in sitemesh.xml
Figure out how to override and enhance Some internal tools dynamically resolve views(per tenant) or resources (GrailsViewResolver, GrailsConventionGroovyPageLocator, GrailsResourceLoader, etc.)
In PHP you can use Innomatic Platform for building multi-tenant (isolated databases) applications:
http://www.innomatic.org