Those interested please give a quick read and provide feedback,
comments, concerns, etc...
So far the comparison looks good. I have some quick feedback:
* Freemarker does not have a template sample
* Compare error reporting (users do not have a debugger,
how does the template report mistakes? Precise line and char
error with clear explainations, or simply "you did screw up
syntax man!" like our SLD parsers?)
* Compare template reloading (the template is updated, will
Geoserver notice?)
* Compare the ability to have simple but most common formatters
around (number, date and time formatters for example), as
well as light string manipulation. Is it easy, hard, impossible?
* are both parsers streaming?
I will add a section on "Usability" for each of the candidate
technologies and work on answering the questions. I can answer a few of
them up front though.
Andrea Aime wrote:
Justin Deoliveira ha scritto:
Hi all,
As of late there has been talk of adding the ability to use templates in
GeoServer. So I have done a bit of research and whipped up my thoughts
here.
Those interested please give a quick read and provide feedback,
comments, concerns, etc...
So far the comparison looks good. I have some quick feedback:
* Freemarker does not have a template sample
Good point, a complete example for each would not be a bad idea.
* Compare error reporting (users do not have a debugger,
how does the template report mistakes? Precise line and char
error with clear explainations, or simply "you did screw up
syntax man!" like our SLD parsers?)
from my research i found freemarker to be better, but i will come up
with some of the common cases and see what the errors are.
* Compare template reloading (the template is updated, will
Geoserver notice?)
Both velocity and freemarker check the modification time of the source
and compare it with what has been cached, reloading if a modification
has occured.
* Compare the ability to have simple but most common formatters
around (number, date and time formatters for example), as
well as light string manipulation. Is it easy, hard, impossible?
Will look into this one.
* are both parsers streaming?
Both back onto iterators over collections, so I believe so.
The example is good, but I would like to make sure that people don't _have_ to define the template in their SLD. Like they should be able to just define a template for their featureType, and then get it as WMS GetFeatureInfo output and KML output.
I also think it might be worthwhile to make it a WFS output as well - it's an alternate way of displaying the information about the feature. But this goes back to my whole goal of combining our factories for GetFeatureInfo and GetFeature, since they do essentially the same thing.
C
Brent Owens wrote:
I quickly read it and so far I think it looks pretty good. I put an example at the bottom on the potential use in KML and SLD.
Brent Owens
(The Open Planning Project)
Justin Deoliveira wrote:
Hi all,
As of late there has been talk of adding the ability to use templates in
GeoServer. So I have done a bit of research and whipped up my thoughts here.
Yeah, I was thinking more along the lines of the kml writer looking for
a template with a prefined name in the specific feature type directory,
using it if it exists, if not just doing what it does now.
Maybe the lookup could be:
1. Look for "kmlDescriptionTemplate" in "featureTypes/<the feture type>"
2. If 1 does not exist, look in the SLD
3. If nothing in the SLD, do what we do now
-Justin
Chris Holmes wrote:
The example is good, but I would like to make sure that people don't
_have_ to define the template in their SLD. Like they should be able to
just define a template for their featureType, and then get it as WMS
GetFeatureInfo output and KML output.
I also think it might be worthwhile to make it a WFS output as well -
it's an alternate way of displaying the information about the feature.
But this goes back to my whole goal of combining our factories for
GetFeatureInfo and GetFeature, since they do essentially the same thing.
C
Brent Owens wrote:
I quickly read it and so far I think it looks pretty good. I put an
example at the bottom on the potential use in KML and SLD.
Brent Owens
(The Open Planning Project)
Justin Deoliveira wrote:
Hi all,
As of late there has been talk of adding the ability to use templates in
GeoServer. So I have done a bit of research and whipped up my
thoughts here.
-------------------------------------------------------------------------
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
Yeah, I was thinking more along the lines of the kml writer looking for
a template with a prefined name in the specific feature type directory,
using it if it exists, if not just doing what it does now.
Maybe the lookup could be:
1. Look for "kmlDescriptionTemplate" in "featureTypes/<the feture type>"
2. If 1 does not exist, look in the SLD
3. If nothing in the SLD, do what we do now
-Justin
Chris Holmes wrote:
The example is good, but I would like to make sure that people don't
_have_ to define the template in their SLD. Like they should be able to
just define a template for their featureType, and then get it as WMS
GetFeatureInfo output and KML output.
I also think it might be worthwhile to make it a WFS output as well -
it's an alternate way of displaying the information about the feature.
But this goes back to my whole goal of combining our factories for
GetFeatureInfo and GetFeature, since they do essentially the same thing.
C
Brent Owens wrote:
I quickly read it and so far I think it looks pretty good. I put an
example at the bottom on the potential use in KML and SLD.
Brent Owens
(The Open Planning Project)
Justin Deoliveira wrote:
Hi all,
As of late there has been talk of adding the ability to use templates in
GeoServer. So I have done a bit of research and whipped up my
thoughts here.
-------------------------------------------------------------------------
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
Yeah, I was thinking more along the lines of the kml writer looking for
a template with a prefined name in the specific feature type directory,
using it if it exists, if not just doing what it does now.
Maybe the lookup could be:
1. Look for "kmlDescriptionTemplate" in "featureTypes/<the feture type>"
2. If 1 does not exist, look in the SLD
3. If nothing in the SLD, do what we do now
So the idea is to have templates identified by name? GetFeatureInfoHTMLTemplate, GetFeatureHTMLTemplate, and so on?
We have many things that could use templating, a naming convention
like <Service><Request><Format>Template.xxx could address most of them.
Hum, in many requests we could have a separate GET parameter too...
yes I would like to possibly see a separate parameter in the request so a user could dynamically select what template they want to use. It could override the default template.
Brent Owens
(The Open Planning Project)
Andrea Aime wrote:
Chris Holmes ha scritto:
Sounds good.
Chris
Justin Deoliveira wrote:
Yeah, I was thinking more along the lines of the kml writer looking for
a template with a prefined name in the specific feature type directory,
using it if it exists, if not just doing what it does now.
Maybe the lookup could be:
1. Look for "kmlDescriptionTemplate" in "featureTypes/<the feture type>"
2. If 1 does not exist, look in the SLD
3. If nothing in the SLD, do what we do now
So the idea is to have templates identified by name? GetFeatureInfoHTMLTemplate, GetFeatureHTMLTemplate, and so on?
We have many things that could use templating, a naming convention
like <Service><Request><Format>Template.xxx could address most of them.
Hum, in many requests we could have a separate GET parameter too...
Can we also consider something "easier" along the lines of simple search and replace? Take a look at the confluence template syntax where they replace @WORD@anonymised.com
If we are considering more complicated things like Velocity can we consider JET as an easier alternative.
Jody
Hi all,
As of late there has been talk of adding the ability to use templates in
GeoServer. So I have done a bit of research and whipped up my thoughts here.
Can we also consider something "easier" along the lines of simple search
and replace? Take a look at the confluence template syntax where they
replace @WORD@anonymised.com
Like you mean forgoing templates all together? Hmm... Not sure a simple
search and replace will do it. I imagine users will want some sort of
functionality like simple string manipulation, formatting, etc...
If we are considering more complicated things like Velocity can we
consider JET as an easier alternative.
JET is *way* more complicated then any of the alternatives imho. At
least it was the last time I looked at it. For one in order to load
templates dynamically you need an eclipse runtime. I could never get it
to work outside of eclipse. It also drags along a pile of eclipse
dependencies which we could not afford.
Maybe it has gotten nicer to non-eclipse apps latley. Not sure, have not
looked at it in a while. Please feel free to evaluate and add to the
list of candidates.
Jody
Hi all,
As of late there has been talk of adding the ability to use templates in
GeoServer. So I have done a bit of research and whipped up my thoughts here.
Like you mean forgoing templates all together? Hmm... Not sure a simple
search and replace will do it. I imagine users will want some sort of
functionality like simple string manipulation, formatting, etc...
I think people would like simple first ... wait until they hit the limits (and you have some real users)
before breaking out the complicated stick.
If we are considering more complicated things like Velocity can we consider JET as an easier alternative.
JET is *way* more complicated then any of the alternatives imho. At
least it was the last time I looked at it. For one in order to load
templates dynamically you need an eclipse runtime. I could never get it
to work outside of eclipse. It also drags along a pile of eclipse
dependencies which we could not afford.
That is the opposite of my experience? I am talking straight normal Java only jar which basically does
something like a JSP page. The attributes you can play with in your <% %> tags can come from a
Map or Java Bean (and you can teach it other things like Feature).
Maybe it has gotten nicer to non-eclipse apps latley. Not sure, have not
looked at it in a while. Please feel free to evaluate and add to the
list of candidates.
The end result looks like javascript mostly. Indeed you may want to consider javascript as an alternative
as well.
Yeah, I was thinking more along the lines of the kml writer looking for
a template with a prefined name in the specific feature type directory,
using it if it exists, if not just doing what it does now.
Maybe the lookup could be:
1. Look for "kmlDescriptionTemplate" in "featureTypes/<the feture type>"
2. If 1 does not exist, look in the SLD
3. If nothing in the SLD, do what we do now
Another suggestion. If we end up in 3, make so that we're using a template engine an a user visible template anyways.
Advantages:
* standard templates would become samples
* if you just want to modify things for every request independent
of the feature type, you just modify the default one
About the implementation, we could have the standard templates
in the data directory. If the data directory is empty, we can
have a copy of the standard templates in classpath and dump
them on the data directory. This goes along the lines of creating
the data directory pieces when missing, instead of complaining.
Yeah, I was thinking more along the lines of the kml writer looking for
a template with a prefined name in the specific feature type directory,
using it if it exists, if not just doing what it does now.
Maybe the lookup could be:
1. Look for "kmlDescriptionTemplate" in "featureTypes/<the feture type>"
2. If 1 does not exist, look in the SLD
3. If nothing in the SLD, do what we do now
Another suggestion. If we end up in 3, make so that we're using a
template engine an a user visible template anyways.
Advantages:
* standard templates would become samples
* if you just want to modify things for every request independent
of the feature type, you just modify the default one
Makes sense, we could throw the "default" template under "templates" in
the data directory, and they can modify that if they wish to set things
globally. As well as being able to override on a per feature type basis.
About the implementation, we could have the standard templates
in the data directory. If the data directory is empty, we can
have a copy of the standard templates in classpath and dump
them on the data directory. This goes along the lines of creating
the data directory pieces when missing, instead of complaining.
JET is *way* more complicated then any of the alternatives imho. At
least it was the last time I looked at it. For one in order to load
templates dynamically you need an eclipse runtime. I could never get it
to work outside of eclipse. It also drags along a pile of eclipse
dependencies which we could not afford.
That is the opposite of my experience? I am talking straight normal Java only jar which basically does
something like a JSP page. The attributes you can play with in your <% %> tags can come from a
Map or Java Bean (and you can teach it other things like Feature).
I'm wondering, if we went the Jet route, would that lock us using Eclipse for Geoserver development even more than now?
I mean, is it possible to develop new JET templates without it?
We recently had quite an annoying experience with EMF: Justin used it
to generate the classes to handle GML3 and WFS, because EMF was the
only library that could handle GML3 intricacies. I had to extend
those for WFS, and the result was that the extension was incompatible,
because I used a more recent EMF release that did break compatibility,
my generated classes were trying to call methods in the superclasses
that weren't there. Happily Justin was able to regenerate all the
classes with the newer version of EMF, but that required new testing
and so on, not very pleasing from a maintenance point of view.
In my opinion, the less we depend on a specific IDE, the better.
I would be tempted to try out IDEA, for example, but how can I knowing
that I would not be able to hack anymore on the EMF stuff?
JET is *way* more complicated then any of the alternatives imho. At
least it was the last time I looked at it. For one in order to load
templates dynamically you need an eclipse runtime. I could never get it
to work outside of eclipse. It also drags along a pile of eclipse
dependencies which we could not afford.
That is the opposite of my experience? I am talking straight normal Java only jar which basically does
something like a JSP page. The attributes you can play with in your <% %> tags can come from a
Map or Java Bean (and you can teach it other things like Feature).
I'm wondering, if we went the Jet route, would that lock us using Eclipse for Geoserver development even more than now?
I mean, is it possible to develop new JET templates without it?
Hi Andrea - JET is *really* simple - it is just a step up from search and replace. The only
reason I am recommending it as it is halfway between search and replace and the harder things like velocity.
We recently had quite an annoying experience with EMF: Justin used it
to generate the classes to handle GML3 and WFS, because EMF was the
only library that could handle GML3 intricacies. I had to extend
those for WFS, and the result was that the extension was incompatible,
because I used a more recent EMF release that did break compatibility,
my generated classes were trying to call methods in the superclasses
that weren't there. Happily Justin was able to regenerate all the
classes with the newer version of EMF, but that required new testing
and so on, not very pleasing from a maintenance point of view.
Note EMF is something to capture a model (like UML). Java Emitter template would
of just been used to do seach and replace kind of stuff, mapping sections of that model
into blanks in the template.
The data access stuff is almost the same as like bean shell or something - very direct.
In my opinion, the less we depend on a specific IDE, the better.
I would be tempted to try out IDEA, for example, but how can I knowing
that I would not be able to hack anymore on the EMF stuff?
So nothing to do with IDE, EMF or anything else. It is just annoying that they
have Eclipse in the name.
