Jody Garnett ha scritto: > Thanks for the detailed feedback Andrea going to try to field these > quickly before my workday... >> DataAccess >> ----------------- >> >> The interface does not say anything about being able to provide >> read only or read write accessors. I see that there's a Store >> interface that extends Source, but it's completely empty. >> > Indeed this is where I wanted to talk to someone - but we place the > topic at the end of the meeting agendas :-( >> Describing type by returning the "native" type as in Object describe() >> is useless in my opinion, because it makes it impossible to write >> generic reading code. >> > We can write generic reading code (expression), but you are correct we > cannot determine what those expressions should look like without prior > knowledge. That prior knowledge can be provided in the form of an SLD > file, but we still need a solution. > > The solution is a model, which one? Well some options were listed. >> Something using this simply cannot be added to Geoserver, and it's a >> shame, because it would be nice to be able and serve pojo out of it, no? >> > It would but you are going to need a lot more, namely to take on the > model problem in a responsible enough fashion to do transformations > between model descriptions. Aka UML to GML, ISO to UML to GML etc... >> What I'm thinking is, if you can provide property accessors to your >> "content", then you can also sum up all the conceivable property >> accessors for your type and make something that looks like a >> FeatureType out of it, no? >> > Well I could, but we are serving up rich content here - so the result > does not look like FeatureType, it looks like a schema of FetureTypes > with relationships etc...
Nope, when you're rendering you're using just the "flat", simple part of it, or you would not be able to use it, no? >> Why, instead of simply returning a useless "Object", can't we return >> something that implements an interfaces that _looks like_ Feature type? >> Maybe something that can list all "simple" properties around, those that >> geotools is able to handle at the moment, and a default geometry. >> Or, as a second alternative, provide services that turn these object >> description into something that can be understood at the geotools >> api level without any external intervention? >> > An implementation can do all these things, an implementation that is > close is on the FM branch. > > Andrea GeoServer (and generating GML) is not my only concern here; I > would like to open the door to rich content beyond our feature model. > Since we have failed to produce one (and something like EMF seems to be > taking over) it seems best to sit on the sidelines. If we cannot "reflect", "inspect" at least the simple properties out of that Source thing, then I'm against having it around. It just adds confusion and provides little value imho. Of course it's a matter that the PMC should discuss, so if mine it's the only -1 with two vote sessions you can get away anyways. Cheers Andrea ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
