i'm using play framework 2.1 and i got a strange error.
I'm trying to move controllers in subfolders, es:
controllers->
- Application.java
- pages ->
- - - -Index.java
- - - -Second.java
and in routes i have:
GET / controllers.pages.Index.main();
error:
value main is not a member of object controllers.pages.Index
It's a bug? regards Nicola
SOLVED
bug found: you cannot access to methods of parent class, you have to override them:
public static Result main(String page, String method)
{
return ParentClass.main(page,method);
}
I don't think it was fixed in final Play 2.1 (or I missed something) - the route to method which is not 'overriden' in child class still returns error.
AFAIK in Java real overriding of static methods isn't possible at all.
Anyway... remember that all actions by design are a static methods so, you don't need to use the route to Child.methodOfParent() while you can just use Parent.methodOfParent(), something you are showing as a solution should be rather considered as overloading instead of overriding.
On the other hand, from my point of view I'd rather suggest to do not use this pattern at all. Play's actions should be separate methods which does its job independently from other actions, and if you need to use the (almost) same functionality in both actions probably it would be better concept to use other static method (not an action) ie. in new utils package to process body of both actions with params. IMHO it will be just safer approach, as you can see - there are still some 'unknowns'.
Related
In my application that uses Typhoon library, I've created an AppAssembly that is being initialized in SceneDelegate like this:
self.appAssembly = [[AppAssembly new] activated];
my appAssembly looks like this
- (Person *)me;
- (Dog *)dog;
- (Cookie *)cookie;
- (DogInteractionVC *)dogVC;
- (HowManyCookiesVC *)howManyCookiesVC;
From SceneDelegate I want to transit to dogVC,
Then, from the dogVC, I want to transit to howManyCookiesVC
Calling the instance of dogVC from SceneDelegate is quite easy as I do have an access to it:
self.viewController = [self.appAssembly dogVC];
I do not understand how to pass the very same appAssembly instance to a dogVC and then to howManyCookiesVC. When I try to create an instance of AppAssembly in the dogVC, I come across the issue that I believe is called circular dependency.
There is a guide on GitHub about injecting Assembly itself. So I created a property appAssembly in a dogVC of type TyphoonComponentFactory. Here is how my initializing method inside my appAssembly for a dogVC looks like:
- (DogInteractionVC *)dogVC {
return [TyphoonDefinition withClass:[DogInteractionVC class]
configuration:^(TyphoonDefinition *definition) {
[definition useInitializer:#selector(initWithPerson:)
parameters:^(TyphoonMethod *initializer) {
[initializer injectParameterWith:[self me]];
}];
[definition injectProperty:#selector(appAssembly) with:self];
}];
}
I think the part injectProperty:#selector(appAssembly) is wrong, but I spent a long time understanding that, and I am afraid that I cannot go any further than this without some help from the community. Any help is appreciated. Thank you.
Side note:
Dear community, I am very close to being blocked from posting, as my last posts have not been well received. I believe that question has everything that it needs. If I am wrong, please let me know before putting your thumbs down so I can understand my mistakes. Thank you.
Dependency Injection:
Typhoon helps to apply the dependency injection pattern - an object oriented software approach whereby:
The key actors and their interactions with other core software components in a system a declared at the composition root.
In this way:
We can de-duplicate configuration of shared objects.
We can have the benefits of singletons without overly tight coupling.
Using Dependency Injection in a Mobile App:
When we use dependency injection in a mobile app, we start at the app delegate to launch a view controller.
The first controller will depend on some singleton services to do its job.
We may then wish to transition from one view controller to another. We can load an 'object graph' consisting of the view controller and it dependencies.
When the next controller is presented, we can release the current one.
Factory Pattern:
To transition from one controller to another we can use Typhoon as a factory for emitting built instances. The factory pattern allows us to:
Obtain an instance (ie a view controller) with a mix of runtime and static dependencies.
So to transition from one view controller to another we can inject Typhoon assembly to be used as a factory to obtain the next view controller. To inject the assembly as a factory, docs are here.
Scopes:
Depending on navigation style, controllers will typically retained in memory as long as used and then released. Meanwhile services or other shared infrastructure will be shared.
The default scope is TyphoonScopeObjectGraph
To create a shared class use definition.scope = TyphoonScopeSingleton as documented here.
Pilgrim:
Typhoon is, at least in my opinion, the best and most flexible DI library for objective-C. Meanwhile, if you use Swift you might like to try simpler and better: pilgrim.ph
When using m.module, I often would like to provide arguments to the controller constructor so that the first rendering starts with the right data. However, the Mithril documentation and examples always show module.controller() and module.vm.init() without parameters.
To go around this issue and have module.controller(initData) I've resorted to use this small utility function to wrap and extend the existing m.Module:
var mModule = function (dom, mod, arg) {
return m.module(dom, {
view: mod.view,
controller: mod.controller.bind(mod.controller,arg)
});
};
Questions:
Is this an anti-pattern? Is there an alternate recommended way instantiate the module with custom external data?
Would this cause issues with m.route? I saw some mentions of recursive calls in the source code but could not get my head around it.
Following the 2 points above, is the lack of parameter for m.module a deliberate design choice?
Oh...and thanks to all involved for the existing documentation and discussions.
No, it's not an anti-pattern, and it's an idea that is explored in one of the blog articles, and also by Moria (a router extension library for Mithril)
I am using Ninject in substitution of MEF and I was wondering if it's possible to get lazy instances via standard kernel methods and not via [inject] .
I need this since when building up my application's menu I have to pass all particular view models and then if the user is enabled on that function to add it to the menu
Thanks
Sure thing, you can inject a Lazy<T> and the value will only be instanciated when you access Lazy<T>.Value.
You can also inject a Func<T> and use it to create T whenever you like (with the func, every call creates a new instance).
Of course you can also do IResolutionRoot.Get<Lazy<T>>() or IResolutionRoot.Get<Func<T>>(), but usually that's a sign of bad design (service locator), so use constructor injection when it's feasible.
EDIT: When is the "enabling of the user" happening? Is it a one time thing? What is being displayed before and after?
There might be other/better designs to achieve this but it's hard to say with that little information.
Let's say I have a few controllers. Each controller can at some point create new objects which will need to be stored on the server. For example I can have a RecipeCreationViewController which manages a form. When this form is submitted, a new Recipe object is created and needs to be saved on the server.
What's the best way to design the classes to minimize complexity and coupling while keeping the code as clean and readable as possible?
Singleton
Normally I would create a singleton NetworkAdapter that each controller can access directly in order to save objects.
Example:
[[[NetworkAdapter] sharedAdapter] saveObject:myRecipe];
But I've realized that having classes call singletons on their own makes for coupled code which is hard to debug since the access to the singleton is hidden in the implementation and not obvious from the interface.
Direct Reference
The alternative is to have each controller hold a reference to the NetworkAdapter and have this be passed in by the class that creates the controller.
For example:
[self.networkAdapter saveObject:myRecipe];
Delegation
The other approach that came to mind is delegation. The NetworkAdapter can implement a "RemoteStorageDelegate" protocol and each controller can have a remoteStorageDelegate which it can call methods like saveObject: on. The advantage being that the controllers don't know about the details of a NetworkAdapter, only that the object that implements the protocol knows how to save objects.
For example:
[self.remoteStorageDelegate saveObject:myRecipe];
Direct in Model
Yet another approach would be to have the model handle saving to the network directly. I'm not sure if this is a good idea though.
For example:
[myRecipe save];
What do you think of these? Are there any other patterns that make more sense for this?
I would also stick with Dependency Injection in your case. If you want to read about that you will easily find good articles in the web, e.g. on Wikipedia. There are also links to DI frameworks in Objective C.
Basically, you can use DI if you have two or more components, which must interact but shouldn't know each other directly in code. I'll elaborate your example a bit, but in C#/Java style because I don't know Objective C syntax. Let's say you have
class NetworkAdapter implements NetworkAdapterInterface {
void save(object o) { ... }
}
with the interface
interface NetworkAdapterInterface {
void save(object o);
}
Now you want to call that adapter in a controller like
class Controller {
NetworkAdapterInterface networkAdapter;
Controller() {
}
void setAdapter(NetworkAdapterInterface adapter) {
this.networkAdapter = adapter;
}
void work() {
this.networkAdapter.save(new object());
}
}
Calling the Setter is where now the magic of DI can happen (called Setter Injection; there is also e.g. Constructor Injection). That means that you haven't a single code line where you call the Setter yourself, but let it do the DI framework. Very loose coupled!
Now how does it work? Typically with a common DI framework you can define the actual mappings between components in a central code place or in a XML file. Image you have
<DI>
<component="NetworkAdapterInterface" class="NetworkAdapter" lifecycle="singleton" />
</DI>
This could tell the DI framework to automatically inject a NetworkAdapter in every Setter for NetworkAdapterInterface it finds in your code. In order to do this, it will create the proper object for you first. If it builds a new object for every injection, or only one object for all injections (Singleton), or e.g. one object per Unit of Work (if you use such a pattern), can be configured for each type.
As a sidenote: If you are unit testing your code, you can also use the DI framework to define completely other bindings, suitable for your test szenario. Easy way to inject some mocks!
I have a Struts 1 application which works with Velocity as a template language. I shall replace Velocity with Freemarker, and am looking for something similar to 'toolbox.xml'-File from VelocityViewServlet. (there you can map names to Java Classes and, using these names it is possible to access methods and variables of various Java class in the Velocity template).
Does someone know, what is possible with Freemarker instead? So far I have found only information about the form beans...would be glad if someone can help....
For the utility functions and macros that are View-related (not Model-related), the standard practice is to implement them in FreeMarker and put them into one or more templates and #import (or #include) them. It's also possible to pull in TemplateDirectiveModel-s and TemplateMethodModelEx-es (these are similar to macros and function, but they are implemented in Java) into the template that you will #import/#inlcude as <#assign foo = 'com.example.Foo'?new()>.
As of calling plain static Java methods, you may use the ObjectWrapper's getStaticModels() (assuming it's a BeansWrapper subclass) and then get the required methods as TemplateMethodModelEx-es with staticModels.get("com.example.MyStatics"). Now that you have them, you can put them into the data-model (Velocity context) in the Controller, or pick methods from them in an #import-ed template, etc. Of course, you can also put POJO objects into the data-model so you can call their non-static methods.
The third method, which is not much different from putting things into the data-model is using "shared variables", which are variables (possibly including TemplateMethodModelEx-es and TemplateDirectiveModel-s) defined on the Configuration level.