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

Eugene Lazutkin eugene at lazutkin.com
Thu Jun 8 23:08:55 EDT 2006

Tom Trenka wrote:
>> 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

It looks like it means a set of universal proxies, which will operate on 
actual objects, while exposing a unified API. For example, I already 
have an SVG/VML drawing, and I instantiate a dojoRect proxy on an attach 
point. Is this a correct scenario?

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

You have to use DOM in some form or fashion, if you want to create nodes 
dynamically. I think we need both.

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

I am for "both" unless we have some major technical issues. I know about 
unfortunate scaling of line width, but sometimes it can be useful. It 
should be up to a widget author to use a group, or a helper, which can 
change transformation for a group of objects.

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

Funny, but I had no problems with XPath. Yes, it does force the unusual 
programming style. I actually wrote some applications completely in XSL 
without any help from scripts and performance was very good. Then again 
I didn't try MS extensions --- I cannot say whether they work better.

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

I can try to do SVG => VML translation using pure XSLT, when we decide 
on what SVG constructs we want to support, and what to do about attach 
points. If it turns out to be deficient, we can do MS-specific hacks 
augmenting XSL with JS.



More information about the dojo-contributors mailing list