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

Eugene Lazutkin eugene at lazutkin.com
Fri Jun 9 15:42:03 EDT 2006


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

While it makes perfect sense to have templates for many things, in the 
Real Life (tm) a number of bars in your bar chart (slices in your pie 
chart, lines in your graph, lines in your grid, scale in your axes, and 
so on) depends dynamically on data you want to show. Not only number is 
different --- shapes, their number, and graphic attributes may be 
different. Do you want to solve it with templates only? I am curious to 
hear about your plan.

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

OK, I really need to know your ideas about graphic templates. It looks 
like I am missing some details.

> 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

I am all ears. :-)

> DOM methods as well...including cloneNode (although I think I need to
> double check that).

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

Yep, JS would be easier to use here. But it can be done with XSL too.

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

I am with you. We do need both.

> 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

I doubt it is possible in even simple cases, but then again I need to 
learn your ideas first.

> 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

Do you need an API for positioning and transformation, or is it done by 
template somehow?

> API; I'll need some positioning functionality which should end up
> being there underlying the drawing API anyways (think dojo.svg).

Yes, the drawing API needs it too. I see you want to split the 
transformation off the drawing API. What else do you need? Do you want 
to change graphic attributes? Do you want to add new shapes?

> On the other hand, one should also be able to use the Drawing API
> without having the XSL being loaded for IE.

Of course. It would be nice to load a prepared drawing sometimes as a 
starting point.

> 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

Right.

> 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

I think we need to split the drawing API and the existing code allowing 
to reuse pieces in both branches of Dojo Graphics. E.g., transformations 
of different type.

> that the drawing API be able to take existing nodes as arguments if
> needed.  Let me give an example.

I am all for that!

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

It is useful for any kind of template modifications as well as for DOM 
modifications. We can reuse it providing we have compatible API.

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

Of course. We have to have that.

> Does that make sense at all?  It's the morning here and the coffee
> hasn't quite kicked in yet...

Coffee works wonders for you. ;-)

Thanks,

Eugene



More information about the dojo-contributors mailing list