On Wed, Feb 26, 2014 at 2:52 AM, Erik de Bruin <e...@ixsoftware.nl> wrote:
> > > > > 1. I can add a file copy pass to the publish operation of the compiler > > > easily enough, but we need to discuss the best option: > > > - copy all 'non-JS and non-CSS' files, whether or not they are > actually > > > used > > > - copy only the files that belong to classes that are actually used > > > (would require strict naming convention and some compiler intelligence) > > > - pass in the files to copy as a compiler argument (that's going to > get > > > unpractical really, really quickly) > > > > > > > > As Alex mentioned, how about a goog.require for the svg file? Any chance > > we can do that for an entire directory? > > I do see that in the examples/ListsTest project, the image files are > > getting copied over into the js version. How is that working? > > > The 'build_example.xml' ant file has a copy task that specifically copies > all .png files from the src (root only) to bin-debug. I'd call that a > workaround ;-) > Ah, dint see the ant script. Makes sense now. > > Also, the SVG files are not in a particular project, they're part of the > SDK. > > As to 'goog.require', that is integral to the Closure tools, I wouldn't > want to hijack that system for fear of breaking something in the Closure > steps of publishing (now or on a future update of the tools). > Just curious, how to other apps using GCC include their assets? > > I suggest something more like this: if there are files that need to travel > with a particular class, they will be in a directory 'assets' next to the > class file, and their name(s) will begin with the name of the class, > possibly followed by a postfix. Example: class A (defined in 'src/A.js') > needs two SVG and one TXT file. The compiler would find these files because > they are in 'src/assets/' and are named A_up.svg, A_down.svg and > A_whatever.txt. > This works for me. I can make this change right away. > > > > > > 2. I have built a primitive event passing mechanism with my SVG > skins. > > > > I > > > > would like some suggestions on how to wire it up with FlexJS's event > > > > model. > > > > Where is the code that attaches event handlers to buttons? Any > chance > > I > > > > can get a handle to this event handler function inside TextButton.js? > > I > > > > need this because I want to inject it as into the SVG skin. > > > > > > > > Background: When using an SVG in an embed directive, the SVG > document > > > eats > > > > all the mouse events. So, I am passing event handlers into the SVG > > > > document (from the parent) which can then be called from within the > > > > document itself. > > > > > > > > Ok, this is going to be 'interesting'. The MXML representation - the > 'click' attribute - is compiled into debug JS as a randomly named public > method (e.g. $EH2). Other than sequence, there remains no way I can see > that will allow the SVG to 'fish' for a specific JS handler method based on > only the knowledge of the original MXML. > Yes, I do see the $EHx function names listed on the JS version. Where do they get attached to the mouse events of the components? > > One possible solution might be to drop the 'random' naming convention and > start using a more predictable one. I can see how - for MXML nodes with an > 'id' property - create event handlers with names that follow a template > like: '[id]_[attribute]'. That would translate to 'mySVGComp_click', > instead of '$EH1'. Then the SVG code can look in the parent for a method > with a name that fits it's template... I don't know SVG, so I can't tell if > that would even be possible on the SVG side. > The SVG document can call a javascript function on its parent document by calling parent.functionName() or top.functionName() What is also possible is that the SVG document can inspect the attributes of its parent node (Embed, in this case). What I want to do is add attributes like "onclick", "onmouseover", etc. and read it from within the SVG document. Then I am wiring up the local events within SVG and calling the parent's event handlers as callbacks. You can see it here [1] and [2] In essence, there is no need for the SVG document to know anything about the names of events, etc. The containing JS file (TextButton.js) should somehow figure out the event handlers and inject them into the SVG document. [1] view-source:http://people.apache.org/~bigosmallm/fxg2svg/buttonskinjs/embedButtons.html [2] view-source:http://people.apache.org/~bigosmallm/fxg2svg/buttonskinjs/buttonSkin.svg > > > > EdB > > > > -- > Ix Multimedia Software > > Jan Luykenstraat 27 > 3521 VB Utrecht > > T. 06-51952295 > I. www.ixsoftware.nl >
