>
> > 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 ;-)

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).

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.


> > > 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.

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.


> EdB



-- 
Ix Multimedia Software

Jan Luykenstraat 27
3521 VB Utrecht

T. 06-51952295
I. www.ixsoftware.nl

Reply via email to