Hi Jake,
"Jake B" <[EMAIL PROTECTED]> wrote on 08/22/2007 11:20:50 PM:
> The goal is to take a meta-modelling environment which we
> have implemented in Python/Tkinter, construct a lightweight front-
> end, and use pieces of the original environment to power the back-end.
Well I hope it goes well for you, and hopefully we will be able
to help you past any rough spots.
> I'm currently working on a small prototype in order to get familiar
> with Batik, and become a bit more knowlegable about the details of
> the technologies involved. Basically, I am trying to construct a few
> basic user interface widgets (a button, a panel, and a menu) in SVG.
> I know that the idea of building standard user interface widgets has
been
> discussed, and even implemented, but my version will have a slightly
> different twist to it, which is that the layout and reactive
> behavior of the widgets will be modelled using statecharts (our tool
> can generate executable python code). This statecharts will be kept
> on the server. The goal of this prototype is to show that widget
> behavior can be modelled using statecharts, and to get aquainted
> with the technologies that the rest of the project will rely upon.
>
> That's pretty much the gist of what I'm trying to do. I have a few
> question to start out. These are fairly open questions, and there
> may not be a straightforward way to answer them, or a single correct
> answer, but I would nevertheless appreciate any advice anyone could
offer:
> 1. In the context of the SVG specification, what would be the most
> appropriate way to represent a widget? It would either have to be a
> <g>,<svg> or <symbol>. I think any of these would work, but I'm not
> sure which one would be the truest to the spec.
I would tend to use a 'g'. The advantage of 'svg' (and also symbol)
is that it establishes a viewport which first adds a default clip region
(which could be good or bad) and second gives you some fairly simple
control of the coordinate system. That said you actually have more
control over the coordinate system with 'g' since you can use the
transform
but the interface is a bit more complex.
Symbol is useful if you want to have multiple copies of the
_exact_ same thing. As soon as you start creating tweaked versions of
things to add as 'symbol' elements that you then 'use' you are almost
always better off just adding the tweaked elements where the use would
be.
> 2. In the context of extending Batik, what would be the most
> appropriate way to represent a widget? If, for example, in the SVG
> spec, a widget would best be represented as <g> element, then in the
> context of Batik, would the most appropriate way to represent a
> widget be to create a subclass of SVGOMGElement? Or would there be a
> better way?
Don't subclass our DOM Elements unless you want to create custom
DOM Elements. I would probably build a separate 'widget tree' with
your own classes (not directly tied to DOM). Then I would have
references to the DOM tree in my widget objects. The widget objects
would register callbacks on the DOM objects for events they care about.
If you need to you could also have a hash table that allowed one
to go from an arbitrary DOM object to the associated Widget Object
but in my experience that isn't normally needed (the event listeners
know what object registered them, so this generally only needed if
the need to map graphics->widget comes outside of the scope of an
event).
> 3. I'd like to leverage the Factory classes in org.apache.batik.dom.svg
> , but I can't figure out how to initialize the attributes of the
> Element objects I've created. They do not have public set methods,
> and even though they implement the Element interface, calling
setAttributeNS
> on them does not change their attributes. What is the proper way to
> set the attributes on these objects?
What Factory classes in batik.dom.svg? The only two I see are the
Factory classes for producing Documents. Documents don't have
attributes - so perhaps that is your problem?
A clean Application should never even know that batik.dom.svg
exists. That is the package we use to implement the org.w3c.dom.svg
interfaces. The org.w3c.dom.svg interfaces are what you should
use in your Application. We are free to change any and all details
of our DOM implementation - but the W3C SVG DOM interface must stay.
> 4. I also cannot seem to append the Element objects produced by the
> factory classes to the SVG document by calling
svgRoot.appendChild(object).
> It just doesn't seem to get appended to the DOM tree. Is there a
> special way to attach the objects created by the factory classes (as
> opposed to those created by doc.createElementNS) to the DOM tree?
I suspect you are creating Document objects which can't be
'child' Nodes. The only correct way to create Element's is through
the document object. Our Document Object is cleanly extensible
so you can register new 'factory' methods to construct private DOM
Objects. However, as I said above I would lean towards leaving the
DOM the DOM and hang my data structures alongside the DOM. This
might also make the job of sending updates a little easier as your
control stuff won't be mixed in with the 'display' document.
> Thank you very much for reading my very long email. I would
> appreciate any guidance anyone can offer.
Good luck.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
