Hello Dev,
I've clipped Thomas' todo list and pasted below for reference. I'll just
refer to the numbers.
My paying gig would benefit from all of the below, so I'm ordering based
on personal preference. If one task is more useful to a larger audience,
I'm cool with refocusing.
Task 4 is one I'd like to tackle first. I do have some concerns though.
Would we continue to support the shadowtree api? I would assume so since
much code probably relies on the voodoo-traversal to the real parent. Since
the computational overhead of supporting the spec and the shadowtree may be
significant, should the shadowtree api be refactored to mimic the old
behavior while really traversing elementinstance's? Are there any test
cases for the shadowtree to test for regression?
Task 3 probably the most interesting to me. Thomas, do you happen to know
where the gradient example might have landed if not on trunk. I can dig if
you are not sure.
1 & 2 look pretty straightforward.
Jonathan
1) Pipe all element "lookups" through an object associated with the
BridgeContext. This would be to serve two purposes. First it
would more easily enable people to 'replace' Batik's lookup/fetch
logic (replacing/augmenting ParsedURL only goes so far). Second
if paired with 'unlookup' calls it would enable Batik to detect
complex reference loops in content (an element that references a
pattern that uses the element).
2) Make everything use ParsedURL for references. Currently there
are still a few places where we don't use ParsedURL (I think
mostly in CSS) this mostly means that you can't use base64
encoded URLS in these places.
3) Add dynamic updates for referenced content. Currently in many
cases if a referenced element changes Batik doesn't notice. I
think this is true for patterns, filters, masks, etc. I did an
example of dependency tracking for gradients (which may not have
landed on trunk) at some point it would be nice if this was extended
to other areas.
4) Implement ElementInstance for Use elements. Currently we create a
shadow tree to support the use element, which is not conformant to
the SVG specification. It would be better if we created ElementInstances
that could carry the CSS cascade information and then use a reference
to the actual element for DOM attributes. This would require updating
all of the Bridges to know/handle the ElementInstance case but I think
the changes (while widespread) could be fairly simple.
