On Tue, Apr 9, 2013 at 10:18 PM, Alex Harui <aha...@adobe.com> wrote:
> Good progress. I didn't look at your implementation, but some comments > inline. > > > On 4/9/13 7:40 PM, "OmPrakash Muppirala" <bigosma...@gmail.com> wrote: > > > Hi, > > > > Here is some more experimental work based on FXG to SVG transformation. > > > > > http://people.apache.org/~bigosmallm/fxg2svg/buttonskinjs/embedButtons.html > > > > This time, all the skin states are in one .svg file along with the JS: > > > > http://people.apache.org/~bigosmallm/fxg2svg/buttonskinjs/buttonSkin.svg > > > > Notes: > > > > * My earlier approach of using each .svg file as a background of each > > button state has a major problem - it is not runtime scriptable because > of > > security restrictions. > If you don't need runtime scriptability, is separate svg files a better > solution? Maybe we need to support both? Especially because a quick > search > of "how-to" seemed to find the separate svg file approach. > I dont think separate svg files are better for any situation. For example, when we use css and pseudo selectors, we are limited by the selectors themselves. If we need custom states, it is better if we have all states in one .svg file and use JavaScript to switch states. Moreover, in the separate svg files approach, the svg for a state is loaded only when that state is triggered, which causes an obvious flicker when loading for the first time. I am thinking that inert graphics (like backgrounds for panels, etc) can be skinned using a single svg with no JS. Anything that is interactive is better off with a single svg with JS scripting. > > * In this version, I am using the <embed> tag with the src attribute > > pointing to the .svg skin. > > * Inside the SVG, the states are being managed using JavaScript > Do the states get tied to CSS pseudo-states or something else. If we do > have to support two mechanisms (embedded js states and separate svg files > with css, is there a higher level abstraction that can encapsulate both? > In this approach, it is not tied to css states. We could do that, but as I mentioned, it limits us from doing custom states. > > * The button's label and click callback function is injected into the SVG > > file via the embed tag's attributes. > Why is the callback for click part of the "view"? > Because the embedded SVG eats all the mouse events. The approach I have taken seems to be the only way to add interactivity to a component created in this fashion. I did quite a bit of research on this. I will be glad to be proven wrong. I tried bubbling events, but it seems like the browsers create a new document context when rendering embedded SVG. There are other approaches we could try like positioning a transparent div on top of each button, but I am not sure which approach is worse. What do you think? > > * Inside the SVG, the onInit() function reads the > > window.frameElement.attributes properties to read and set the required > > variables > > * Chrome and Firefox restrict accessing window.frameElement when working > on > > the filesystem (cross domain scripting security precaution) But it works > > fine when running from a server. I will figure out a way around this for > > development ease soon. > Try launching chrome with these additional command-line parameters: > --allow-file-access-from-files --disable-web-security > > * Communication from SVG to the parent HTML is done via calling > > top[injectedCallbackFunctionName](); > What kind of communication is required? I would hope that most "skins" > don't have events or other output. > Mainly event handlers which I want to inject into the skin. Otherwise, there should be no communication from the skin to the containing component or document. > > -- > Alex Harui > Flex SDK Team > Adobe Systems, Inc. > http://blogs.adobe.com/aharui > >
