You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wookie.apache.org by Scott Wilson <sc...@gmail.com> on 2010/04/30 15:25:03 UTC
Should we use a templating engine for API views?
Hi everyone,
Just looking over the various classes in the org.apache.wookie.helpers package I was wondering if we should be replacing the various methods like "toXml()" and "toJSON() in WidgetHelper, WidgetInstanceHelper (etc) with a templating engine to generate the various representations of classes we expose in the API.
Looking over the API we have 6 classes to represent using XML, and also potentially in JSON and Atom (at least in the case of Widget), so around 13 templates.
I've had a brief look at a few OSS templating engines:
Apache Velocity (http://velocity.apache.org/)
Tea (http://teatrove.sourceforge.net/)
FreeMarker (http://freemarker.sourceforge.net/)
There is a list of others here:
http://java-source.net/open-source/template-engines
I think the "pros" for using templating engines are:
- templating languages are easier to work with than Java code,
- implementers can edit templates directly without touching the source (e.g. to remove or include properties, or use different markup, etc.)
- formatting code is removed from the java source (no more clumsy string building)
The "cons" are:
- it adds more dependencies
- it will take effort to do
What do you think? Any experience in using these? Do you think its worth the effort?
S
Re: Should we use a templating engine for API views?
Posted by Scott Wilson <sc...@gmail.com>.
On 30 Apr 2010, at 21:20, Copeland, Bryan wrote:
>> I was only really thinking in terms of how we expose the API methods of the Wookie server, so things like "/wookie/widgets?format=atom" rather than the widgets themselves which should just use "normal" HTML, CSS and JS. So not as big a risk (or payoff) really.
>
> Oh, I thought it might be an option to use it to stick dynamic data into some local widgets. If it's just intended for formatting API calls it almost sounds like a case for using RESTlet or Jersey or something like that instead? They tend to let you bind data models for many different formats, with native support for XML, SOAP, RSS, Atom, JSON, etc; with URL-templating and few, if any, other dependencies...
>
> RESTlet: http://www.restlet.org/
> Jersey (JAX-RS): https://jersey.dev.java.net/
>
> Maybe I'm misunderstanding what you wanted to accomplish with the Template Engine though?
No, you've got it right there. I did look at RESTlet a while back, and Apache Wink, but it seemed a bit OTT at the time. But worth revisiting I think.
> Also, maybe an obvious question if I dig through some previous email but do you have a link for the Issue Tracker submissions?
No worries, its here: https://issues.apache.org/jira/browse/WOOKIE
>
> Thanks,
>
> Bryan
>
>
>
>
>
>
> -----Original Message-----
> From: Scott Wilson [mailto:scott.bradley.wilson@gmail.com]
> Sent: April 30, 2010 12:50 PM
> To: wookie-dev@incubator.apache.org
> Subject: Re: Should we use a templating engine for API views?
>
> On 30 Apr 2010, at 16:36, Copeland, Bryan wrote:
>
>> Only have experience with Velocity of those listed so can't comment on the others, but wouldn't it make sense to "eat your own dogfood" (keep it in the Apache family), unless of course one of the others were that much more superior. At first glance, looks like they are mostly older and less active projects though.
>
> Some of them do seem to be less active, though FreeMarker seems pretty common (its used in some other Apache projects) - presumably as it pretty light and doesn't have any additional dependencies.
>
>> IMHO:
>> Templating Engines generally mean more modularity, in exchanged for high code dependency on the library used. It's also another point of failure. As long as it was designed so that using the chosen Template Engine was an *optional* feature, rather than requiring all widget models to pass data through the template or support it, that would probably be a good idea. I think the goal is to keep the Widgets themselves and their logic as simple as possible (even goes for the XML and Atom/JSON representations).
>
>> Especially if the Template Engine was able to be activated or deactivated through XML config, build properties or the like, that makes it lower risk for organizations adopting Wookie as their Widget container framework. (But that probably comes with even more coding and may or may not be possible depending on the Template Engine, so I shouldn't talk)
>
> I was only really thinking in terms of how we expose the API methods of the Wookie server, so things like "/wookie/widgets?format=atom" rather than the widgets themselves which should just use "normal" HTML, CSS and JS. So not as big a risk (or payoff) really.
>
>> Speaking of simple widgets, what is the process for submitting a sample widget?
>> I've got a couple useful pure-AJAX examples that pull data from Web Services cross-domain without requiring a Proxy... let me know if you'd like to include them,
>
> Create an issue in the tracker and attach them and we can review them - there is a button on the attachments form to say you're submitting them as contributed work ("Grant license to ASF for inclusion in ASF works (as per the Apache License §5)".
>
>> Bryan
>>
>> -----Original Message-----
>> From: Scott Wilson [mailto:scott.bradley.wilson@gmail.com]
>> Sent: April 30, 2010 10:25 AM
>> To: wookie-dev
>> Subject: Should we use a templating engine for API views?
>>
>> Hi everyone,
>>
>> Just looking over the various classes in the org.apache.wookie.helpers package I was wondering if we should be replacing the various methods like "toXml()" and "toJSON() in WidgetHelper, WidgetInstanceHelper (etc) with a templating engine to generate the various representations of classes we expose in the API.
>>
>> Looking over the API we have 6 classes to represent using XML, and also potentially in JSON and Atom (at least in the case of Widget), so around 13 templates.
>>
>> I've had a brief look at a few OSS templating engines:
>>
>> Apache Velocity (http://velocity.apache.org/)
>> Tea (http://teatrove.sourceforge.net/)
>> FreeMarker (http://freemarker.sourceforge.net/)
>>
>> There is a list of others here:
>>
>> http://java-source.net/open-source/template-engines
>>
>> I think the "pros" for using templating engines are:
>> - templating languages are easier to work with than Java code,
>> - implementers can edit templates directly without touching the source (e.g. to remove or include properties, or use different markup, etc.)
>> - formatting code is removed from the java source (no more clumsy string building)
>>
>> The "cons" are:
>> - it adds more dependencies
>> - it will take effort to do
>>
>> What do you think? Any experience in using these? Do you think its worth the effort?
>>
>> S
>
Re: Should we use a templating engine for API views?
Posted by Luciano Resende <lu...@gmail.com>.
On Fri, Apr 30, 2010 at 1:20 PM, Copeland, Bryan
<Br...@nrc-cnrc.gc.ca> wrote:
>>I was only really thinking in terms of how we expose the API methods of the Wookie server, so things like "/wookie/widgets?format=atom" rather than the widgets themselves which should just use "normal" HTML, CSS and JS. So not as big a risk (or payoff) really.
>
> Oh, I thought it might be an option to use it to stick dynamic data into some local widgets. If it's just intended for formatting API calls it almost sounds like a case for using RESTlet or Jersey or something like that instead? They tend to let you bind data models for many different formats, with native support for XML, SOAP, RSS, Atom, JSON, etc; with URL-templating and few, if any, other dependencies...
>
> RESTlet: http://www.restlet.org/
> Jersey (JAX-RS): https://jersey.dev.java.net/
>
> Maybe I'm misunderstanding what you wanted to accomplish with the Template Engine though?
>
I don't know the full details about the requirements/scenarios, but if
you are talking about REST/JAX-RS we also have Apache Wink and Apache
CXF that are JAX-RS compliant. I'm also working in some REST features
for Apache Tuscany, but I'm not sure if this applies here.
> Also, maybe an obvious question if I dig through some previous email but do you have a link for the Issue Tracker submissions?
>
> Thanks,
>
> Bryan
BTW Brian, I'd be interested in looking into your widgets and how they
are handling the cross-domain stuff if that is available somewhere.
--
Luciano Resende
http://people.apache.org/~lresende
http://twitter.com/lresende1975
http://lresende.blogspot.com/
RE: Should we use a templating engine for API views?
Posted by "Copeland, Bryan" <Br...@nrc-cnrc.gc.ca>.
>I was only really thinking in terms of how we expose the API methods of the Wookie server, so things like "/wookie/widgets?format=atom" rather than the widgets themselves which should just use "normal" HTML, CSS and JS. So not as big a risk (or payoff) really.
Oh, I thought it might be an option to use it to stick dynamic data into some local widgets. If it's just intended for formatting API calls it almost sounds like a case for using RESTlet or Jersey or something like that instead? They tend to let you bind data models for many different formats, with native support for XML, SOAP, RSS, Atom, JSON, etc; with URL-templating and few, if any, other dependencies...
RESTlet: http://www.restlet.org/
Jersey (JAX-RS): https://jersey.dev.java.net/
Maybe I'm misunderstanding what you wanted to accomplish with the Template Engine though?
Also, maybe an obvious question if I dig through some previous email but do you have a link for the Issue Tracker submissions?
Thanks,
Bryan
-----Original Message-----
From: Scott Wilson [mailto:scott.bradley.wilson@gmail.com]
Sent: April 30, 2010 12:50 PM
To: wookie-dev@incubator.apache.org
Subject: Re: Should we use a templating engine for API views?
On 30 Apr 2010, at 16:36, Copeland, Bryan wrote:
> Only have experience with Velocity of those listed so can't comment on the others, but wouldn't it make sense to "eat your own dogfood" (keep it in the Apache family), unless of course one of the others were that much more superior. At first glance, looks like they are mostly older and less active projects though.
Some of them do seem to be less active, though FreeMarker seems pretty common (its used in some other Apache projects) - presumably as it pretty light and doesn't have any additional dependencies.
> IMHO:
> Templating Engines generally mean more modularity, in exchanged for high code dependency on the library used. It's also another point of failure. As long as it was designed so that using the chosen Template Engine was an *optional* feature, rather than requiring all widget models to pass data through the template or support it, that would probably be a good idea. I think the goal is to keep the Widgets themselves and their logic as simple as possible (even goes for the XML and Atom/JSON representations).
> Especially if the Template Engine was able to be activated or deactivated through XML config, build properties or the like, that makes it lower risk for organizations adopting Wookie as their Widget container framework. (But that probably comes with even more coding and may or may not be possible depending on the Template Engine, so I shouldn't talk)
I was only really thinking in terms of how we expose the API methods of the Wookie server, so things like "/wookie/widgets?format=atom" rather than the widgets themselves which should just use "normal" HTML, CSS and JS. So not as big a risk (or payoff) really.
> Speaking of simple widgets, what is the process for submitting a sample widget?
> I've got a couple useful pure-AJAX examples that pull data from Web Services cross-domain without requiring a Proxy... let me know if you'd like to include them,
Create an issue in the tracker and attach them and we can review them - there is a button on the attachments form to say you're submitting them as contributed work ("Grant license to ASF for inclusion in ASF works (as per the Apache License §5)".
> Bryan
>
> -----Original Message-----
> From: Scott Wilson [mailto:scott.bradley.wilson@gmail.com]
> Sent: April 30, 2010 10:25 AM
> To: wookie-dev
> Subject: Should we use a templating engine for API views?
>
> Hi everyone,
>
> Just looking over the various classes in the org.apache.wookie.helpers package I was wondering if we should be replacing the various methods like "toXml()" and "toJSON() in WidgetHelper, WidgetInstanceHelper (etc) with a templating engine to generate the various representations of classes we expose in the API.
>
> Looking over the API we have 6 classes to represent using XML, and also potentially in JSON and Atom (at least in the case of Widget), so around 13 templates.
>
> I've had a brief look at a few OSS templating engines:
>
> Apache Velocity (http://velocity.apache.org/)
> Tea (http://teatrove.sourceforge.net/)
> FreeMarker (http://freemarker.sourceforge.net/)
>
> There is a list of others here:
>
> http://java-source.net/open-source/template-engines
>
> I think the "pros" for using templating engines are:
> - templating languages are easier to work with than Java code,
> - implementers can edit templates directly without touching the source (e.g. to remove or include properties, or use different markup, etc.)
> - formatting code is removed from the java source (no more clumsy string building)
>
> The "cons" are:
> - it adds more dependencies
> - it will take effort to do
>
> What do you think? Any experience in using these? Do you think its worth the effort?
>
> S
Re: Should we use a templating engine for API views?
Posted by Scott Wilson <sc...@gmail.com>.
On 30 Apr 2010, at 16:36, Copeland, Bryan wrote:
> Only have experience with Velocity of those listed so can't comment on the others, but wouldn't it make sense to "eat your own dogfood" (keep it in the Apache family), unless of course one of the others were that much more superior. At first glance, looks like they are mostly older and less active projects though.
Some of them do seem to be less active, though FreeMarker seems pretty common (its used in some other Apache projects) - presumably as it pretty light and doesn't have any additional dependencies.
> IMHO:
> Templating Engines generally mean more modularity, in exchanged for high code dependency on the library used. It's also another point of failure. As long as it was designed so that using the chosen Template Engine was an *optional* feature, rather than requiring all widget models to pass data through the template or support it, that would probably be a good idea. I think the goal is to keep the Widgets themselves and their logic as simple as possible (even goes for the XML and Atom/JSON representations).
> Especially if the Template Engine was able to be activated or deactivated through XML config, build properties or the like, that makes it lower risk for organizations adopting Wookie as their Widget container framework. (But that probably comes with even more coding and may or may not be possible depending on the Template Engine, so I shouldn't talk)
I was only really thinking in terms of how we expose the API methods of the Wookie server, so things like "/wookie/widgets?format=atom" rather than the widgets themselves which should just use "normal" HTML, CSS and JS. So not as big a risk (or payoff) really.
> Speaking of simple widgets, what is the process for submitting a sample widget?
> I've got a couple useful pure-AJAX examples that pull data from Web Services cross-domain without requiring a Proxy... let me know if you'd like to include them,
Create an issue in the tracker and attach them and we can review them - there is a button on the attachments form to say you're submitting them as contributed work ("Grant license to ASF for inclusion in ASF works (as per the Apache License §5)".
> Bryan
>
> -----Original Message-----
> From: Scott Wilson [mailto:scott.bradley.wilson@gmail.com]
> Sent: April 30, 2010 10:25 AM
> To: wookie-dev
> Subject: Should we use a templating engine for API views?
>
> Hi everyone,
>
> Just looking over the various classes in the org.apache.wookie.helpers package I was wondering if we should be replacing the various methods like "toXml()" and "toJSON() in WidgetHelper, WidgetInstanceHelper (etc) with a templating engine to generate the various representations of classes we expose in the API.
>
> Looking over the API we have 6 classes to represent using XML, and also potentially in JSON and Atom (at least in the case of Widget), so around 13 templates.
>
> I've had a brief look at a few OSS templating engines:
>
> Apache Velocity (http://velocity.apache.org/)
> Tea (http://teatrove.sourceforge.net/)
> FreeMarker (http://freemarker.sourceforge.net/)
>
> There is a list of others here:
>
> http://java-source.net/open-source/template-engines
>
> I think the "pros" for using templating engines are:
> - templating languages are easier to work with than Java code,
> - implementers can edit templates directly without touching the source (e.g. to remove or include properties, or use different markup, etc.)
> - formatting code is removed from the java source (no more clumsy string building)
>
> The "cons" are:
> - it adds more dependencies
> - it will take effort to do
>
> What do you think? Any experience in using these? Do you think its worth the effort?
>
> S
RE: Should we use a templating engine for API views?
Posted by "Copeland, Bryan" <Br...@nrc-cnrc.gc.ca>.
Only have experience with Velocity of those listed so can't comment on the others, but wouldn't it make sense to "eat your own dogfood" (keep it in the Apache family), unless of course one of the others were that much more superior. At first glance, looks like they are mostly older and less active projects though.
IMHO:
Templating Engines generally mean more modularity, in exchanged for high code dependency on the library used. It's also another point of failure. As long as it was designed so that using the chosen Template Engine was an *optional* feature, rather than requiring all widget models to pass data through the template or support it, that would probably be a good idea. I think the goal is to keep the Widgets themselves and their logic as simple as possible (even goes for the XML and Atom/JSON representations).
Especially if the Template Engine was able to be activated or deactivated through XML config, build properties or the like, that makes it lower risk for organizations adopting Wookie as their Widget container framework. (But that probably comes with even more coding and may or may not be possible depending on the Template Engine, so I shouldn't talk)
Speaking of simple widgets, what is the process for submitting a sample widget?
I've got a couple useful pure-AJAX examples that pull data from Web Services cross-domain without requiring a Proxy... let me know if you'd like to include them,
Bryan
-----Original Message-----
From: Scott Wilson [mailto:scott.bradley.wilson@gmail.com]
Sent: April 30, 2010 10:25 AM
To: wookie-dev
Subject: Should we use a templating engine for API views?
Hi everyone,
Just looking over the various classes in the org.apache.wookie.helpers package I was wondering if we should be replacing the various methods like "toXml()" and "toJSON() in WidgetHelper, WidgetInstanceHelper (etc) with a templating engine to generate the various representations of classes we expose in the API.
Looking over the API we have 6 classes to represent using XML, and also potentially in JSON and Atom (at least in the case of Widget), so around 13 templates.
I've had a brief look at a few OSS templating engines:
Apache Velocity (http://velocity.apache.org/)
Tea (http://teatrove.sourceforge.net/)
FreeMarker (http://freemarker.sourceforge.net/)
There is a list of others here:
http://java-source.net/open-source/template-engines
I think the "pros" for using templating engines are:
- templating languages are easier to work with than Java code,
- implementers can edit templates directly without touching the source (e.g. to remove or include properties, or use different markup, etc.)
- formatting code is removed from the java source (no more clumsy string building)
The "cons" are:
- it adds more dependencies
- it will take effort to do
What do you think? Any experience in using these? Do you think its worth the effort?
S