I'm looking at grails (2.2), and it's all beautiful and even magical, how it all works. I'm looking at a Controller class which is created with grails create-controller and out of the box it has many methods and properties available, like render(), redirect(), params, request and I presume it goes on and on.
where does all this get wired in? Where in the code/project/framework do I see that render() is made available as a method? And how is it implemented?
As a java developer I'm used to inheritance and code injection and reflection. And in javascript prototypes can do some black magic. But the XXController.groovy is just a standalone object. Is it the name (XXController) or the location (grails-app/controllers?) or is there some injection happening which the IDE can pick up?
Welcome to the wonderfull world of Grails,
Here you have a couple of links that may help you:
The Section of Controllers in the Web Layer docs.
And the docs of the render method. Check it out the "Quick reference" column at the right for more methods avaliable at the Controllers.
If you are wondering how that magic is done, Grails is an open source project, so as usual, go and serve yourself at Github (warning, it is quite large project).
Grails works on the top of Groovy, which is a Dynamic Language with a powerful support of meta programming. Tha is basically the trick of all the magic of Grails
Finally, Grails is a framework based on CoC (Convection over configuration), So the Controllers will be any class under the directory "grails-app/controllers" and with the suffix "Controller". (In the folder of controllers may be "commandObjects as well).
The integration with well-know ides is quite powerful as well, you should check it out
EDIT
You may also found how the render methods behaves here at github.
And more inyected stuff at the Controllers metaClass package
As of Grails 2.0+ it's implemented using an AST transformation - previously it was done by adding the methods to the Groovy MetaClass. The benefits of the new approach are that things will be a bit faster and use less memory.
GORM domain class methods now use this approach too (except for dynamic methods like findByFooAndBar which have to be added dynamically to the metaclass) and those have the benefit of being callable from Java since the AST adds the methods to the bytecode. This doesn't help controllers though since they're only called from Grails itself as the result of a web request.
For the gory details, ControllersApi is where the methods are, and they're mixed into each controller class by a combination of ControllerTransformer and the code in the doWithDynamicMethods closure in ControllersGrailsPlugin
Related
In the new ASP.NET 5.0 (vNext), the startup code relies on the IApplicationBuilder interface. The Use method is used to add a handler to the builder, while Build is used to construct the final delegate. But I can't figure out what is the purpose of New. I've been digging in GitHub, but can't find any place where that's used.
Anyone understand what is the purpose of that method?
New() creates a second ApplicationBuilder, sharing all the ApplicationServices and ServerFeatures of the first one, but none of the middleware. It is used internally by the branching extensions (Map, MapWhen, UseWhen) to create the new 'branch'.
You can find the implementation here: ApplicationBuilder.cs.
In some cases, it is also useful in higher-level frameworks.
For exemple, the [MiddlewareFilter] attribute in MVC Core uses New() internally to execute a piece of ASP.NET Core middleware inside the MVC framework (i.e. as a filter). MVC Core creates a small pipeline around the middleware, builds it into a RequestDelegate, then runs the HttpContext through it. Just like ASP.NET Core does with your 'main' pipeline built in Startup.cs.
Thanks to this feature, we can reuse a piece of general-purpose ASP.NET Core middleware, from inside MVC.
For more information, see MiddlewareFilterBuilder.cs in ASP.NET MVC Core.
It appears to be there to branch [clone] the original instance (as can be demonstrated in src/Microsoft.AspNet.Http/Extensions/MapExtensions.cs). There was also a previous MapWhenExtensions.cs, but it appears to have been removed from the dev branch.)
I suspect it's an artifact of a previous design that would provide the ability to bind middleware based on circumstances without affecting the root's configuration. The fact that it's been there since before IBuilder was refactored to IApplicationBuilder and that most dependencies were in files that have since been removed from the dev branch, I would venture a guess that it's old news.
Of course it's hard to tell given neither the interface nor the base implementation are commented.
I am implementing new project. I completed one use case, I likes to use scaffolding to generate all other uses cases. if i use generate-all it creates controller, services and views, But problem is, in my use case, there is 4 more types of classes <Domain>Search.groovy, <Domain>SearchBuilder.groovy, <Domain>TableDef.groovy, <Domain>DetailDef.groovy for every use case. So i have to create these four also with generate-all command.
how can i achieve with scaffolding.
A pracmatic approach could be to extend the set of templates (as you mentioned) and additionally to write your own gant scripts. Take a look at $GRAILS_HOME/scripts for some inspiration (i.e. 'CreateController.groovy').
I've an ASP.NET MVC application using Ninject3 (NuGet install). The solution contains:
an MVC project (composition root);
a Domain Model project;
a Data Layer project;
a scheduler project (running scheduled jobs within a windows service and holding an alternative composition root);
some other projects.
I'm following the approach to have many small modules spread across the projects defining the bindings. The two composition roots use exactly the same bindings.
I cannot figure out how to configure scope for the modules within the class libraries. For example, given these bindings:
Bind<IDomainService1>()
.To<Service1Impl>()
.InSingletonScope(); //This should always be a singleton
Bind<IDomainService2>()
.To<Service2Impl>(); //No scope specified
I would always want a single instance of Service1Impl, whereas scope for Service2Impl should depend on the composition root used. MVC project should have InRequestScope() for Service2Impl (and for all other bindings with unspecified scope). Scheduler project, which does not run within an http context, should use InThreadScope().
Is this approach correct? If yes, what is the right way of configuring this behaviour?
In Ninject, not specifying the scope means InTransientScope().
Your choices are to either duplicate the bindings or create a custom InScope() scoping rule for the binding.
The cleanest solution (especially given that MVC is already in play) is for you to create a plugin that slots into the InRequestScope() mechanism.
There is a CreateScope() method which currently has minimal documentation in the ninject.extensions.namedscope README, which is used like this. It requires you to select 'Include Prerelease' in NuGet. (And I should be writing a wiki article on it but I have too many other things on my plate...)
I am trying to properly use Ninject to inject log4net logging into my MVC3 application. I am using the Ninject.MVC3 package, so I have the NinjectMVC3 class that automatically extends the App_Start method and contains the RegisterServices method that binds all dependencies. I also have the Ninject.Extensions.Logging.Log4Net package, but I don't know how to use it. I already know how to configure log4net in my web.config, but don't know how to use this extension for DI.
I have read all the following articles/posts, but none of them seem to define how to properly setup a project for DI logging.
At http://dotnetdarren.wordpress.com/2010/07/29/logging-in-mvc-part-4-log4net/, Darren
provides a great article, but doesn't seem to deal with DI (at least I don't see it).
At Using Ninject to fill Log4Net Dependency,
Remo Gloor states here that the extensions should provide all that's needed for implementation, but it doesn't show the code of how to instantiate it.
The documentation for ninject.extensions.logging at https://github.com/ninject/ninject.extensions.logging/wiki/Using is very limited at best. I have re-read it many times, and still don't see how to use bind the injection in the NinjectMVC3 class, or concrete examples of how to call the logger from my controller class for example.
At the most promising article, Moosaka provides some great code at Ninject.Extensions.Logging.Log4net unexpected behavior, but when I try it, I get a compile error in the LoggerFactory at ILogger logger = new Logger(type); stating "Cannot access protected constructor 'Logger' here". Also, he states to "Tuck this whole mess away into a separate class library". Does that mean as a whole separate project?
I'm just getting lost in all the differing options and dated posts and would like any input on how to use Dependancy Injection with Ninject and Log4Net in my MVC3 project. Also, if it matters, all of my Ninject code is in my domain project, but the logging needs done from both the domain and web project (and mocked in my unit tests). Any help is appreciated.
You shouldn't have to configure anything except the normal log4net config.
All you have to do is to inject a ILogger wherever you want to log.
https://github.com/ninject/ninject.extensions.logging/wiki/Using
What is the recommended approach when an application Controller name conflicts with the name of a plugin's Controller?
I've seen these Grails JIRAs:
GRAILS-4240
GRAILS-1243
...and Burt Beckwith's replies to these two threads imply that the only recourse is to rename one of the Controllers (presumably the application Controller since hacking plugin code is not desirable)
How to use the package name to differentiate between classes in grails?
How to extend/override controller actions of plugins?
However, Burt's own spring-security-ui plugin advocates the exact approach of naming an application Controller the same as a plugin Controller - see spring-security-ui docs.
This approach actually seems to work in both development mode (grails run-app) and when the app is deployed as a WAR. So can this functionality be depended on? If so, what is the Controller conflict resolution rule? The grails docs do not make any mention of it. Perhasps Burt can share his insight?
Having a "plugin" architecture like grails' without even a basic namespacing facility to handle conflicts like this seems pretty broken to me...
The problem is that while you can use packages for any artifact, the convention for controllers is to remove the package and "Controller" to create URLs, e.g. PersonController -> /appname/person/action_name. So in effect everything gets flattened.
In 1.2 and more so in 1.3 things were changed so plugins are compiled separately from application code (and are compiled first) and this gives you the opportunity to replace a plugin artifact with the application's version. Since you shouldn't edit plugin code, this gives you the flexibility to extend or replace a plugin artifact just by using the same name.
I tend to use UrlMappings to get around stuff like this when there are two similarly named controllers. For example say you have an admin UserController that allows low-level CRUD actions and a regular UserController that users work with. I'd name the admin controller AdminUserController and map it to /admin/user/* and leave UserController as is. The admin GSPs will be in views/adminUser and the others will be in views/user so there's no conflict there. This has the added benefit of being able to easily secure - map /admin/** -> ROLE_ADMIN. The conventions are convenient, but this is a simple configuration step that solves this issue for me.
The good news is that GRAILS-1243 will definitely be implemented in 2.0 and possibly in 1.4. And the plugin that Kim Betti references in the comments of GRAILS-1243 looks interesting.