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:[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 >
