Hi Geir,
As you suggested, I'm moving this discussion to the Velocity list since its
really not related to Turbine. As a caveat to this discussion, please keep
in mind that I am not a Velocity developer; I've looked at the docs, but
that's it (so feel free to correct any misunderstanding I might have).
> 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.
I agree that you have to bind code with content at some point; the question
is where. One of the basic premises of the XMLC approach is that all
template content must remain valid markup, so that it can be edited by
designers using any basic 3rd party design tool. Consequently, with an XMLC
based approach (and Barracuda builds on this), the binding occurs by using
ids in the markup; there's never any programming logic in the markup.
With pure XMLC, the developer has to write servlet code to process the known
ids in the template. With the Barracuda template component, the designer can
associate directives with an id (or directly with an element in the markup).
The keeps the template valid in terms of markup, while still allowing for
the benefits of template driven development that you identified (designer
freedom w/minimal programmer participation).
> 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.
XMLC doesn't do any kind of MVC one way or the other (just like DOM
doesn't). Barracuda _does_ do MVC; both Model 2 and true MVC. One of my
gripes about MVC is that terms seems to get terribly misused in the web-app
space (and I think Sun started this by trying to capitalize on the success
of MVC in the Swing/client-server arena). I view MVC as something very
similar to what you find in Swing: strongly typed interfaces that exist in
the context of a component model; I view Model 2 as an "MVC-ish approach"
that bears some high level similarities to MVC. You might want to check out
http://barracuda.enhydra.org/cvs_source/Barracuda/docs/comp/mvc.html for a
better understanding of my definitions.
> 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.
I'm not sure if I can answer your question very clearly. Remember, I don't
know Velocity all that well ;-)
The 'containing' device that holds a BTemplate could be
a) nothing (ie. if the template component is the root component)
b) some other component (because Barracuda components are like Swing
components in that they can contain other components).
Maybe this will help; in Barracuda the typical markup rendering process goes
something like this:
-load a DOM object
-create a component hierarchy, binding components to the appropriate places
in the DOM
-render component hierarchy (which causes components to update the DOM
structure)
-render the DOM hierarchy (which yields the final markup)
Keep in mind that Barracuda really lives at a lower level than a lot of
presentation frameworks. Its trying to apply client-server development
techniques to the server-side development paradigm. Much of what we're doing
is building enabling infrastructure upon which other higher-level
presentation frameworks can then be based. For instance, it would be
entirely possible to build a typical Model 2 template framework (like you'd
find in Turbine/Velocity) on top of Barracuda; it's also possible to build a
framework that is driven by startcharts, or hierarchical mvc, or is
assembled via XML descriptors. We believe there are a lot of different
approachs to building webapps that vary depending on problem
domain--Barracuda attempts to abstract out the low-level commonality (using
components, events) to make it easier to build different kinds of high level
frameworks.
I don't know if that helps at all...
> 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'.
In addition to the above infrastructure goals, we have a the primary
requirement that markup stays valid at all times, plus the goal that
Barracuda support more than just template driven approaches.
> 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).
Ahhh, now this sounds interesting! One of the things I am very interested in
doing is seeing how we can support other rendering approaches within the
context of Barracuda. It would be very cool if we could create a 'BVelocity'
component so that if someone _wanted_ to use the Velocity engine from inside
Barracuda they could.
Would you have any interest in helping me figure out if this is doable?
> 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 :)
Barracuda's BTemplate supports Iterate_Start, Iterate_Next, Iterate_End,
Get_Data, Set_Attr, and Discard. A designer is also allowed to use custom
directives. As I said in the original email, this has been kept
intentionally simple. Many XMLC developers object to any kind of template
approaches at all; I disagree with them in this regard, but at the same time
I didn't want to go and try to develop a super robust template mechanism
either...hence my interest in trying to support other more powerful template
engines (like Velocity).
> I would be interested in seeing some use-cases where you think Velocity
> isn't appropriate.
Well, here are a couple possibilities:
a) where its a requirement that the template be valid *ML that can be edited
using 3rd party design tools (how do you guys deal with this?)
b) where I want to use several different methods of rendering the same page
(with BTemplate, its quite frequent for the model to return other components
like a BList, BSelect, BLink, etc to handle rendering spcific UI elements)
I'd definitely be interested in discussing this further (although I need to
brush up on my understanding of Velocity first). As I said at the top,
please feel free to use this as an opportunity to help correct any
misconceptions I might have...I want to accurately understand Velocity.
I appreciate your comments and look forward to hearing your response...
Christian
------------------------------------------------
Christian Cryder [[EMAIL PROTECTED]]
Barracuda - MVC Component Framework for Webapps
http://barracuda.enhydra.org
------------------------------------------------
"What a great time to be a Geek"
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
> Behalf Of Geir Magnusson Jr.
> Sent: Saturday, June 09, 2001 12:28 PM
> To: [EMAIL PROTECTED]
> Subject: Re: What about Barracuda? (Was Re: JavaOne Struts BOF)
>
>
> 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]
>
