The current theming works well if you have a single attribute value that
you want to assign a different style to. It does not however work if you
want to define more complex style to feature rules using more than one
attribute (e.g. number of lanes and surface type on a road).
What would be
Guiseppe,
I have attached the scribus files that I have been using. One is for a
topic title page, the other for a normal topic page, and the third for
a topic graphic page. I also attached the font files I am using. (I
think I may be missing a third font that I am using.)
I will try to take
I haven't started on any of the tools functios, although I was going
to try to get to the new ones at some point.
You tear into it and I will work around what you accomplish. Thanks
for the great effort with the documentation!
The Sunburned Surveyor
On 6/8/07, Giuseppe Aruta [EMAIL PROTECTED]
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
Hi SS,
I don't want to hold up progress. If the majority wants
Subversion, then by all means go for it.
Sorry I haven't been keeping up with the list, I've been busy.
regards,
Larry
On 6/8/07, Sunburned Surveyor [EMAIL PROTECTED] wrote:
Let's wait to see what Larry Becker has to say
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
Hi Paul and Larry,
Just few questions I wonder about naming schemas :
- What really needs to be named, FeatureSchema or FeatureCollection ?
- Will it be possible to have two different names for identical schemas
(it should) ?
- Will it be possible to have two different schemas with identical
Michaël,
1. It is the FeatureSchema that needs to be named as this is the only
thing a Feature has reference to.
2. Yes you can have different names for two different FeatureSchema
instances that share the same attribute names and types, consider say a
simple data set that has road and river and
Good questions, Michael, especially the one about having different
schemas with the same name. I suspect Paul's code would work fine in
this case, but it is an important philosophical point which should be
thought out fully before going far down this road.
Michaël Michaud wrote:
Hi Paul and
So how does your TableAttributeView handle the situation where two
different FeatureSchemas have the same name? Isn't it going to make
assumptions about how to handle the schema based on the name? Or -
perhaps it's just displaying the name, and doesn't expect any other
semantics around it?
No problem Larry.
I will work on setting up the Subversion repository for OpenJUMP
development this week and will let the list know when it is complete.
I will also assign all those with write access to the CVS write access
to the SVN. If you don't have write access currently but would like to
Martin,
Does JUMP currently have any introspection code to get a property from
an object by a name, something like commons-beanutils. If it does I can
use introspection to see if the FeatureSchema has a name property if
it does use that rather than requiring it on the FeatureSchema class.
BTW I
Not sure what you mean - you mean retrieve an attribute from a Feature
by name? If so, yup. Otherwise, it has whatever java reflection provides.
Paul Austin wrote:
Martin,
Does JUMP currently have any introspection code to get a property from
an object by a name, something like
Something like this, rather than having to do all the class.getMethod stuff
String name = PropertyUtils.getProperty(featureSchema, name);
Paul
Martin Davis wrote:
Not sure what you mean - you mean retrieve an attribute from a Feature
by name? If so, yup. Otherwise, it has whatever java
Martin,
My new detail view page actually uses the Layer to group things by name
at the moment using the InfoModel as used by the existing geometry and
table views.
I agree that having a name space as name is important and in fact I have
that in my underlying model that I wrap with a JUMP
I get it. Nope, but sounds like a good thing in jump.util (or some
appropriate subpackage)
Paul Austin wrote:
Something like this, rather than having to do all the class.getMethod stuff
String name = PropertyUtils.getProperty(featureSchema, name);
Paul
Martin Davis wrote:
Not sure
I think that FeatureSchema instances would be local to the data source
used to load the layer (e.g. file or database connection), within the
scope of that names should be unique.
Hmm... seems to me this would then require all code that depended on
name uniqueness to then be aware of the
All,
JUMP could do with a utility class similar to commons-beanutils that
would allow you to get/set properties on an object without using
introspection. The following is a naive implementation for getting a
property value. A real implementation would need to use caching to
improve performance
18 matches
Mail list logo
