Message-ID: <87485091.40266.1371592709577.JavaMail.email@example.com> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_40265_24026561.1371592709576" ------=_Part_40265_24026561.1371592709576 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
Right now it is very hard to track changes that are made to objects in a=
style tree. There are a number of solutions to this:
1) Modify all the existing styling objects to have an event mechanism (prob= ably one that notifies parent objects)
2) Redesign the styling architecture to use more generic nodes, cutting dow= n on the number of unique objects and simplifying the addition of a style s= ystem
3) Leave everything as it is but use crazy dynamic proxy code to add events= into the existing structure.
James - My current approch is No 3). It may not be the best (2 probably= is) but is easy to implement and will result in a backwards compatable sol= ution. Questions remain about how easy it would be to use and, criticaly, = what the performance cost would be.
A branch to do this has been created (At revision: 15806) to evaluate it= s practicality and performance. Details to follow...
Jody - your branch was amsuing (he made a DynamicProxy that added Proper= tyChange events to every set method)!
Before we could even start we ran into a number of problems:
This was a simple mistake of the undone kind, everything is set up as ex= pected now.
What is expected? Here is an article:
Wrote an article on supporting multiple versions:
Here is what the ideal looks like:
And here is what we would need todo with Java 1.4:
That is we cannot indicate from our GeoTools interfaces
that subclasses returned are explicilty of a known GeoTools
type. We are stuck with lowest common demoninator aka
a lot of instance of checks.
The best advice was to leave things alone and mark new methods
We can still set up Factory classes that are restricted to constructing<= br /> things within the bounds of their specifications.
Conclusion their is not much to be done until we have Java 5 with type n= arrowing...
This is a related problem to that above, but we can have more success be=
no interaction with GeoAPI is needed.
This is consistent w/ Java use, interested Renderers can use an instance= of check and a cast.
We grabbed the even system from Catalog and made a copy, changing everyt=
hing over to Style.
StyleLayerDescritor has the add/remove listener code. It has a event system= suitable to changes
in a tree structure, in particular it is amiable to "batched changes&q= uot; such as would be produced
by a single transformation performed by a StyleVisistor.
Part of the fun of setting up for the above ease of use is this - the ne=
ed for a getParent() inorder to pass the
change notification up the tree. To make this easy we set up a StyleCompon= ent and implemented everything once...
Thinking ahead we decided to rip everything out into org.geotools.event =
so this system can be reused with Filter
and Catalog. We did need to isolate the API for getParent/setParent/notifi= cation to an interface for this technique
to work. (The driving story here being someone wanting to implement a custo= m Stroke, and making sure they can still
hook into everything w/ out breakage). GTComponent is thus not API for cli= ent code, it is API for people extending
Finally we made a GTList (subclass of ArrayList) that knows how to pass =
along events when the list is changed. A
smooth move that lets events have very little impact on the Style implement= ations.