Martin, You wrote: "Your suggestions for enhancing the FeatureInfoTable view all sound good to me, Paul. It's a nice idea to have different Geometry text renderers. I might even go further and define a simple framework for GeometryTextRenders, which could have different instantiations added in the Registry. The FeatureInfoTable view could display choices for all loaded renderers."
Are you and Paul just talking about a way to allow custom rendering of a selected feature's attributes in the FeatureInfo tool? (For example, if the attribute was the full path to an image, the image could be rendered instead of the actual text value contained in the attribute.) Or are you guys talking about something else entirely? The Sunburned Surveyor On 6/4/07, Paul Austin <[EMAIL PROTECTED]> wrote: > Hi Martin, > > I'm just working on a concept of a HtmlRenderer that will take an object and > convert it to HTML for display in Swing HTML widgets. There will then be a > HtmlRendererRegistry that will map from a Java Class to a renderer. When > displayign features you would use the registry to get a renderer for an > object and use this to generate the HTML. > > We could then extend this concept for things like geometry where the user > can via the UI choose between a choice of renderers for that class (e.g. > WKT, GML), those plug-ins would switch on the fly the renderer in the > registry. > > The registry should also support the property change listener so that UI's > can refresh themselves if the registry changes. > > Paul > > > Martin Davis wrote: > Your suggestions for enhancing the FeatureInfoTable view all sound good to > me, Paul. It's a nice idea to have different Geometry text renderers. I > might even go further and define a simple framework for > GeometryTextRenders, which could have different instantiations added in > the Registry. The FeatureInfoTable view could display choices for all > loaded renderers. As for the compound Feature idea, this seems to depend > on having Readers which can actually create these things. It sounds like > you have defined a custom reader for your need. I would be reluctant to > build very much functionality for compound Features into the core until > there is a clearer idea about the general use cases for them, and what > would be required to make them usable throughout JUMP. For now hopefully > adding some hooks to extend the FeatureInfoTable view will meet your > need. 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. More generally, this is all moving in the > direction of supporting a full GML-like data model, where Features can > contain FeatureCollections as attributes. I think deegree might have > already extended JUMP to accomodate this - it would be nice to hear from > them how well this worked and what they had to do to make it work. I think > there might be some big UI challenges in accomodating a hierarchical > Feature model, but it might be worth building the infrastructure (i.e. > enhancing the feature package), and then gradually enhancing the UI to > expose more and more of it. It should be possible to provide sensible > default UI behaviour wherever necessary. Paul Austin wrote: > All, I have attached a screen shot of my new Feature InfoTable > implementation. As you can see I've added some CSS styling to the table > and where there are "nested" feature types have the feature type name > displayed and a nested table with their attributes. NOTE: The sub feature > type name stuff won't work with regular JUMP features as the FeatureSchema > does not include the feature type name. I'm using my own Feature > implementation based on the model used in my reader framework. It would be > simple to add this to FeatureSchema if required. After looking at the > current implementation I would like to suggest a change to the way the who > feature info table view works. 1. Under the view menu have sub menu to > allow the user to select the style for viewing geometry (WKT, EWKT, CL, > GML) in addition to the current approach and save that so the user always > get their preference. 2. Implement a FeatureInfoTable renderer which > defines the style for the info view (e.g. HTML table, v.s. GML v.s. Tab/CSV > format 3. Roll the FID and geometry attribute into the table > FeatureInfoTable renderer so that the geometry render is just used when > geometry values are detected to display the value portion. So for example > there would be a position row in the table that would have the geometry > formatted as WKT or GML 4. Where multiple records are displayed use a > database style paging display where one feature is displayed at a time but > you have back/forward, first/last and jump to record number. Think > MSAccess or FME style paging through selected features. Any > comments/suggestions? Paul Martin Davis wrote: > Is your use case only for a property which contains a single Feature? The > general case would be to have a property which contains a FeatureCollection > (this is the full GML model, for instance). In this case the UI gets a bit > more complicated. How are you creating the Feature property? Do you need to > spatially visualize it? I'm asking these questions because while your use > case may simply be to view a single Feature property, it's nice to look a > bit further down the road at a more general design, in order to avoid > making the implementation overly specific and hard to extend. In general > supporting a hierarchical feature model introduces tons of issues all > through JUMP... which is why we didn't go there at first. The closest we > got was to support a custom object hierarchy and expose different classes > of it as separate FeatureCollections. This allowed treating the various > classes as map layers, which worked pretty well. But this was all custom > code and hard to make general-purpose. As for the code-value entry plugin, > the general concept would clearly be nice to have. Would your entry screen > only support that single attribute, or would you make a general entry panel > which showed all attributes? This was talked about a week or two ago - it > would be nice to have this as another view in the Attribute View window. > How would you supply the code-value mapping? Paul Austin wrote: > I have a data set where a property of a feature is another feature object. > In the schema it has the type Object but it's actually a Feature > instance.What I would like to do is have the following. 1. A right click > on the feature row to view the whole feature and have a view/edit feature > frame that would display the list of property names and values with nested > panels for each nested feature. 2. Use the feature display panel to > display the feature on say roll over of a complex property value Has > anyone worked on such a feature? If not I'll start writing one. Also I was > thinking that in databases you have the concept of code lookup tables, I > was thinking of a plugi-in that you can configure to display the code value > instead of the code ID and have a drop down for changing the values instead > of entering the > codes. Paul ------------------------------------------------------------------------ ------------------------------------------------------------------------- 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
