[dojo-contributors] Re: Draft: Unified 2D graphics subsystem for Dojo

Tom Trenka ttrenka at gmail.com
Thu Jun 8 10:07:03 EDT 2006

> > There is a problem with "something manipulatable". I think it is
> > possible to preserve a node name during the transformation, but it
> > doesn't do a lot of good for manipulation purposes because VML and SVG
> > handle it differently.
> I would assume that if we instantiate a "dojoRectangle" from a node, be it
> svg, vml, or a div, that the dojoRectangle implementation on that browser
> would be specific in its implementation (though generic in its interface).

There would definitely need to be something "dojoified" in terms of
cross-platform manipulation, but VML is actually slightly easier in
this respect, because most of the positioning aspects are done via
CSS.  But yes, there will definitely be a need for the widget author
to take into account *how* the translation is done, and be pretty
careful about the way they try to manipulate the object model.  It
will be much more likely that you will need to use Dojo attach points
than to try to access nodes via the DOM, for instance...

> > It may be even more hairy to change graphical attributes or apply a
> > transformation because it may involve adding more nodes or even changing
> > the hierarchy of existing nodes, e.g., putting them under a parent to
> > facilitate some group changes.
> My initial attempts suggest that using the native group transforms is
> often *not* the way to go. For example, if you group several SVG shapes
> together and scale them up, the stroke weight is scaled also, often
> unevenly. You can see this behavior in my drawing editor prototype. I had
> to do some silly "re-apply the group xform to the elements inside the
> group" when ungrouping them as well.

Yes, this is a definite issue and one we'll have to address at some
point. My personal preference would be to allow both but then...

> >> Already have the paper and have digested a number of things from it,
> >> thanks.  The main thing I'm looking at is the need to include script
> >> in the transformation process; I don't think I can load it on the fly
> >> though, which means there's probably be some duplication of JS stuff
> >> :(   I may see if I can figure out a way of loading that code, but
> >> we'll see.
> Yeah, I didn't get that either. Possibly was using jscript to emulate SVG
> features not in VML?? I also emailed the Italian guy who was doing the VML
> translator XSLT but haven't heard back yet.

The MSXML parser allows you to include script (either the JScript or
the VBScript engine) directly in a stylesheet and call it, as a way of
extending the functionality of XPath.  Since the string parsing
functionality in XPath is *horrible* (did I mention it's HORRIBLE?) my
initial instinct is to include a bit of script to help that along
(translating an SVG Path to a VML path comes to mind here, I can do
that much cleaner and faster in script than with XPath manipulation).

The problem though is that you can't include an external script that
isn't defined with an XML Namespace outside of an XSL block.  The
other thing to keep in mind is that including script in XSL under MS
forces a new script engine instance.  Most of the time the performance
isn't that bad (you can't really notice it) but it does mean cross-app
comm won't happen.

I included that information because I wanted to pre-empt the idea that
we could create a hostenv stub with Dojo for XSL, which (in my mind)
would be the next logical step if one could include JS within
XSL...sorry for the confusion about that.


More information about the dojo-contributors mailing list