[dojo-contributors] Re: Draft: Unified 2D graphics subsystem for Dojo
ttrenka at gmail.com
Fri Jun 9 17:07:44 EDT 2006
dude, your inline comment placement just confused the shit out of
me... ;) Some answers inline.
On 6/9/06, Eugene Lazutkin <eugene at lazutkin.com> wrote:
> 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.
All of the examples you just described would be better handled by a
drawing API or a code forking than a template system. I'm referring
to widgets that don't require the creation of nodes as a part of the
template. If a widget requires creating nodes dynamically (other than
HTML as text nodes) then of course there would need to be an inclusion
of the drawing API.
> Yep, JS would be easier to use here. But it can be done with XSL too.
Yes it can. But I'd much rather drop into script then get into a slew
of string splitting/parsing using things like substring-before, after,
etc. In this respect JS is a lot more powerful, and there is *very*
little perf hit with this in the MSXML parser (i've done it before, it
> Do you need an API for positioning and transformation, or is it done by
> template somehow?
Basic style and position manipulation on the order of the manipulation
encapulated in the current dojo.style + dojo.html should not be a part
of a drawing API IMHO. Changing and manipulating basic things such as
attributes (with care!) should be available outside of both the
drawing API and the SVG to VML XSL.
Think of it this way...should vector-based DnD be a part of the
drawing API? What does this say for the current code base? Extend
that to other things, such as animation. Should all of this be tied
to a more extensive drawing API?
> 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.
Refer to my other email--I think that that's probably the best
solution for this that I can think of...although I'm open to
More information about the dojo-contributors