> The data model for a score contains one or more StaffComponents which in turn > each reference a StaffComponentModel object that wraps a [collection] which > contains Chord objects which also have a [collection] which contains Note > objects. Having the ability to declare the object graph for a whole score or > just a staff in BXML is important and it also looks like what type of Pivot > collection to use in place of the generic placeholder [collection] used by > the StaffComponentModel and Chord objects is important for binding.
You'll most likely want to use a "read-only sequence". The WTKX Primer section of the tutorial talks about this - I'm currently in the process of updating it to cover BXML, but many of the concepts still apply in the earlier version. > What I am thinking of is having a StaffComponent, StaffComponentModel (also > known as a Part in music) and StaffComponentSkin. There is only one type of > StaffComponent that is created for each score staff desired. A StaffComponent > will then reference one of the StaffComponentModel instances that are stored > in a separate map outside of the score. A StaffComponent will also have a > StaffComponentSkin which will be able to layout and paint the music data in > the StaffComponentModel referenced by a StaffComponent in any possible way. Makes sense. > The StaffComponentSkin should be able to dynamically load JSON resource files > to provide user/style properties (to load into it dictionaries) which will be > recipes for different notation types (there are many types of proposed > notations besides the standard notation we all know). Is it possible to use > the same resource file mechanism that localization does for this? Yes, you could certainly do that. But it might be more consistent with Pivot design to define "styles" in your skin class that allow the caller to customize its appearance/behavior. Styles are simply bean properties defined by your skin class. They can be accessed by the Component's style dictionary and set either programmatically in code or declaratively in BXML (using either JSON or XML). > is it possible to dynamically load/store notation resource files for a > StaffComponentSkin so the LNF for a staff can be changed at any time and be > completely pluggable (as in PLNF)? Pivot doesn't support runtime replacement of the entire L&F like Swing does. However, you can dynamically change styles at runtime, which may be sufficient. If you find that providing multiple skins makes development easier, you could simply re-instantiate the component using a specific skin and re-attach it to your model. This would allow you to swap out the L&F for an individual component, at least. > There are also Renderer objects and Decorator objects to consider as > extensions to the StaffComponentSkin. With the StaffComponentSkin responsible > for the layout and painting of the data in the staff's StaffComponentModel > how would Renderer and Decorator objects be best utilized? Components represent the "controller" in Pivot's MVC implementation, and skins represent the "view". A skin defines the overall L&F of a component, but it doesn't define how the component's content is painted. That's where renderers come in. However, based on my understanding of your app's requirements, I'm not sure you would need to support a renderer (not all skins do). Decorators are used to augment a component's default paint behavior. They allow a caller to hook into the paint process before and after a component is painted. Skins often take advantage of them, but they don't necessarily have to. In other words, there's no need to use a decorator if you can implement the behavior you need within the skin's paint() method. G
