By anshu mishra
via anshu-manymoods.blogspot.com
Published: Oct 14 2009 / 09:24
![]() | |
| HTML5 Canvas | |
| Written by: Simon Sarris | |
| Featured Refcardz: Top Refcardz: | |
| 150+ Refcardz Available · Get them all | |
By anshu mishra
via anshu-manymoods.blogspot.com
Published: Oct 14 2009 / 09:24
Comments
chudak replied ago:
Defeats the whole idea of dependency INJECTION and creates a leaky abstraction.
ceaseoleo replied ago:
I don't think this is correct, in spring 3.0 , you can just do @Value("name") ... something along these lines to get a property value.
anshu mishra replied ago:
I was not aware of that spring 3.0 way, by the way it is not available to be used in prod. Thanks for sharing it though.
As far as leaky abstraction is concerned it kind of depends on your choice. I am not saying you absolutely need to use it. If only to be used in middleware components, one may pass the properties as spring bean property, and then can access it. However, if you think about the need of it being accessed in your front end components (like freemarker templates), it makes easier for them not to be dependent on java coders to keep adding the accessible props for them.
chudak replied ago:
"However, if you think about the need of it being accessed in your front end components (like freemarker templates), it makes easier for them not to be dependent on java coders to keep adding the accessible props for them. "
How is programmatically accessing the properties (as described in the blog) solving this problem? Answer: it's not.
anshu mishra replied ago:
Well, you can do it like this (Didn't mention the use case in the blog, as never thought about it..there could be so many reasons to do it and not to do it this way):-
Put it in some abstract class which the other resources are extending.
model.put("getProperty", propertyConfigurer);
#Add one more helper method for the Freemarker layer
OpenPropertyPlaceholderConfigurer extends PropertyPlaceholderConfigurer implements TemplateMethodModelEx {
public Object exec(List list) throws TemplateModelException {
SimpleScalar property = (SimpleScalar)list.get(0);
try {
return getMergedProperties().getProperty(property.getAsString());
} catch (IOException e) {
throw new TemplateModelException(String.format("Error resolving requested property: %s", property), e);
}
}
}
#Access it in .ftl file
"MyVal": "${getProperty("MyProperty)}"
chudak replied ago:
Now you have your view pages pulling in runtime properties? THAT's maintainable. Why not have them just pull the data out of the database while you are at it and skip the controller altogether? Perhaps you should be PUSHING those values to the view from your controller? Like you are pushing the rest of the data that the view is displaying? If you can push the configurer to the view, why not just the property that it needs?
No matter how you try to spin it..having components pulling in values from some global 'property manager' is at odds with the goals of IOC, which is supposedly why you chose Spring in the first place.
Voters For This Link (8)
Voters Against This Link (4)