I would like to implement a single data respository that is available to many of my view elements. My first idea was to simply create a plain JS object and add it to the global namespace (optionally adding a custom namespace).
But then I would loose the possibility to easily import elements like, f.e., iron-ajax. So I thought it would be better to define the repository as a Polymer element.
Now the question is whether the views should access the singleton via the global instance or should I have a wrapper element that the views would instantiate declaratively which itself is a facade to the global instance. In both cases it is not fully clear to me how to instantiate the global instance (document.createElement maybe?)
My data repository will provide methods like getData, getDevices etc. that should be accessible by all views. Some of these methods will cache static data others will have parameters and load different data with every call.
Is there any recommended pattern to this?
Related
Using Om, it seems like passing relevant parts of the app state to child components is effectively the same thing as not passing any app state but using ref-cursors. What is the use case for ref-cursors over passing pieces of the app state down the chain?
I've read through all three of the tutorials and conceptual overview on the Om github repository but I cant really find an answer to this question. It seems like one could use either one or the other and accomplish the same thing (one either defines a component with (defn blah [_ owner] ...) and uses ref cursors or defines a component with (defn blah [relevent-state owner] ...)
Can someone clarify when I would want to use a ref cursor inside a component as opposed to simply passing part of the app state into that component?
This question is pretty old, but I'll give it a shot.
I believe the main use-case for ref-cursors is to promote modularity and decoupling of the global application state from components. It limits the scope of components to just the data that they depend on, and nothing else.
Normally, you'd pass application state and any change callbacks down the component tree via props, as you say. A consequence is that the component hierarchy becomes tightly coupled with the "shape" of the application state. The components hierarchy will have to match the state 1:1, or else many components will receive big blobs of data and callbacks that only a few subcomponents depend on, which they themselves may never actually use -i.e you might find yourself passing down parts of the global state down the component chain just so that components further down can have access to it. These components are being used as a channel for passing down state, which is not ideal because it exposes them to application state that they have no business knowing about. You run the risk of coupling and lose modularity.
With cursors, component dependencies are explicitly specified by each component upon mounting. The cursors are a black box into the application state -the component itself never has to know where inside the application it is situated. You have the full flexibility of stating a component's dependencies from anywhere in the application state without having to worry about all the transient data being passed around. You get one-way data flow without having to pass update callbacks down arbitrarily deep hierarchies. The end result is excellent component compartmentalization and modularity. As a bonus, you now have a single point into the application state that you can observe for changes!
I used it because when you update it, all of the observers get called.
I'm confused as to the proper use of core-meta in polymer. I tried looking at Topeka's metadata.html but it seems to cloud the issue for me further, with its extensive usage of x-meta tags seemingly related specifically to polymer designer tool etc. (I'm not using polymer designer)
Basically, I'm simply looking to create a config-file of sorts for my polymer application. For instance, I'd like to set the application's API data source URL (or at least the base URL) in one place and have any of the various elements reference it as required. Would that approach be considered best practice in polymer applications? In other words, should one use a separate metadata.html containing core-meta tags to accomplish the aforementioned goal for an application? If so, I'd like to see a brief example if possible. Thanks!
core-meta is a generic element you can use for sharing information across the DOM tree. It uses monostate pattern such that any instance of core-meta has access to the shared information. You can use core-meta to share whatever you want (or create an extension [like x-meta] for enhancements).
The core-meta instances containing your actual data can be loaded in an import, or constructed in any way you see fit. The only requirement is that you create them before you try to access them.
Examples:
If I create an instance like this:
<core-meta id="info" keyUrl="foo/bar"></core-meta>
Note that keyUrl="foo/bar"is the metadata I've defined. I could define more attributes or use child nodes to define additional metadata.
Now I can access that element (and it's metadata) from any core-meta instance via the myId method, e.g.
meta.byId('info').getAttribute('keyUrl').
Pure imperative form would be like:
document.createElement('core-meta').byId('info').getAttribute('keyUrl');
Or, in a Polymer element, you can include a meta in your template:
<core-meta id="meta"></core-meta>
...
this.$.meta.byId('info').getAttribute('keyUrl');
You could sugar the byId('info').getAttribute('keyUrl') expression any number of ways to make access more convenient depending on your use case.
Live code: http://jsbin.com/vipoyi/1/edit
I'd like to be able to register some types on a container and then top these up with some additional type declared in an XML configuration file. Unfortunately, IConfigurationInterpreter (implemented by XmlInterpreter) is only available in the WindsorContainer() constructor, not in any AddXXX() methods. Is there any other way I can achieve this without resorting to parent/child containers (that may soon be unsupported).
Background: Our large application is only starting to use the Castle framework to register and resolve some of it's components. Because Castle is being retrofitted into this app we're using a singleton class to maintain a global instance of WindsorContainer(). In unit tests, we need to wire up this container instance to use a combination of custom mock implementations (specific to the test) + some default mock implementations. For DLL dependency reasons, these mock class types are unavailable in this unit test fixture abstract base class so dynamic registration (using strings) is necessary. I was hoping to use an XML resource file to register the default mocks. Otherwise I have to do the same using an IWindsorInstaller implementation that's really duplicating what XmlInterpreter does. This API appears to be forcing this direction.
I think these will work ...
container.Install(Castle.Windsor.Installer.Configuration.FromXml(resource))
OR
container.Install(Castle.Windsor.Installer.Configuration.FromXmlFile(path))
which both avoid use of the IConfigurationInterpreter interface.
How would I create a strongly typed class at runtime (so to be able to create instances of it)? It can't be a proxy.
Additional Info:
For example, say I want to create a Person class with first and last where both are Strings.
Context
This is for an application that lets you create the data model and custom components at runtime. This is only part of it. I need to be able to have strong typing. If that means going to the server and creating a new SWF on the server with the value objects then loading in the definition at runtime then I would but that is a lot more work if there is an alternative.
AS3Commons-Bytecode lets you generate classes at runtime: http://www.as3commons.org/as3-commons-bytecode/emit.html
In all my projects till now, I use to use singleton pattern to access Application configuration throughout the application. Lately I see lot of articles taking about not to use singleton pattern , because this pattern does not promote of testability also it hides the Component dependency.
My question is what is the best way to store Application configuration, which is easily accessible throughout the application without passing the configuration object all over the application ?.
Thanks in Advance
Madhu
I think an application configuration is an excellent use of the Singleton pattern. I tend to use it myself to prevent having to reread the configuration each time I want to access it and because I like to have the configuration be strongly typed (i.e, not have to convert non-string values each time). I usually build in some backdoor methods to my Singleton to support testability -- i.e., the ability to inject an XML configuration so I can set it in my test and the ability to destroy the Singleton so that it gets recreated when needed. Typically these are private methods that I access via reflection so that they are hidden from the public interface.
EDIT We live and learn. While I think application configuration is one of the few places to use a Singleton, I don't do this any more. Typically, now, I will create an interface and a standard class implementation using static, Lazy<T> backing fields for the configuration properties. This allows me to have the "initialize once" behavior for each property with a better design for testability.
Use dependency injection to inject the single configuration object into any classes that need it. This way you can use a mock configuration for testing or whatever you want... you're not explicitly going out and getting something that needs to be initialized with configuration files. With dependency injection, you are not passing the object around either.
For that specific situation I would create one configuration object and pass it around to those who need it.
Since it is the configuration it should be used only in certain parts of the app and not necessarily should be Omnipresent.
However if you haven't had problems using them, and don't want to test it that hard, you should keep going as you did until today.
Read the discussion about why are they considered harmful. I think most of the problems come when a lot of resources are being held by the singleton.
For the app configuration I think it would be safe to keep it like it is.
The singleton pattern seems to be the way to go. Here's a Setting class that I wrote that works well for me.
If any component relies on configuration that can be changed at runtime (for example theme support for widgets), you need to provide some callback or signaling mechanism to notify about the changed config. That's why it is not enough to pass only the needed parameters to the component at creation time (like color).
You also need to provide access to the config from inside of the component (pass complete config to component), or make a component factory that stores references to the config and all its created components so it can eventually apply the changes.
The former has the big downside that it clutters the constructors or blows up the interface, though it is maybe fastest for prototyping. If you take the "Law of Demeter" into account this is a big no because it violates encapsulation.
The latter has the advantage that components keep their specific interface where components only take what they need, and as a bonus gives you a central place for refactoring (the factory). In the long run code maintenance will likely benefit from the factory pattern.
Also, even if the factory was a singleton, it would likely be used in far fewer places than a configuration singleton would have been.
Here is an example done using Castale.Core >> DictionaryAdapter and StructureMap