I'm developing a project using Play and I'm confused about Application class. I see it in many code snippets, for example:
class Application(silhouette: Silhouette[DefaultEnv]) extends Controller
(source)
But I don't get if it's an arbitrary name for a generic controller (used instead of FooController, MyController...) or if it has a special meaning and it gets handled by the framework in a special way.
To add further confusion, I realized that there is also the Application interface (source) and the concrete implementation is DefaultApplication (source) and documentation says:
Application creation is handled by the framework engine.
so... what is the meaning of having an Application controller?
This is just an arbitrary, generic name as its example. Imagine you are writing a documentation. As an example controller name, you maybe name it as Application, ApplicationController, MyApp, MyAppController or MainController etc.
But DefaultApplication you found on play documentation has meaning.
It is a default implementation of play.Application interface (in scala, play.api.Application trait) that maneges the play application environment and state etc.
https://www.playframework.com/documentation/2.7.x/JavaApplication
https://www.playframework.com/documentation/2.7.x/ScalaApplication
As long as you place controllers under controllers namespace, you can name your controllers whatever you want such as "Application".
By the way, default controller from official play template was named as Application previously. I guess this is a reason why you see many controller code snippets named Application.
https://github.com/typesafehub/activator-hello-play-scala/blob/master/app/controllers/Application.scala
Related
I'd like to use a Cakephp 3 component inside a class located in, for example, /src/Classes/Customers.php.
I don't know how to instanciate the compoent.
You are not supposed to do that, components are services for the controller layer, and that's where the story ends. It is strongly advised that you do not use framework components outside of their intended purpose, this will just cause trouble at some point!
If you want to share logic between components and other utilities unrelated to controllers, then you should put that logic into for example generic service classes that both your components as well as your other code can utilize.
I'm thinking about a platform-neutral (i.e. not .NET MEF) technique of implementing chain-of-responsibliity pattern using web services as the handlers. I want to be able to add more CoR handlers by deploying new services and not compiling new CoR code, just change configuration info. It seems the challenge will be managing the metadata about available handlers and ensuring the handlers are conforming to the interface.
My question: any ideas on how I can safely ensure:
1. The web services are implementing the interface
2. The web services are implementing the base class behavior, like calling the successor
Because, in compiled code, I can have type-safety and therefore know that any handlers have derived from the abstract base class that ensures the interface and behavior I want. That seems to be missing in the world of services.
This seems like a valid question, but a rather simple one.
You are still afforded the protection of the typing system, even if you are loading code later, at runtime, that the original code never saw before.
I would think the preferred approach here would be to have something like a properties file with a list of implementers (your chain). Then in the code, you are going to have to have a way to instantiate an instance of each handler at runtime to construct the chain. When you construct the instance, you will have to check its type. In Java, for instance, that would take the form of instanceof (abomination ordinarily, but you get a pass for loading scenarios), or isAssignableFrom. In Objective C, it's conformsToProtocol.
If it doesn't, it can't be used and you can spit an error out to the console.
I have several classes that exist persistently throughout application lifetime and can contain any code a programmer might need to run (stuff like for example that is executed when a user resizes the app window). These classes are basically empty templates and aren't for a single task (uh oh, sounds like bad OOP, but please stay with me here). There are several of these classes in my framework and which one is integrated into the rest of the framework depends on the build target (web, desktop, mobile, etc). Currently these classes are named:
AppModule
AppDesktopModule
AppAndroidModule
etc.
But I'm not happy with this naming. I'd like to give them a name that somehow clarifies that these classes are persistent throughout app lifetime. Does anyone have ideas for a better naming?
I recently read about Dynamic Creation as one of the design pattern in Cocoa. However, I don't really understand how it works. So I need clarification from you who have implemented in your design.
What is it? Why and when would you use this design pattern?
I have read that you use NSClassFromString() to access the class. I assume that I use this when I want to use class that doesn't exist within the project I'm working on. Usually when I want to use certain class, I imported them in header. Does using this approach skip the #import process?
Class JavaArrayList = NSClassFromString(#"java.util.ArrayList");
I quote the code above as example. If do according to the code above, that means I can create a new JavaArrayList class and use the methods in it right?
JavaArrayList *foo = [[JavaArrayList alloc] init];
[foo useMethodBelongJava:doWhateverTask];
What are the benefits of using this design pattern? Especially in iPhone Development.
Your example appears to be using that pattern to instantiate a Java class. In the old days (up to about MacOS 10.4 I think), Apple had some technology called the Cocoa-Java Bridge, which let you use Java classes within Objective-C code. You had to instantiate them in the manner specified, because they didn't have Objective-C header files to import.
However, as of Snow Leopard, the Java Bridge no longer exists, so the code in your question won't work any more.
The recommended solution for calling a Java class from Objective-C is now JNI. Take a look at this question if that is what you're trying to do.
What is it? Why and when would you use this design pattern?
Coming back to NSClassFromString, it has other uses besides instantiating Java classes (which, as I mentioned, it doesn't do any more!). For an example, recently I wrote a library for parsing the response from a web service. In order to make it work with different web services, I had it read in a configuration file that described the data format it was expecting. For each field in the web service, my configuration file specified which Cocoa class to instantiate. Thus, in my code, I had a Cocoa class name as a string. To instantiate the object I wanted, I used NSClassFromString to turn it into a Class object.
Usually when I want to use certain class, I imported them in header. Does using this approach skip the #import process?
It can do. NSClassFromString will instantiate any class that is present at run time, so you don't need the header to be able to use it. If you don't have the header, you'll get a bunch of warnings of "may not respond to selector" whenever you try and use your newly instantiated class, as the compiler doesn't have enough information to be helpful. However, in many circumstances where NSClassFromString is useful, the header files aren't available.
See this link:
need advise about NSClassFromString
The only real benefit for iPhone was being able to reference classes from newer APIs and still target the old APIs. Since 4.0 you can do this anyway by setting the deployment target of your project. I can't really see any reason you would use it for iPhone programming any more.
This would only work for objective-C classes. You can't import java objects into your iphone app.
What I am trying to do is inject a component into my MVC app and make use of it from the controllers.
Currently I am not trying to use MEF for the actual controllers, but i want to import components e.g. A loggin component into the MVC app.
Where is the best place to do this?
Currently I have, directly in the controller, put my compose parts code and ILogger property, but I get the feeling this is not the best way. Seems like I should only need to call Compose once in the application.
So should it be in the global asax file that I do the compose?
If so, how do I get a handle on ILogger from my controllers? Should I have a "base" controller, where i inject ILogger into the constructor and inherit every standard controller from?
Hope that makes sense - I'm just struggling a bit with the structure of my code.
Thx
I use Log4Net and inject the logger into each controller. I dont think its a big hit when you use injection. Take a look at Ninject. It has both an MVC implementation and a logging module. The modules are loaded once in the global, then it injects the controllers. Basic DI, but do you really need more? If you create a base controller you will still have to create a ctor in each controller that can be injected.
You might create a base controller with the logging, then use property injection. I have never done this, but if all controllers use the same base it should work fine.