[dojo-contributors] Re: Draft: Unified 2D graphics subsystem for Dojo
ttrenka at gmail.com
Fri Jun 9 11:17:56 EDT 2006
> 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?
No, not really. The end goal here would be to write a template for a
widget in a subset of SVG and have the VML version be created, with
limitations, automatically for the developer (unless they get into
writing the VML version themselves, at which point we'd need a switch
to not use the XSL transformation). Having the dojoRect proxy is
basically what we're trying to avoid (more on this later).
> > 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.
No disagreement that we need both but hopefully we can avoid the need
to create nodes dynamically; we can't in specific situations (the
drawing collaboration tools come into mind) but at that point you're
using the API that you've proposed anyways. The only time I can see
this being a really sticky point is when you're creating dynamic nodes
during widget instantiation, and I think that can be avoided with some
clever templating. IIRC VML nodes can be operated on using standard
DOM methods as well...including cloneNode (although I think I need to
double check that).
> >> 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've also written quite a few apps using XSL; I'm thinking very
specifically here of the parsing and interpretation of string-based
attribute values that contains compound information, i.e. SVG path
element's d attribute, which describes the entire path. For this I'd
be MUCH happier dropping into script.
Yes, it takes a bit to get into the node-based thought process for
coding with XSL but the string handling functionality leaves a bit to
If it helps, I highly doubt I would use script for any kind of node or
nodelist transformation; I'm thinking very specifically of strings,
especially when it comes to casting (once again, pointing at the path
> > 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.
Ok, on the whole SVG to VML XSL concept, just to clarify...it's a
limited thing with a limited goal. The idea is to allow widget
authors try to write thier templates in one language without having to
support the other, and it has *nothing* really to do with an actual
drawing API. The end goal would be to be able to create SVG-based
widgets without having to deal (overly) with cross-browser issues in a
declarative way--which is really not the same thing that you (Eugene)
and Gavin are proposing.
For me the main end goal would be to allow this *without* having to
include your drawing API (unless the widget in question is doing
things using dynamic node creation). A good example is the Gauge
widget Torrey and I are working on; all of the nodes needed are (or
should be) already there, so there is only position and transformation
manipulation involved. For this I shouldn't need a unified drawing
API; I'll need some positioning functionality which should end up
being there underlying the drawing API anyways (think dojo.svg).
On the other hand, one should also be able to use the Drawing API
without having the XSL being loaded for IE.
The end goal of this (XSL) subproject is to make it very simple for an
author (in a limited way) to create vector-based widgets without
having to learn a new API at all. As I mentioned at DDD, Dojo already
has the capability to create a unified vector markup language--we'd
just create a widget to represent every primitive. But obviously this
would end up being very very slow, which is why the XSL approach was
I like the idea of both projects, but I would also like to keep them
as absolutely separate as possible. The only thing I'd suggest is
that the drawing API be able to take existing nodes as arguments if
needed. Let me give an example.
Say I've an SVG doc that I'm working with:
<rect dojoAttachPoint="rectNode" .../>
The result of an XSL transformation for IE would look like:
Ideally what would happen in the widget author's script is they'd
refer to each node in thier template using the attachPoint (which
translates directly to properties of the widget itself). There may be
forking necessary, and we'll try to address that as we go; it may
require the use of the drawing API, it might not, we'll see.
Now say I want to use the drawing API to manipulate widget.rectNode.
Ideally, I'd want to be able to do something like this:
...which would, instead of creating a new Rectangle node, would simply
use the existing one.
Does that make sense at all? It's the morning here and the coffee
hasn't quite kicked in yet...
More information about the dojo-contributors