I normally just lurk on this list, but since you're talking about
Velocity...
Christian Cryder wrote:
>
> I normally just lurk on this list, but since you're asking about Barracuda,
> I'll try to explain.
>
> > The main difference between Turbine and Barracuda that I read
> > about on the website seems to be the choice between Velocity
> > or XMLC2
>
> Hmm...yes and no. Its not so much a difference between template engines, as
> it is a difference between template engine _paradigms_. Most template
> engines (and I believe this includes Velocity) allow you to embed logic in
> the template, usually by way of a scripting language. The XMLC approach (and
> it hasn't changed between version 1 and 2, btw) is to compile a template
> document to a Java object that can be manipulated programatically using the
> DOM interfaces.
>
> In the traditional template approach, you're manipulating the template from
> within the template; in the DOM template approach, you're manipulating the
> template externally from servlet code. Fans of XMLC will argue this yields
> better seperation of code from content.
I guess I don't completely understand. It sounds like you *have* to
bind code with content to produce output - in other words, specific code
is needed to produce the output, whereas in the template case,
especially with a Model2 approach for web usage, once the accessable
data set is defined, the desginer is free to do what they need w/o
programmer participation.
Also, I guess that Velocity wouldn't be bundled into the 'traditional'
bucket, as it provides an API to allow you to dynamically construct an
output stream from within code through rendering bits of template code
w/o ever having a template in existance anywhere. Useful for dynamic
content generation where bits of separate 'stuff' need to be brought
together, or where a middle-step processing facility is needed.
> Now, while I think XMLC is great technology, I still think there are some
> problems with it. First, the DOM interfaces are pretty low-level; if you
> need to drastically alter the structure of the template, it can be a lot of
> code to do so. Second, XMLC uses what some people call "push Model 2", where
> your servlet code is pushing the logic into the template, rather than
> allowing the template to pull the necessary data out of the model. This
> requires the developer to have an implicit knowledge of the structure of the
> document, meaning if the designer wants to dramatically change the ordering
> of the screen, chances are the developer is going to have to make changes.
This sounds like it terribly breaks the MVC pattern - I am not sure if
XMLC claims to support it, but from this description, it sounds like it
isn't.
> Barracuda addresses both of these issues. First, in order to make it easier
> to manipulate the DOM, we created a set of strongly typed MVC components
> (similar to Swing) that can be bound to nodes in the DOM. So you take a
> template, bind components to the appropriate nodes, and then just set data
> through the component interfaces (ie. implementing a Model interface). This
> means a Barracuda developer rarely needs to interact with the DOM
> interfaces. It also means that Barracuda is not tightly coupled with XMLC
> (although most of our examples use XMLC)--Barracuda can be used to
> manipulate any DOM objects, whether they come from XMLC or some other
> source.
That sounds neat...
> To solve the second issue, we created a BTemplate component which basically
> brings template driven "pull Model 2" to DOM templates. This is very similar
> to the traditional template engine approach...the component parses the
> template and as it encounters "directives", it queries data from the
> template's models and substitutes it in. This makes the whole thing very
> flexible: a designer can radically revamp a page and there are no developer
> changes needed.
As it should be :)
> There are still some differences between this approach and something like
> Velocity. In Barracuda, the BTemplate component is just that: a
> component--it can be freely intermixed with other components, and can be
> used where it makes sense or avoided where it doesn't. It essentially allows
> you to apply templating processing to just a portion of the template page,
> not the whole thing. Plus, it provides a strongly typed MVC model interface,
> just like the other Barracuda components. Plus, all Barracuda models can
> return more than just String data--they can also return DOM Nodes (making it
> easy to insert chunks of markup), or they can return other Barracuda
> components (just like in Swing, where you can put any component inside other
> components). This makes it very easy to use granular components inside a
> larger template component.
Here I don't follow. I am assuming that there is some kind of
'container' or definition of a 'page'. ( I am assuming we are talking
about page-oriented web output...). If BTemplate is just a portion,
what is the 'containing' device that holds the BTemplate element?
I don't know if I asked that question clearly.
The reason why I am poking at this is that I don't see much of what you
say as examples of differences. For example, the model elements in the
context accessible by a Velocity template can return anything - for
example a DOM tree, in JDOM parlance
#set($root = $doc.getRootElement() )
#foreach( $node in $root.getChildren() )
do something with $node
#end
if you stuck a jdom document into the context as 'doc'.
Also, it's pretty easy to wrap Velocity as a 'component' for use in
other systems, where you might want to mix some of the things Velocity
is good at ( looping and logic ) with other systems that are challenged
in that area (such as XSLT). For example, a client of mine has a system
that uses both XSLT and Velocity intermixed to layout, style and render
XML-based content for web use.
Maybe what you are saying is that there isn't an uber-framework for uses
like this provided by Velocity.... to that end, that isn't the domain of
Velocity. That is what Turbine is supposed to address where relevant.
Velocity 'wants' to be a rich and functional general template engine,
w/o directly supporting or constraining specific use-cases.
> This componetization also enables us to keep the whole "directive set" very
> very simple for the BTemplate component. Most template approaches start with
> a very simple scripting language that unfortunately blooms in complexity in
> order to support all kinds of fringe logic that needs to be expressed in the
> template. In Barracuda, we limit complexity to 4 or 5 simple directives, and
> if you need something that is not supported you either define a custom
> directive or you use a different component. The fact that the whole system
> is based on components makes it easy for someone to develop custom
> components and experiment with different approaches. No ones locked into any
> one particular way of doing things.
I am not sure if I buy the claim at the top. We have been lucky in
Velocity. Because of the pioneering work of WebMacro, we were able to
have a good understanding of what really mattered, and work very hard to
keep things simple. #if(), #foreach(), #set(), #include(), #parse() are
the primary directives, with additional #elseif, #else, #end rounding it
out. And #macro(), of course :)
And while we do offer developers the ability to add custom directives,
the combination of a great 'macro' facility as well as solid community
support for helping solve problems has kept custom directive development
activity to zero, as far as I can tell, and as I believe it should be.
> > But since you can plug in any templating system you like into Turbine that
> > seems a bit of a moot point.
>
> Within Barracuda, the idea is that you should be able to apply templating to
> portions of a page; you shouldn't have to do it for the whole thing. Use it
> where it makes sense; don't where it doesn't. Barracuda makes it possible to
> take a template approach like you'd use within Velocity ("pull Model 2") as
> well as an XMLC type approach ("push Model 2"), and freely intermix them,
> not only within the same app but also within the same page.
Hm. It would be interesting to see what kind of 'container' we could
come up with to combine multiple template/output systems into a single
page... and if it really makes sense. I suspect it doesn't make sense
though, as in practice, you will most likely have a set of designers
working in a given technology on a project....
I would be interested in seeing some use-cases where you think Velocity
isn't appropriate. I don't claim that it is the Ultimate Solution for
Now and Forever(tm) and am interested in seeing unsolvable problems that
are in the problem domain it is supposed to cover.
I know this is a little off-topic for the Turbine list, so if this
thread is objectionable, I would love to continue with it on
velocity-user.
geir
--
Geir Magnusson Jr. [EMAIL PROTECTED]
System and Software Consulting
Developing for the web? See http://jakarta.apache.org/velocity/
You have a genius for suggesting things I've come a cropper with!
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
