>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:[email protected]] Sent: April 30, 2010 12:50 PM To: [email protected] 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:[email protected]] > 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
