geotools-devel-admin@lists.sourceforge.net wrote on 01/23/2006 10:15:45 AM:
Bryce L Nordgren wrote:
> [Bunch of crap]
>
Bryce we have a lot of positive experience with EMF, it should do you
just fine. At its heart EMF has EClass and EObject which are similar in
spirit to the featureType and Feature constructs (aka they both are
forming a dynamic type system).
Yup. Good to hear that it's not all-talk-no-walk.
You will also find that JET (Java Emitter Template) will enable you to
generate out either a) an imlementation that satisfies both EMF and
Feature needs. If you need assistence with JET talk to Justin or Jesse
(an offer to put Justin up when he comes to europe
Nice try.
Best of luck and I understand about the deadlines. I have carefully
ensured that the FeatureType work will not conlfict with an EMF based
solution - as it is an obvious move from where I sit as well.
Very good news!
If there is any chance that you can put together these abstractions in a
public space - geotools spike or udig? I would be very interested taking
part.
I haven't assembled them anywhere yet (just thinking so far). When I do,
it will be on the coverage branch.
You will also find that the GeoServer team is in the "gotta start" doing
stage, there is probably room for collaboration. Indeed you will find
trunk is being "cleared" explicitly for this work.
My intention is to stick entirely to coverages if I can. I also don't have
enough (any) experience with EMF yet to say what form the Feature solution
should look like. (e.g., just use EClass/EObject directly or try to make a
FeatureType implementation?) I'd like to offload an EMF Feature solution
to someone smarter than me and then I'll follow suit inside coverages by
extending the Feature solution.
Lastly, trying to input a design to EMF with the glorified property editor
is a little like gouging out your own eye with a rusty spoon. Has anyone
developed some sort of XSLT solution for XMI/UML2 (e.g. Poseidon, et. al)
to EMF's XMI?
Bryce we have a lot of positive experience with EMF, it should do you
just fine. At its heart EMF has EClass and EObject which are similar in
spirit to the featureType and Feature constructs (aka they both are
forming a dynamic type system).
Yup. Good to hear that it's not all-talk-no-walk.
You will also find that JET (Java Emitter Template) will enable you to
generate out either a) an imlementation that satisfies both EMF and
Feature needs. If you need assistence with JET talk to Justin or Jesse
(an offer to put Justin up when he comes to europe
Nice try.
Yep better stick to beer.
Best of luck and I understand about the deadlines. I have carefully
ensured that the FeatureType work will not conlfict with an EMF based
solution - as it is an obvious move from where I sit as well.
Very good news!
You will find the "event" system to be a bit of a learning curve. For uDig we ended up "translating" from
their notification system to normal java events (aka add/remove listener methods). It is capable however.
We took a simplified take on these ideas (and reinvented the wheel) for the recent revisions to styling
classes.
You will also find that the GeoServer team is in the "gotta start" doing
stage, there is probably room for collaboration. Indeed you will find
trunk is being "cleared" explicitly for this work.
My intention is to stick entirely to coverages if I can. I also don't have
enough (any) experience with EMF yet to say what form the Feature solution
should look like. (e.g., just use EClass/EObject directly or try to make a
FeatureType implementation?) I'd like to offload an EMF Feature solution
to someone smarter than me and then I'll follow suit inside coverages by
extending the Feature solution.
Fair 'nuff. You can convince EMF to refer to interfaces defined outside of its model, so your EMF
generated Coverage can still refer to Feature. Stub out some code mapping getAttribute( name ) to eGet( name )
and you are on your way.
Lastly, trying to input a design to EMF with the glorified property editor
is a little like gouging out your own eye with a rusty spoon. Has anyone
developed some sort of XSLT solution for XMI/UML2 (e.g. Poseidon, et. al)
to EMF's XMI?
You can feed EMF from java interafaces, XMLSchema or ECore (its internal format).
Although ECore sounds like a silly idea, go download Omondo, it speaks ECore directly
and is happy to play for free as long as you are not on a shared project. If you don't
have subclipse installed it cannot tell you are working with version control....
There are translations available from RationalRose to ECore so if you have something like
that around ....
For uDig we hack at normal java interfaces and hit generate, occasionaly dragging out Omondo
for a pretty picture.
Thanks for the encouragement!
Well it won't be fun - you did buy the book right?
Jody
