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

Tom Trenka ttrenka at gmail.com
Fri Jun 9 11:25:48 EDT 2006


BTW, as I'm thinking about it, I think that what is now dojo.svg
should be refactored into the following type of structure:

src/vector.js

(vector here would be a placeholder object, that detects what browser
capability and includes either dojo.vector.svg or dojo.vector.vml)

src/vector/svg.js src/vector/vml.js

Both of these files would contain the same methods with signatures;
the final line in each would mix the entire object into dojo.vector,
so that developers would refer directly to dojo.vector for base
functionality.

I'll probably end up working on that fairly (i.e. within the next
couple of weeks) soon, so if there are any suggestions for methods
feel free to say so.  This is *not* the drawing API but wrappers for
the base functionality that the drawing API would be on top of; I'll
be using dojo.style+dojo.html as the inspiration source for this.

trt

On 6/9/06, Tom Trenka <ttrenka at gmail.com> wrote:
> > 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
> be desired.
>
> 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
> d attribute).
>
> > > 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.
>
> (see above)
>
> 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
> suggested.
>
> 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:
>
> <svg dojoAttachPoint="domNode">
> <g dojoAttachPoint="mainGroupNode">
> <rect dojoAttachPoint="rectNode" .../>
> </g>
> </svg>
>
> The result of an XSL transformation for IE would look like:
>
> <div dojoAttachPoint="domNode">
> <v:group dojoAttachPoint="mainGroupNode">
> <v:rect dojoAttachPoint="rectNode">
> </v:group>
> </div>
>
> 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:
>
> var rect=dojo.gfx.createRectangle(widget.rectNode);
>
> ...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...
>
> trt
>



More information about the dojo-contributors mailing list