This all seems like a lot of extra complexity to support something that at the moment is really only your own use case. Perhaps you should publish this as a plugin for now, and if it gets used a lot then the JUMP project can think about incorporating it in the core.
Paul Austin wrote: > Hi Martin, > > The reason I'm proposing to include them is for the new Attribute View > that I'd like to have as a core OpenJump view. With the attribute view > it uses my new Builder framework for displaying the features and this > supports nested features just by the virtue of having a value for a > property that is a Feature instance. By having the name on the > FeatureSchema we are able to display the type of feature for nested > features. All of this works with current JUMP features except the > FeatureSchema name > > I could do all of the above by registering a custom renderer for Paul's > Feature instance class but I think this is something that other people > may want in the future. > > Paul > > Martin Davis wrote: > >> Paul, >> >> It sounds like (a) named Feature Schemas are a pretty specialized use >> case (I certainly have never had the need for them in all my JUMP >> projects, and (b) you aren't proposing to provide any functionality to >> expose them to JUMP users. >> >> In this case, I wonder whether there's a real need to add them to the >> JUMP Feature model right now? In some of my projects I've achieved >> similar functionality (and a whole lot more) simply by creating custom >> subclasses of Feature. Client code can easily check the subclass and >> make decisions based on it. >> >> I'm not against the idea of named schemas, since that moves things in >> the direction of a more "database-like" Feature API. But if they're not >> really used anywhere in the JUMP codebase except in your own custom >> code, it seems like it might be better to hold off designing them in. >> "Parts left out cost nothing". >> >> My 2c worth.... >> >> Paul Austin wrote: >> >> >>> Hi Larry, >>> >>> At the moment the FeatureSchema is designed just to allow you to get the >>> list of attributes for a feature. If you want to know the "type" of >>> feature you are dealing with you have to know the layer the feature is >>> in to get the "type" of the feature. I would say that 99% of the time >>> the name of the feature schema would be the same as the layer name. >>> >>> I would probably not persist the feature schema name in the .jmp file, >>> instead internally in jump update the feature schema name when the layer >>> name changes. This of course would not be the case if we had "themed" >>> layers as per Martins suggestions regarding the Catalogue concept. >>> >>> Here are the cases where it would be used. >>> >>> 1. For features that contain properties that are features (they don't >>> have to have geometry), I think I'm the only one using this and >>> it's supported by JUMP as a property can contain any object value >>> 2. Where you want to process a feature collection and don't have the >>> associated layer but would want to do some QA tasks that vary >>> based on the type of feature. For example you could have a minimum >>> length plug-in that could have different minimum lengths for road >>> vs. river segments >>> >>> The name on the feature is the only change I require to the feature >>> model in JUMP (for now ;) ) >>> >>> Paul >>> >>> Larry Becker wrote: >>> >>> >>> >>>> Hi Paul, >>>> >>>> Just a few questions regarding the FeatureSchema Name, since I'm >>>> unable to come up with the use case myself. I can see that it is >>>> simpler to look at the Name than to compare all of the attributeNames >>>> individually, but I would hate to make that assumption and then find >>>> that the user has deleted an attribute I was depending on. Also, >>>> would the FeatureSchema Name be persisted in the Task (.jmp) file, and >>>> if so how does that affect compatibility? >>>> >>>> thanks, >>>> Larry Becker >>>> >>>> On 6/9/07, Stefan Steiniger <[EMAIL PROTECTED]> wrote: >>>> >>>> >>>> >>>> >>>>> hei Paul, >>>>> >>>>> mhm.. if you write the function (that also supports empty names) >>>>> this should be possible to include if Michael and Larry agree >>>>> >>>>> stefan >>>>> >>>>> btw. although you are following specific interests, and changes to the >>>>> core need to be discussed it is open to you to join the jpp-team >>>>> >>>>> Paul Austin schrieb: >>>>> >>>>> >>>>> >>>>> >>>>>> Martin, >>>>>> >>>>>> If the FeatureSchema class could be extended to have a name property, >>>>>> with a getName (and maybe a setName) with a default constructor and a >>>>>> constructor that takes the name as an argument then that would be great. >>>>>> As we have default constructor existing code won't break as the name is >>>>>> optional. >>>>>> >>>>>> The advantage of having the name is that if you were doing some >>>>>> processing of features and don't have reference to the layer you can >>>>>> find out what type of feature it is and do different processing >>>>>> accordingly. >>>>>> >>>>>> Paul >>>>>> >>>>>> Martin Davis wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> BTW, the idea of having hum-readable names for FeatureSchemas is a nice >>>>>>> one. I'd definitely support adding that functionality, even if it isn't >>>>>>> exposed right now. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> ------------------------------------------------------------------------- >>>>>> This SF.net email is sponsored by DB2 Express >>>>>> Download DB2 Express C - the FREE version of DB2 express and take >>>>>> control of your XML. No limits. Just data. Click to get it now. >>>>>> http://sourceforge.net/powerbar/db2/ >>>>>> _______________________________________________ >>>>>> Jump-pilot-devel mailing list >>>>>> Jump-pilot-devel@lists.sourceforge.net >>>>>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> ------------------------------------------------------------------------- >>>>> This SF.net email is sponsored by DB2 Express >>>>> Download DB2 Express C - the FREE version of DB2 express and take >>>>> control of your XML. No limits. Just data. Click to get it now. >>>>> http://sourceforge.net/powerbar/db2/ >>>>> _______________________________________________ >>>>> Jump-pilot-devel mailing list >>>>> Jump-pilot-devel@lists.sourceforge.net >>>>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>> ------------------------------------------------------------------------- >>> This SF.net email is sponsored by DB2 Express >>> Download DB2 Express C - the FREE version of DB2 express and take >>> control of your XML. No limits. Just data. Click to get it now. >>> http://sourceforge.net/powerbar/db2/ >>> _______________________________________________ >>> Jump-pilot-devel mailing list >>> Jump-pilot-devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel >>> >>> >>> >>> >> >> > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Jump-pilot-devel mailing list > Jump-pilot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > > -- Martin Davis Senior Technical Architect Refractions Research, Inc. (250) 383-3022 ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
