Message-ID: <1788384147.2805.1412261527257.JavaMail.firstname.lastname@example.org> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_2804_1634312038.1412261527256" ------=_Part_2804_1634312038.1412261527256 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 t= he existing styling objects to have an event mechanism (probably one that n= otifies parent objects)
2) Redesign the styling architecture to use m= ore generic nodes, cutting down on the number of unique objects and simplif= ying the addition of a style system
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 solu= tion. Questions remain about how easy it would be to use and, criticaly, wh= at the performance cost would be.=20
A branch to do this has been created (At revision: 15806) to evaluate it= s practicality and performance. Details to follow...=20
Jody - your branch was amsuing (he made a DynamicProxy that added Proper= tyChange events to every set method)!=20
Before we could even start we ran into a number of problems:=20
This was a simple mistake of the undone kind, everything is set up as ex= pected now.=20
What is expected? Here is an article:=20
Wrote an article on supporting multiple versions:=20
Here is what the ideal looks like:=20 =20
And here is what we would need todo with Java 1.4:=20 =20
That is we cannot indicate from our GeoTools interfaces
that subcl= asses returned are explicilty of a known GeoTools
type. We ar= e stuck with lowest common demoninator aka
a lot of instance= of checks.
The best advice was to leave things alone and mark new methods
wit= h javadocs.
We can still set up Factory classes that are restricted to constructing<= br /> things within the bounds of their specifications.=20
Conclusion their is not much to be done until we have Java 5 with type n= arrowing...=20
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.=20
We grabbed the even system from Catalog and made a copy, changing everyt=
hing over to Style.
StyleLayerDescritor has the add/remove listener c= ode. It has a event system suitable to changes
in a tree structure, i= n particular it is amiable to "batched changes" 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 t= ree. To make this easy we set up a StyleComponent and implemented everythin= g 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/notification to an interface for th= is technique
to work. (The driving story here being someone wanting t= o implement a custom Stroke, and making sure they can still
hook into= everything w/ out breakage). GTComponent is thus not API for client 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 implementations.