You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@turbine.apache.org by John Thorhauer <jo...@zenplex.com> on 2001/06/08 00:29:32 UTC
Re: What about Barracuda? (Was Re: JavaOne Struts BOF)
On Friday 08 June 2001 01:09, Bruno Unna wrote:
>
> Nonetheless, since the time I started to use Turbine, Lutris came out
> with their first beta release of Barracuda, and since I'm yet in the
> early stages of my first project with Turbine, I'm feeling just as a
> fifteen years old girl about to make *the* decision of her life... :)
>
I dont know much about Barracuda but if you tell us what it does, maybe we
can help you understand how turbine might accomplish the saem thing,
John
--
********************************
** John Thorhauer
** john@zenplex.com
** take a look at:
** http://tambora.zenplex.org
** http://www.zenplex.org
** http://www.zenplex.com
********************************
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: What about Barracuda?
Posted by Scott Hernandez <sk...@eecs.berkeley.edu>.
----- Original Message -----
From: "Geir Magnusson Jr." <ge...@optonline.net>
Subject: Re: What about Barracuda?
> Scott Hernandez wrote:
> >
> > I wanted to get into more XSL stuff but I'm not sure this list is the
right
> > place... but let me make a few more generic comments.
>
> Strictly speaking, probably not. However, I am very interested in
> different frameworks and approaches to templating - we'll steal anything
> we can :) So as long as no one is really offended by this thread here,
> I'm in...
So until we get flak... I'll keep going. :)
[stuff here]
> I guess it would be very easy to make a tool that you drop in the
> context that lets the template specify the xml to read. Very pull-like.
Interesting idea... :)
> > > The real point I would make here is that I am not convinced that to
the
> > > average designer, the declarative, rules-based approach is obvious,
> > > especially when it seems that designers think more linearly, more
> > > procedurally. (Like they see a whole page in Dreamweaver...)
> >
> > I spend much time wondering and discussion how different people will
react,
> > and how easily they will adapt, if they need to learn XSL(T). It is a
very
> > serious question and one that is out there for all systems. I can only
hope
> > that as more people get involved in XML/XSLT familiarity will go up.
>
> it is a very serious issue. And since I don't completely buy the idea
> that all templates will be generated by tools, at least not for a while,
> it's important.
hmm... I don't see why tools couldn't do this. The problem, just like an XML
editor, is that we don't have a good UI/usability paradigm.
> If I recall, we weren't supposed to be programming at this point in time
either.
That is an infesting question... One of the reasons we wanted to have
multiple XSL transforms was so that the level/amount of programming logic
could be reduced/removed as you get towards the end. This approach could
reduce performance a little, maybe dramatically (we haven't done much
testing yet... but plan to). But it could also simplify what each type of
person (i.e. developer, html monkie, designer, etc.) would have to look at.
I've found building dynamic web applications is hard to do without some
simple presentation coding. Using loops, ifs, switches, and even vars have
their place for dynamic web applications. Take this scenario...
You want to list people, of which you are a member, and apply some simple
styling to the end result.
In a MVC framework let's assume that you have a controller that generates
the model, a simple map of user, indexed by name.
Now I want a view that creates a simple page with a HTML table with
alternating row colors, and hi-lights your entry.
Now, would you expect that the model would have the color that should be
used for each person? Probably not. You might go as far as indicating which
person get which type of coloring. But would most likely leave the actually
color selection and implementation for the view technology rendering the
view. This puts us in an unfortunate situation if you are not supposed to do
*any* programming at the view stage. If that is the case then the question
is just how much programming are you supposed/allowed to do at the view
stage.
>
> > In XSLT you can define everything in the root template.
> > <xsl:template match="/">
> > <html>
> > .... (with XSL:* tags for processing-instructions)
> > </html>
> > </xsl:template>
> >
> > Most editors, although I haven't specifically tested with dreamweaver,
> > should be able to handle this as you would expect. If you want to do
more
> > you can define and call/apply more templates.
>
> I am sure dreamweaver can deal with it. The problem is the model. I
> think of XSLT as 'event-driven' rather than linear. I find this very
> cool, by the way - however, I wonder if that notion can be well
> expressed in a GUI tool for your average designer.
The way a xsl:template match works is by changing the context to the matched
node. All XPath expressions used are relative to that node (context). In
the example above, the root match, the context is set to the root node. In
that example you can access the model, or any part of it, by selection,
using XPath expressions, rather than by event processing and template
matching. For example you can use an xsl:value-of element to print any value
from the context tree.
<!-- match root element -->
<xsl:template match="/">
<html>
<head>
<!-- print out the title -->
<title><xsl:value-of select="doc/contents/title" /></title>
</head>
<body>
<!-- loop through the people -->
<xsl:for-each select="doc/content/group1/people">
<!-- sort in the loop by lastname-->
<xsl:sort select="lastname"/>
<!-- current context is set to the active people node-->
...
</xsl:for-each>
</body>
</html>
</xsl:template>
[SNIP]
> Please do. Or we write one. <aside> I just started using TOAD for
> oracle. What a great tool... we need a java version of that </aside>
<aside>
<reply>
Yep, I used toad when I working with Oracle. It was pretty cool...
</reply>
</aside>
skot
Re: What about Barracuda?
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Scott Hernandez wrote:
>
> I wanted to get into more XSL stuff but I'm not sure this list is the right
> place... but let me make a few more generic comments.
Strictly speaking, probably not. However, I am very interested in
different frameworks and approaches to templating - we'll steal anything
we can :) So as long as no one is really offended by this thread here,
I'm in...
>
> ----- Original Message -----
> From: "Geir Magnusson Jr." <ge...@optonline.net>
> Subject: Re: What about Barracuda?
>
> [stuff was here...]
> > Rule-based:
> > > In XSLT things are rule-based, allowing for recursion, and matching
> follows
> > > (initially) the structure of the input DOM. So rules (xsl-template
> elements)
> > > allows for an easy transformation from the source. Adding XPath for
> select
> > > make things really powerful. This rule syntax is fairly simple and
> > > straight-forward but extremely powerful.
> >
> > Yes - you can use XPath on a DOM tree in Velocity as well. As for the
> > rules-based bit, I have been dreaming about a rules based transformer
> > using velocity. It don't think it will be that hard, except for the
> > conditional match part, but that's not too hard either.
>
> Does this require a java class of some sort? Or do you just work from a
> JDOM/DOM4J object that is in the context? I didn't see and type of
> load/parse xml directive. Is there such a thing?
Just drop the JDOM object into the context. (which I will note is a
java class 'of some sort')
I guess it would be very easy to make a tool that you drop in the
context that lets the template specify the xml to read. Very pull-like.
>
> > The real point I would make here is that I am not convinced that to the
> > average designer, the declarative, rules-based approach is obvious,
> > especially when it seems that designers think more linearly, more
> > procedurally. (Like they see a whole page in Dreamweaver...)
>
> I spend much time wondering and discussion how different people will react,
> and how easily they will adapt, if they need to learn XSL(T). It is a very
> serious question and one that is out there for all systems. I can only hope
> that as more people get involved in XML/XSLT familiarity will go up.
it is a very serious issue. And since I don't completely buy the idea
that all templates will be generated by tools, at least not for a while,
it's important.
If I recall, we weren't supposed to be programming at this point in time
either.
> In XSLT you can define everything in the root template.
> <xsl:template match="/">
> <html>
> .... (with XSL:* tags for processing-instructions)
> </html>
> </xsl:template>
>
> Most editors, although I haven't specifically tested with dreamweaver,
> should be able to handle this as you would expect. If you want to do more
> you can define and call/apply more templates.
I am sure dreamweaver can deal with it. The problem is the model. I
think of XSLT as 'event-driven' rather than linear. I find this very
cool, by the way - however, I wonder if that notion can be well
expressed in a GUI tool for your average designer.
[SNIP]
> > > W3C Standard:
> > > In my experience the XSLT engines I've used have all worked on my XSL
> files
> > > without any need for changes. The node-list concept in XSLT is extremely
> > > powerful and very cool. The fact that it is a standard helps focus
> changes,
> > > evolution and additions.
> >
> > See previous response to Jeff. I respect this, and as long as you stay
> > with 'real tools', it's good. Once you start trying to tell me that IE
> > and Netscape do it 'to some degree', the arg falls apart for me.
>
> I'm not talking about the browser. I mean platforms and systems. If you have
> XSL files it is easy to move them from one system to another because it is a
> standard. XML is a portable data format, XSL(T) is portable transformation
> language.
And that is what I meant about 'real tools'. I certainly see the value
there. (but Jeff mentioned browsers...)
>
> >
> > > XML Based:
> > > Because XSL files are just instances of XML documents when some good XML
> > > editor comes along, they will be able to enjoy the ride. I really hope
> this
> > > happens soon. :) I've played with VS.Net's XML editor, it allows for
> > > graphical and textual editing with syntax checking and suggestions.
> >
> > I would love a great editor! I tried Merlot, which is pretty good (but
> > I have a slow computer), and the only other that was recommeded (XML
> > cooktop) seems to be a Win32 binary that uses IE5 as a control... so
> > seems like a control frame on IE5.
>
> If I find one, I'll send email your way. :)
Please do. Or we write one. <aside> I just started using TOAD for
oracle. What a great tool... we need a java version of that </aside>
> [stuff was here...]
>
> > The important part to me is that you offer Velocity as an option. You
> > guys seem to have a clear vision of how you like to work with XML/XSL,
> > and will be interesting to see how you extend the use of Velocity in
> > that environment. Keep us updated.
>
> No problems. I will be involved in the Velocity list as I start to
> understand its full scope and abilities. So far it seems pretty stable, and
> aside from some issues I had in getting it integrated into our system, it
> work great. Those issues are related to deployment, and the fact that the
> engine is all statics. It would be nice if I could hold onto an instance of
> the engine for any given application without classloader and VM worries...
Yes, we want to do that. More on that soon.
geir
--
Geir Magnusson Jr. geirm@optonline.net
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!
Re: What about Barracuda?
Posted by Scott Hernandez <sk...@eecs.berkeley.edu>.
I wanted to get into more XSL stuff but I'm not sure this list is the right
place... but let me make a few more generic comments.
----- Original Message -----
From: "Geir Magnusson Jr." <ge...@optonline.net>
Subject: Re: What about Barracuda?
[stuff was here...]
> Rule-based:
> > In XSLT things are rule-based, allowing for recursion, and matching
follows
> > (initially) the structure of the input DOM. So rules (xsl-template
elements)
> > allows for an easy transformation from the source. Adding XPath for
select
> > make things really powerful. This rule syntax is fairly simple and
> > straight-forward but extremely powerful.
>
> Yes - you can use XPath on a DOM tree in Velocity as well. As for the
> rules-based bit, I have been dreaming about a rules based transformer
> using velocity. It don't think it will be that hard, except for the
> conditional match part, but that's not too hard either.
Does this require a java class of some sort? Or do you just work from a
JDOM/DOM4J object that is in the context? I didn't see and type of
load/parse xml directive. Is there such a thing?
> The real point I would make here is that I am not convinced that to the
> average designer, the declarative, rules-based approach is obvious,
> especially when it seems that designers think more linearly, more
> procedurally. (Like they see a whole page in Dreamweaver...)
I spend much time wondering and discussion how different people will react,
and how easily they will adapt, if they need to learn XSL(T). It is a very
serious question and one that is out there for all systems. I can only hope
that as more people get involved in XML/XSLT familiarity will go up.
In XSLT you can define everything in the root template.
<xsl:template match="/">
<html>
.... (with XSL:* tags for processing-instructions)
</html>
</xsl:template>
Most editors, although I haven't specifically tested with dreamweaver,
should be able to handle this as you would expect. If you want to do more
you can define and call/apply more templates.
>
> Someone has made the argument to me that the back-end templating
> technology will be moot once the tools get good enough. (He was
> referring to the inherant yecchiness of typing in JSP...). I don't fully
> buy it - I still write SQL by hand - but I think that XSL will have a
> tough time there.
I've worked with some systems that are graphical, like Visual Interdev,
Cold-Fusion, and NetDynamics and there is something to be said for building
quick and easy web apps without writing a line of code. For the most part
they have graphical widgets that generate the code for you (disguised as
little runtime widgets), but hey, some people need all the help they can
get.:) The biggest problem these systems have is that the widgets inner
workings are much more complicated than they need to be. This puts a real
limitation on the ability of the user to understand and get away from using
them.
Most of the time I only tune SQL by hand; I find there are sufficient tools
to help me create the initial statements.. but this is another discussion.
;)
> > W3C Standard:
> > In my experience the XSLT engines I've used have all worked on my XSL
files
> > without any need for changes. The node-list concept in XSLT is extremely
> > powerful and very cool. The fact that it is a standard helps focus
changes,
> > evolution and additions.
>
> See previous response to Jeff. I respect this, and as long as you stay
> with 'real tools', it's good. Once you start trying to tell me that IE
> and Netscape do it 'to some degree', the arg falls apart for me.
I'm not talking about the browser. I mean platforms and systems. If you have
XSL files it is easy to move them from one system to another because it is a
standard. XML is a portable data format, XSL(T) is portable transformation
language.
>
> > XML Based:
> > Because XSL files are just instances of XML documents when some good XML
> > editor comes along, they will be able to enjoy the ride. I really hope
this
> > happens soon. :) I've played with VS.Net's XML editor, it allows for
> > graphical and textual editing with syntax checking and suggestions.
>
> I would love a great editor! I tried Merlot, which is pretty good (but
> I have a slow computer), and the only other that was recommeded (XML
> cooktop) seems to be a Win32 binary that uses IE5 as a control... so
> seems like a control frame on IE5.
If I find one, I'll send email your way. :)
[stuff was here...]
> The important part to me is that you offer Velocity as an option. You
> guys seem to have a clear vision of how you like to work with XML/XSL,
> and will be interesting to see how you extend the use of Velocity in
> that environment. Keep us updated.
No problems. I will be involved in the Velocity list as I start to
understand its full scope and abilities. So far it seems pretty stable, and
aside from some issues I had in getting it integrated into our system, it
work great. Those issues are related to deployment, and the fact that the
engine is all statics. It would be nice if I could hold onto an instance of
the engine for any given application without classloader and VM worries...
>
> You are on the 'powered by...' list.
Great, Thanks!
skot
Re: What about Barracuda?
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Scott Hernandez wrote:
[SNIP]
> Now on to the questions at hand, XSL vs. Velocity?
>
> Well, we didn't want to close anyone in on one technology. But here are my
> observations of XSL(T).
>
> Speed could be an issue, but there are projects out there that will soon
> allow for compiled transformation engines. These engines should be as fast
> as any other piece of compiled code. They will eliminate the overhead of
> parsing and evaluating at runtime. Let's leave the performance issue out of
> it for the moment. If everything else is even, we can come back to it later
> if you wish.
Ok. I think things will always get faster - and I have a client that
uses XSLT extensively, and while it's slow, caching helps a lot, so it's
really not a big deal.
> Rule-based:
> In XSLT things are rule-based, allowing for recursion, and matching follows
> (initially) the structure of the input DOM. So rules (xsl-template elements)
> allows for an easy transformation from the source. Adding XPath for select
> make things really powerful. This rule syntax is fairly simple and
> straight-forward but extremely powerful.
Yes - you can use XPath on a DOM tree in Velocity as well. As for the
rules-based bit, I have been dreaming about a rules based transformer
using velocity. It don't think it will be that hard, except for the
conditional match part, but that's not too hard either.
The real point I would make here is that I am not convinced that to the
average designer, the declarative, rules-based approach is obvious,
especially when it seems that designers think more linearly, more
procedurally. (Like they see a whole page in Dreamweaver...)
Someone has made the argument to me that the back-end templating
technology will be moot once the tools get good enough. (He was
referring to the inherant yecchiness of typing in JSP...). I don't fully
buy it - I still write SQL by hand - but I think that XSL will have a
tough time there.
> W3C Standard:
> In my experience the XSLT engines I've used have all worked on my XSL files
> without any need for changes. The node-list concept in XSLT is extremely
> powerful and very cool. The fact that it is a standard helps focus changes,
> evolution and additions.
See previous response to Jeff. I respect this, and as long as you stay
with 'real tools', it's good. Once you start trying to tell me that IE
and Netscape do it 'to some degree', the arg falls apart for me.
> XML Based:
> Because XSL files are just instances of XML documents when some good XML
> editor comes along, they will be able to enjoy the ride. I really hope this
> happens soon. :) I've played with VS.Net's XML editor, it allows for
> graphical and textual editing with syntax checking and suggestions.
I would love a great editor! I tried Merlot, which is pretty good (but
I have a slow computer), and the only other that was recommeded (XML
cooktop) seems to be a Win32 binary that uses IE5 as a control... so
seems like a control frame on IE5.
> Additionally, aside from these strengths of XSL(T), in a maverick
> application there are some additional benefits on using XML. Because the
> input to our transformations is XML (from a file, another engine, or our
> domify code) all of the presentation view can be designed/developed and
> tested without the use of any live back-end datasource or application
> server/code. This could really simplify and streamline the process of
> developing dynamic sites.
>
> Whatcha think?
>
I am interested, and will certainly take a look.
The important part to me is that you offer Velocity as an option. You
guys seem to have a clear vision of how you like to work with XML/XSL,
and will be interesting to see how you extend the use of Velocity in
that environment. Keep us updated.
You are on the 'powered by...' list.
geir
--
Geir Magnusson Jr. geirm@optonline.net
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!
Re: What about Barracuda?
Posted by Scott Hernandez <sk...@eecs.berkeley.edu>.
hmm.... good question... :)
To give you a little background of Maverick let me start with why we created
another web publishing framework. Jeff has been interested in matching
things (for a lack of a more deep explanation) for a while and started a
project to work on it. This project, http://www.similarity.com, is written
using Webworks as the front end. So he and I started talking about MVC
frameworks, specifically web publishing frameworks, and came to the
conclusion to a few conclusions. IMO I wanted something that used XSL(T) for
creating presentation. So that is what I pushed. One of the reasons I was
pushing XSL, beside the fact that I found it useful for generating HTML, was
that I also had this idea for writing a simple wrapper (facet;the domify
package) that would expose any object, or object graph, as XML DOM objects
(which could be used as the input for any transformation). In addition to
that the idea of a transformation pipeline, a series of successive
transformations, came out as Jeff and I discussed things. And with these new
tools in hand, Jeff's experience with WebWorks, and some exploration of
Struts and few other MVC web frameworks, we built a very light-weight (and
understandable) framework. During these discussions Jeff brought up Velocity
and we looked about for other templating systems that could render the view
in our framework.
Now on to the questions at hand, XSL vs. Velocity?
Well, we didn't want to close anyone in on one technology. But here are my
observations of XSL(T).
Speed could be an issue, but there are projects out there that will soon
allow for compiled transformation engines. These engines should be as fast
as any other piece of compiled code. They will eliminate the overhead of
parsing and evaluating at runtime. Let's leave the performance issue out of
it for the moment. If everything else is even, we can come back to it later
if you wish.
Rule-based:
In XSLT things are rule-based, allowing for recursion, and matching follows
(initially) the structure of the input DOM. So rules (xsl-template elements)
allows for an easy transformation from the source. Adding XPath for select
make things really powerful. This rule syntax is fairly simple and
straight-forward but extremely powerful.
W3C Standard:
In my experience the XSLT engines I've used have all worked on my XSL files
without any need for changes. The node-list concept in XSLT is extremely
powerful and very cool. The fact that it is a standard helps focus changes,
evolution and additions.
XML Based:
Because XSL files are just instances of XML documents when some good XML
editor comes along, they will be able to enjoy the ride. I really hope this
happens soon. :) I've played with VS.Net's XML editor, it allows for
graphical and textual editing with syntax checking and suggestions.
Additionally, aside from these strengths of XSL(T), in a maverick
application there are some additional benefits on using XML. Because the
input to our transformations is XML (from a file, another engine, or our
domify code) all of the presentation view can be designed/developed and
tested without the use of any live back-end datasource or application
server/code. This could really simplify and streamline the process of
developing dynamic sites.
Whatcha think?
skot
P.S. http://mav.sourceforge.net :)
----- Original Message -----
From: "Geir Magnusson Jr." <ge...@optonline.net>
> There's something I don't get - in my experience, Velocity is faster
> than XSLT at styling DOM trees. For example, that is what is used to
> generate quite a few Jakarta websites (it's static because it's one
> machine and heavy load...) using Anakia. The same content used to be
> styled with XSLT, and it was slower.
>
> I have a client where we have mixed XSLT transformations *and* Velocity
> to work on XML content, using the Velocity for the control and logic,
> and XSLT for the basic styling. The XSLT is there because that is how
> things originally where, and I expect that over time, more and more will
> be done with Velocity. It certainly will be interesting to see what the
> designers prefer - they have complete freedom to choose.
>
> So, to actually ask a question : why XSLT if you understand the
> usefulness of Velocity?
>
> geir
>
> --
> Geir Magnusson Jr. geirm@optonline.net
> 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!
>
Re: What about Barracuda?
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Scott Hernandez wrote:
>
> That is funny, I just finished adding Velocity support for our MVC framework
> called Maverick (mav.sourceforge.net). We too wrote a servlet based MVC
> framework that did something very similar.
>
> Maverick initially supported XSL and JSP but we really wanted to open things
> up for Velocity development. In the current implementation Velocity
> templates can be used for the whole view, or as XML generators for use with
> XSL pipelines. Individual commands (a page/url request) can use any of the
> view technologies for the best of all combinations.
>
> Please take a look if you are interested.
>
There's something I don't get - in my experience, Velocity is faster
than XSLT at styling DOM trees. For example, that is what is used to
generate quite a few Jakarta websites (it's static because it's one
machine and heavy load...) using Anakia. The same content used to be
styled with XSLT, and it was slower.
I have a client where we have mixed XSLT transformations *and* Velocity
to work on XML content, using the Velocity for the control and logic,
and XSLT for the basic styling. The XSLT is there because that is how
things originally where, and I expect that over time, more and more will
be done with Velocity. It certainly will be interesting to see what the
designers prefer - they have complete freedom to choose.
So, to actually ask a question : why XSLT if you understand the
usefulness of Velocity?
geir
--
Geir Magnusson Jr. geirm@optonline.net
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!
Re: What about Barracuda?
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Scott Hernandez wrote:
>
> That is funny, I just finished adding Velocity support for our MVC framework
> called Maverick (mav.sourceforge.net). We too wrote a servlet based MVC
> framework that did something very similar.
>
> Maverick initially supported XSL and JSP but we really wanted to open things
> up for Velocity development. In the current implementation Velocity
> templates can be used for the whole view, or as XML generators for use with
> XSL pipelines. Individual commands (a page/url request) can use any of the
> view technologies for the best of all combinations.
>
> Please take a look if you are interested.
>
cool.
--
Geir Magnusson Jr. geirm@optonline.net
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!
Re: What about Barracuda?
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Jon Stevens wrote:
>
> on 6/18/01 4:14 AM, "Geir Magnusson Jr." <ge...@optonline.net> wrote:
>
> > That's the approach I have been thinking of - extending the Anakia model
> > to be matching...
>
> This is something that is going to be very difficult to implement because of
> <xsl:apply-templates/>.
>
> I think it would be pretty easy to load up the XML file and load up a file
> full of macros. Then walk the XML file and apply macros for each node that
> matches. The hard part is when macros start to call other macro's in a way
> that is matching.
We've talked about that aspect before. The matching part is the thing
we have to be careful with.
>
> I think that making Anakia work as a matching processor would slow it down
> quite a bit to the point that you would have XSLT speeds and that wouldn't
> be good.
>
> I'm not sure the code complexity and speed hit is really worth it since the
> current Anakia is already a proven working model. If you haven't read
> Anakia's source code, the main portion of the application is about 10 lines
> of code. It doesn't get much simpler than that. :-)
I wasn't thinking of it as a replacement for anakia - anakia works
great. I was thinking of it as a XSLT replacement, something that
matches the pattern.
And why does it take 10 lines? :)
geir
--
Geir Magnusson Jr. geirm@optonline.net
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!
Re: What about Barracuda?
Posted by Jon Stevens <jo...@latchkey.com>.
on 6/18/01 4:14 AM, "Geir Magnusson Jr." <ge...@optonline.net> wrote:
> That's the approach I have been thinking of - extending the Anakia model
> to be matching...
This is something that is going to be very difficult to implement because of
<xsl:apply-templates/>.
I think it would be pretty easy to load up the XML file and load up a file
full of macros. Then walk the XML file and apply macros for each node that
matches. The hard part is when macros start to call other macro's in a way
that is matching.
I think that making Anakia work as a matching processor would slow it down
quite a bit to the point that you would have XSLT speeds and that wouldn't
be good.
I'm not sure the code complexity and speed hit is really worth it since the
current Anakia is already a proven working model. If you haven't read
Anakia's source code, the main portion of the application is about 10 lines
of code. It doesn't get much simpler than that. :-)
-jon
RE: What about Barracuda?
Posted by David Duddleston <da...@i2a.com>.
>
> How do you pass the context?
>
> You can simply hand it the context when populating :
>
> Foo myfoo = new Foo( context );
>
> context.put("foo", myfoo);
>
> Dave Bryson was playing with some context aware tools a while ago - they
> are in whiteboard/daveb. Take a look.
Oh, so obvious. I'm embarassed. I'm sooo Velocity retarded.
Thanks Geir
-david
Re: What about Barracuda?
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
David Duddleston wrote:
>
> > -----Original Message-----
> > From: gmj@mta6.srv.hcvlny.cv.net [mailto:gmj@mta6.srv.hcvlny.cv.net]On
> > Behalf Of Geir Magnusson Jr.
> >
> > > #1 Using a #parse(...), but the ability to generate data is
> > limited to the
> > > data generation capabilities of the classes put into the context.
> >
> > Which can be a good thing.
>
> Agreed. Don't want any potential security issues if the designer can't be
> trusted. I'm most cases the designer can be trusted and it is not much of an
> issue. I guess this is why JSP is accepted because there does not seem to be
> a problem with designers abusing the scriplets and doing things they should
> not.
I can't imagine that is something people really think about until its
too late. If we take the 'trust' issue out of it, there is always the
issue of maintainability...
> For myself, since I'm responsible for data coming in and out of the
> database, I feel more comfortable limiting what the designer can do. One of
> the reasons, I like MVC.
>
> > > #2 Have a custom directive #component(...) that could do all
> > the dirty work
> > > of locating the component and executing it.
> >
> > Why is this different than a tool dropped into the context?
>
> Probably not much... because of my past experience it seems familiar and
> feels right. You call a component by name and maybe pass some parameters...
> any other details are automaticaly handled. Is it worth the effort or is it
> most appropriate... I'm not sure at this point.
>
> > > #3 Drop all the components or the component controller in the
> > context and
> > > manualy locate components and execute them.
> >
> > That hints at the so-called 'pull' model, which has it's merits.
>
> Hmmm, question. How do I pass the whole context to a component class? I have
> not used Velocity in about 2 weeks and since I have not used it much, I
> forgot most if it even though I felt pretty comforable with it for about a
> week. Damn, my memory is the so bad.
How do you pass the context?
You can simply hand it the context when populating :
Foo myfoo = new Foo( context );
context.put("foo", myfoo);
Dave Bryson was playing with some context aware tools a while ago - they
are in whiteboard/daveb. Take a look.
> > > I'm sure there is probably a real novel way to do this that I'm
> > not thinking
> > > of. One of these days, I hope to have time to give it a good
> > think through.
> > > Any thoughts?
> >
> > Any chance using the pull model and Velocimacros would help?
>
> Ahh... yes, macros... I think that would be a better approach than just
> calling the component class directly all the time.
>
> #macro( survey)
> $components.getComponent("survey").execute(...); or something like
> this...
> #end
>
> #survey()
>
> I like it Geir... I knew there was an obvious way to do it... I'm just to
> Velocity retarded to figure it out.
Not at all. VMs aren't the first thing people think of. And it may
turn out to not be the right solution.
> The macros are very cool. I thought about trying to simulate some of the
> XSLT matching stuff with macros. So many possiblities ;-)
That's the approach I have been thinking of - extending the Anakia model
to be matching...
> Geir... thanks so much for all the great support you give. You give so much
> added value to Velocity. You are very tolerant about people rambling they
> ideas off on this list and give good feedback ;-)
I am equally as guilty of rambling as the next person :)
geir
--
Geir Magnusson Jr. geirm@optonline.net
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!
RE: What about Barracuda?
Posted by David Duddleston <da...@i2a.com>.
> -----Original Message-----
> From: gmj@mta6.srv.hcvlny.cv.net [mailto:gmj@mta6.srv.hcvlny.cv.net]On
> Behalf Of Geir Magnusson Jr.
>
> > #1 Using a #parse(...), but the ability to generate data is
> limited to the
> > data generation capabilities of the classes put into the context.
>
> Which can be a good thing.
Agreed. Don't want any potential security issues if the designer can't be
trusted. I'm most cases the designer can be trusted and it is not much of an
issue. I guess this is why JSP is accepted because there does not seem to be
a problem with designers abusing the scriplets and doing things they should
not. For myself, since I'm responsible for data coming in and out of the
database, I feel more comfortable limiting what the designer can do. One of
the reasons, I like MVC.
> > #2 Have a custom directive #component(...) that could do all
> the dirty work
> > of locating the component and executing it.
>
> Why is this different than a tool dropped into the context?
Probably not much... because of my past experience it seems familiar and
feels right. You call a component by name and maybe pass some parameters...
any other details are automaticaly handled. Is it worth the effort or is it
most appropriate... I'm not sure at this point.
> > #3 Drop all the components or the component controller in the
> context and
> > manualy locate components and execute them.
>
> That hints at the so-called 'pull' model, which has it's merits.
Hmmm, question. How do I pass the whole context to a component class? I have
not used Velocity in about 2 weeks and since I have not used it much, I
forgot most if it even though I felt pretty comforable with it for about a
week. Damn, my memory is the so bad.
> > I'm sure there is probably a real novel way to do this that I'm
> not thinking
> > of. One of these days, I hope to have time to give it a good
> think through.
> > Any thoughts?
>
> Any chance using the pull model and Velocimacros would help?
Ahh... yes, macros... I think that would be a better approach than just
calling the component class directly all the time.
#macro( survey)
$components.getComponent("survey").execute(...); or something like
this...
#end
#survey()
I like it Geir... I knew there was an obvious way to do it... I'm just to
Velocity retarded to figure it out.
The macros are very cool. I thought about trying to simulate some of the
XSLT matching stuff with macros. So many possiblities ;-)
Geir... thanks so much for all the great support you give. You give so much
added value to Velocity. You are very tolerant about people rambling they
ideas off on this list and give good feedback ;-)
-david
Re: What about Barracuda?
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
David Duddleston wrote:
>
> I took a quick look at Maverick and while it looked pretty cool, it does not
> seem to directly support the sort of component system I'm talking about...
> unless I missed something. I'm thinking of components that more or less have
> their own _sort_ of mini hierarchical MVC (but not really a pure HMVC). Each
> component takes some input data, evaluates the data and then determines if
> it needs to generate additional data and which view to use. I can think of
> three different approaches to simualting this with Velocity.
> #1 Using a #parse(...), but the ability to generate data is limited to the
> data generation capabilities of the classes put into the context.
Which can be a good thing.
> #2 Have a custom directive #component(...) that could do all the dirty work
> of locating the component and executing it.
Why is this different than a tool dropped into the context?
> #3 Drop all the components or the component controller in the context and
> manualy locate components and execute them.
That hints at the so-called 'pull' model, which has it's merits.
> I'm sure there is probably a real novel way to do this that I'm not thinking
> of. One of these days, I hope to have time to give it a good think through.
> Any thoughts?
Any chance using the pull model and Velocimacros would help?
> BTW, are custom directives a bad idea?
I sort of think so in most cases. I am sure there are darn good cases
where you need them, but I haven't seen it yet. Since you can put
anythign you want into the context, that can take any args, why bother
with a custom directive? I don't see what it adds. References are the
most flexible of the two entities, mainly because of the flexibility in
methods.
Suppose you choose the directive route - what happens when you want to
add another parameter? With an in-context too, just add another method,
and whoever needs it can use it - whoever doesn't can stay as they
are...
geir
--
Geir Magnusson Jr. geirm@optonline.net
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!
RE: What about Barracuda?
Posted by David Duddleston <da...@i2a.com>.
I took a quick look at Maverick and while it looked pretty cool, it does not
seem to directly support the sort of component system I'm talking about...
unless I missed something. I'm thinking of components that more or less have
their own _sort_ of mini hierarchical MVC (but not really a pure HMVC). Each
component takes some input data, evaluates the data and then determines if
it needs to generate additional data and which view to use. I can think of
three different approaches to simualting this with Velocity.
#1 Using a #parse(...), but the ability to generate data is limited to the
data generation capabilities of the classes put into the context.
#2 Have a custom directive #component(...) that could do all the dirty work
of locating the component and executing it.
#3 Drop all the components or the component controller in the context and
manualy locate components and execute them.
I'm sure there is probably a real novel way to do this that I'm not thinking
of. One of these days, I hope to have time to give it a good think through.
Any thoughts?
BTW, are custom directives a bad idea?
-david
> -----Original Message-----
> From: Scott Hernandez [mailto:skot@eecs.berkeley.edu]
> Sent: Saturday, June 16, 2001 2:46 PM
> To: velocity-user@jakarta.apache.org
> Subject: Re: What about Barracuda?
>
>
> That is funny, I just finished adding Velocity support for our
> MVC framework
> called Maverick (mav.sourceforge.net). We too wrote a servlet based MVC
> framework that did something very similar.
>
> Maverick initially supported XSL and JSP but we really wanted to
> open things
> up for Velocity development. In the current implementation Velocity
> templates can be used for the whole view, or as XML generators
> for use with
> XSL pipelines. Individual commands (a page/url request) can use any of the
> view technologies for the best of all combinations.
>
> Please take a look if you are interested.
>
> later,
> skot
>
> ----- Original Message -----
> From: "David Duddleston" <da...@i2a.com>
> Sent: Wednesday, June 13, 2001 11:42 AM
> Subject: RE: What about Barracuda?
> > It was a framework that some friends of mine wrote for a private project
> > several years ago. I can't remember details very well, but
> essentialy, you
> > would create a component that took some parameters, a context and a
> writer.
> > The component would analyize the params and the data in the context to
> > figure out what data it needs to generate if any. Then it would add that
> > data to the context and render itself if needed (data and or template
>
Re: What about Barracuda?
Posted by Scott Hernandez <sk...@eecs.berkeley.edu>.
That is funny, I just finished adding Velocity support for our MVC framework
called Maverick (mav.sourceforge.net). We too wrote a servlet based MVC
framework that did something very similar.
Maverick initially supported XSL and JSP but we really wanted to open things
up for Velocity development. In the current implementation Velocity
templates can be used for the whole view, or as XML generators for use with
XSL pipelines. Individual commands (a page/url request) can use any of the
view technologies for the best of all combinations.
Please take a look if you are interested.
later,
skot
----- Original Message -----
From: "David Duddleston" <da...@i2a.com>
Sent: Wednesday, June 13, 2001 11:42 AM
Subject: RE: What about Barracuda?
> It was a framework that some friends of mine wrote for a private project
> several years ago. I can't remember details very well, but essentialy, you
> would create a component that took some parameters, a context and a
writer.
> The component would analyize the params and the data in the context to
> figure out what data it needs to generate if any. Then it would add that
> data to the context and render itself if needed (data and or template
RE: What about Barracuda?
Posted by David Duddleston <da...@i2a.com>.
It was a framework that some friends of mine wrote for a private project
several years ago. I can't remember details very well, but essentialy, you
would create a component that took some parameters, a context and a writer.
The component would analyize the params and the data in the context to
figure out what data it needs to generate if any. Then it would add that
data to the context and render itself if needed (data and or template
changed) or use a cached render. Also, before using the cached render, it
would ask any child components if they are still valid.
When we started the project, none of us really knew what they were doing and
I just started programming all together, so our design was not all that
great, but it worked and we were happy with the concept and felt it was the
right direction to take. It did get abandoned when my other friends (the
real programmers), stopped doing Web development. I wanted to continue it,
but did not have the knowledge or time to turn it into a solid project.
I don't know that much about Barracuda, but I did take a quick look and it
seems interesting. If you do get it working with Velocity, I will definitely
check it out.
How do you plan to call components from a Velocity template? Are you
planning on adding a new directive? Something like #component(...). Also
with Velocity is seems a sticky point might be how you are going to validate
child components of a Velocity template. Any idea how you will do that?
-david
> -----Original Message-----
> From: Christian Cryder [mailto:christianc@enhydra.org]
> Sent: Wednesday, June 13, 2001 7:35 AM
> To: velocity-user@jakarta.apache.org
> Subject: RE: What about Barracuda?
>
>
> Hi David,
>
> > I have used a component framework in the past for the Web
> > UI and it worked out real well. The component part was very
> > powerful, but unfortunately the templating engine was a bit
> > lacking.
>
> I'd be very curious to hear details about the framework. What was it? Who
> wrote it? What did you like/dislike about it? etc.
>
> This is probably not Velocity related, so feel free to respond to me
> privately or on the Barracuda list.
>
> Christian
> ------------------------------------------------
> Christian Cryder [christianc@enhydra.org]
> Barracuda - MVC Component Framework for Webapps
> http://barracuda.enhydra.org
> ------------------------------------------------
> "What a great time to be a Geek"
>
>
> > -----Original Message-----
> > From: David Duddleston [mailto:david@i2a.com]
> > Sent: Tuesday, June 12, 2001 4:14 PM
> > To: velocity-user@jakarta.apache.org
> > Subject: RE: What about Barracuda?
> >
> >
> >
> >
> > > Do you want to continue this discussion on Velocity-User or carry
> > > it out on
> > > the Barracuda list?
> >
> > I'm interested in the discussion. I have used a component
> framework in the
> > past for the Web UI and it worked out real well. The component
> > part was very
> > powerful, but unfortunately the templating engine was a bit lacking. The
> > thought of trying to use Velocity in a component framework has
> crossed my
> > mind several times, but I just don't have any time to think it through.
> >
> > -david
> >
RE: What about Barracuda?
Posted by Christian Cryder <ch...@enhydra.org>.
Hi David,
> I have used a component framework in the past for the Web
> UI and it worked out real well. The component part was very
> powerful, but unfortunately the templating engine was a bit
> lacking.
I'd be very curious to hear details about the framework. What was it? Who
wrote it? What did you like/dislike about it? etc.
This is probably not Velocity related, so feel free to respond to me
privately or on the Barracuda list.
Christian
------------------------------------------------
Christian Cryder [christianc@enhydra.org]
Barracuda - MVC Component Framework for Webapps
http://barracuda.enhydra.org
------------------------------------------------
"What a great time to be a Geek"
> -----Original Message-----
> From: David Duddleston [mailto:david@i2a.com]
> Sent: Tuesday, June 12, 2001 4:14 PM
> To: velocity-user@jakarta.apache.org
> Subject: RE: What about Barracuda?
>
>
>
>
> > Do you want to continue this discussion on Velocity-User or carry
> > it out on
> > the Barracuda list?
>
> I'm interested in the discussion. I have used a component framework in the
> past for the Web UI and it worked out real well. The component
> part was very
> powerful, but unfortunately the templating engine was a bit lacking. The
> thought of trying to use Velocity in a component framework has crossed my
> mind several times, but I just don't have any time to think it through.
>
> -david
>
RE: What about Barracuda?
Posted by David Duddleston <da...@i2a.com>.
> Do you want to continue this discussion on Velocity-User or carry
> it out on
> the Barracuda list?
I'm interested in the discussion. I have used a component framework in the
past for the Web UI and it worked out real well. The component part was very
powerful, but unfortunately the templating engine was a bit lacking. The
thought of trying to use Velocity in a component framework has crossed my
mind several times, but I just don't have any time to think it through.
-david
RE: What about Barracuda?
Posted by Christian Cryder <ch...@enhydra.org>.
Hi Geir,
> > 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.
>
> I would be interested to know what motivated this premise.
This was a driving force from the early days of XMLC several years ago;
graphic designers build *ML mockups using the markup tools of their choice
(ie. FrontPage, Dreamweaver, etc). The mockups can be viewed directly
through a web browser, can have static links between pages, in forms, etc.
It basically provides an easy way for suits to validate "yes, thats what we
need in our webapp" without ever involving a developer.
Once there is basic signoff on the mockup/prototype, then the developer and
designer meet to work out the contract (from this point on its very similar
to a taglibs or template approach...developer provides data; designer
references data in the templates). The real difference is that the templates
always remain valid markup...
> I have a bit of issue there with the phrase 'programming logic'. Why?
> Because while it is totally accurate, it's a little misleading : I
> believe that designers need the ability to use basic logic for design
> and navigation - as long as that logic isn't "business logic", then I
> think there is nothing wrong with it.
>
> It does tend to lead to the designer taking over some of the application
> flow control, and while MVC fundamentalists might whine, it seems to
> work very well in practice.
We've found a lot of people who want to avoid the situation where the
designer has to do this. Its certainly not because designers aren't capable;
it's rather because when you have a problem in the app you now have to
figure out whether its a designer issue or a developer issue...in often more
difficult to track down.
In addition, I'd tend to argue that any "programming logic" is ultimately
"business logic", but that's not really central to the discussion here...
The bottom line is that most template approaches tend to require you to put
logic in the template, while a pure XMLC approach keeps all the logic in
Java code. The Barracuda BTemplate component allows for some very simple
logic (iterators, references to data) to be added to the template. If we can
extend Barracuda by proving a BVelocity component, then we give the
developer that much more flexibility--they have a greater range of options
to choose from.
> Does that require the maintenance of two things to render one page? One
> 'valid' template, and one id-to-directive mapping?
Directives can be embedded directly in the markup using the class attribute,
or in a separate properties file. That approach seems to keep everyone
happy...
> However, I don't agree with your premise as it seems to be based
> on the assumption that there is a component+interface requirement
> for MVC, whereas my understanding of MVC was based more on the
> existance of a change / user-event notification system between the
> parts of some kind, rather than a specific notion like 'interface',
> which is language dependant.
The purpose of the document is just to state explicitly what we mean by MVC
vs. Model 2. Note that Barracuda does provide an event model...it can be
used all by itself to provide Model 2 flow control; it is also available to
components (although you don't have to use it).
> I assume you mean 'component' as in 'object'? Where does the mapping
> come from to tell you how to do this?
No! We mean 'Component' as in 'UI Widget'. In Barracuda, the essence of
component-ness is:
a) containment - a component can contain any number of other components
b) lifecycle - components may be initialized, used, and then destroyed
c) viewable - a component can be bound to any number of views. When it
renders, its responsible for taking any data associated with the component
and updating the views accordingly. Each view has a 1:1 relationship with a
node in the DOM
d) visibility - any component may be visible/invisible, enabled/disabled.
Invisible components cause the portion of the DOM they are bound to not to
be rendered.
e) renderable - a component can be rendered, which will cause the component
itself to be rendered, plus all of its children. The actual renderer used
will vary depending on client capabilities. Once a component has been
rendered it is marked as validated, meaning that it won't be re-rendered
until the data changes or the component is invalidated.
f) data - components will typically (but not necessarily!) be associated
with data that needs to be rendered in the associated views. Data may either
be stored directly in the component (ie. BAction, BLink, BInput,
BToggleButton, and BText all have setXXX methods), or it may be accessed
through a strongly typed MVC Model interface like you'd find in Swing
(BTemplate, BTable, BList, and BSelect all have Model interfaces).
g) data polymorphism - in a manner similar to Swing, models may return data
of type String, Node, and BComponent. I won't bother trying to explain this
here, but Barracuda developers find it very powerful.
As you've no doubt already realized, folks who think Swing sucks will
probably not like Barracuda.
> Velocity is even lower level - it's simply a templating system,
> and it makes very little demands upon the architecture used.
> The only demand is that it must be fed
Excellent. Sounds like we should be able to integrate with it then. In the
past we've looked at the possiblity of creating components for WebMacro and
JSP, and that was precisely the problem with them--they are tightly coupled
to a specific architecture.
> Note that I would argue that <%foo%> isn't really valid markup. :)
I'd agree.
> This I don't get. Velocity offers something I call 'introspective
> polymorphism' - it allows you to use as the backing 'data object'
> anything that has the right 'shape'. By this I mean if you had a
> reference in a template :
Ok, I follow you on the 'introspective polymorphism' bit, I believe. (Out of
curiosity, any reference points on how introspection impacts performance
here?)regarding the stmt that you didn't get, I'll see if I can explain it a
little better.
First, are you familiar with Swing and its ability for models to return
complex objects? For instance, a TableModel could return a JSelect
component, which would then get rendered in the particular table cell. Or it
could return another JTable...it can really handle any kind of JComponent.
Barracuda components have a similar capability. The best way I can think of
describing it is by referring to your AddressData object: what if getCity()
didn't return a String, but instead returned another "velocity template"? By
this I mean what if AddressData should be replaced with a block of markup
that has its own template tags and might refer to different models, etc.
In Barracuda, its easy to embed components within components within
components... Except you're not just limited to templates. I might have an
overriding template component that parses a page, and as it encounters
directives it queries the model for data. Now in many cases the mode will
just return String data, but there may also be situations where I'd like to
grab a complex block of markup and dynamically update a select component in
it, or insert a list of data, or a table. And that block of data returned
may itself be supported by many other nested components. Barracuda handles
all of that seamlessly.
If it still doesn't make sense, don't worry about it--many died-in-the-wool
xmlc folks don't get it either, and its not really central to this
discussion.
> > Would you have any interest in helping me figure out if this is doable?
>
> Of course! It think it's very doable. Because Velocity is 'nothing
> more' than a template spec and the engine, it's easy to adapt.
Very cool.
> I am interested in seeing this work. I stopped by the enhydra booth at
> JavaOne to pitch Velocity, to talk about putting together an example,
> but I don't think anyone understood me. So they gave me a shirt, I
> guess to get rid of me, and only when I was unpacking did I notice it
> was only a Large. Alas.
Ack! The dreaded JavaOne-booth-salespeople and the only-a-large syndrome
both in one fell swoop! Garn. Unfortunately I wasn't there this year...would
have been fun to talk to you in person. Oh well, at least there's email...
;-)
Maybe we should each start by taking a look at the other's documentation.
Then I can ask you questions and vica-versa.
Do you want to continue this discussion on Velocity-User or carry it out on
the Barracuda list?
Talk to you soon!
Christian
------------------------------------------------
Christian Cryder [christianc@enhydra.org]
Barracuda - MVC Component Framework for Webapps
http://barracuda.enhydra.org
------------------------------------------------
"What a great time to be a Geek"
> -----Original Message-----
> From: gmj@mta8.srv.hcvlny.cv.net [mailto:gmj@mta8.srv.hcvlny.cv.net]On
> Behalf Of Geir Magnusson Jr.
> Sent: Monday, June 11, 2001 10:12 PM
> To: velocity-user@jakarta.apache.org
> Subject: Re: What about Barracuda?
>
>
> Christian Cryder wrote:
> >
> > 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).
>
> That's ok. I prollie haven't read much of the XSLC docs :)
>
> >
> > > 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.
>
> I would be interested to know what motivated this premise.
>
> > 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.
>
> I have a bit of issue there with the phrase 'programming logic'. Why?
> Because while it is totally accurate, it's a little misleading : I
> believe that designers need the ability to use basic logic for design
> and navigation - as long as that logic isn't "business logic", then I
> think there is nothing wrong with it.
>
> It does tend to lead to the designer taking over some of the application
> flow control, and while MVC fundamentalists might whine, it seems to
> work very well in practice.
>
> > 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).
>
> Does that require the maintenance of two things to render one page? One
> 'valid' template, and one id-to-directive mapping?
>
> > > 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.
>
> I scanned it, and I suppose I am very guilty of the smudging of the
> lines myself. However, I don't agree with your premise as it seems to
> be based on the assumption that there is a component+interface
> requirement for MVC, whereas my understanding of MVC was based more on
> the existance of a change / user-event notification system between the
> parts of some kind, rather than a specific notion like 'interface',
> which is language dependant.
>
> Granted, I (and others, I guess) tend to glob C&M together (V can't
> distinguish between - all interaction tends to be between V and C due to
> architectural constraints of webapps).
>
> > > 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
>
> I assume you mean 'component' as in 'object'? Where does the mapping
> come from to tell you how to do this?
>
> > -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...
>
> Honestly, not really - but it does motivate me to take a look. I think
> that it will turn out (when we both do more homework) that Velocity is
> even lower level - it's simply a templating system, and it makes very
> little demands upon the architecture used. The only demand is that it
> must be fed - it doesn't forage for itself -> there must be a mechanism
> to populate the context to 'back' the references in the templates, as
> there is no 'new' or other object instantiation mechanism. This is what
> we believe makes it so safe. I have heard it argued that Velocity's
> allowance of walking down the 'method path'
>
> $foo.bar().woogie().doThis().doThat()
>
> is unsafe, as effectively allows new objects to be created, but I don't
> buy it.
>
> It's only when you use it in something like Turbine, Struts, or the
> various home-grown frameworks that it acquires more of a real
> architectural shape.
>
> > > 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.
>
> Right - I am interested in knowing the motivation behind that.
>
> > > 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?
>
> Of course! It think it's very doable. Because Velocity is 'nothing
> more' than a template spec and the engine, it's easy to adapt.
>
> There is an example already for using Velocity with Enhyrda, done by
> Dave Bryson. It is in our CVS under contrib/temporary/enhydra-velocity,
> but that may not be Barracuda.
>
> > > 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).
>
> Lets do it :)
>
> > > 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?)
>
> People deal : someone has worked out how to get Dreamweaver to do it,
> and we have been tossing around making an input filter to remove <% and
> %>.
>
> Note that I would argue that <%foo%> isn't really valid markup. :)
>
> > 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)
>
> This I don't get. Velocity offers something I call 'introspective
> polymorphism' - it allows you to use as the backing 'data object'
> anything that has the right 'shape'. By this I mean if you had a
> reference in a template :
>
> $address.city
>
> you could satisfy this in a few ways. First, a formal object or two
>
> public class AddressData
> {
> public String getCity();
> }
>
> or
>
> public class AddressData
> {
> public String get( String which );
> }
>
> or be lazy and just use a Map
>
> map.put("city", "Baltimore");
>
> and when you put any of these in the context associated with 'address'
>
> AddressData addressData = new AddressData();
> context.put("address", addressData);
>
> or
>
> context.put("address", map );
>
> then it will work - Velocity isn't tightly bound to the specific class
> of object to resolve a reference.
>
> The point is that if you are concerned that a template contrains the
> data model used for rendering, it doesn't. You as the programmer have
> tremendous freedom in satisfying the agreed upon 'data API'.
>
> > 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...
>
> I am interested in seeing this work. I stopped by the enhydra booth at
> JavaOne to pitch Velocity, to talk about putting together an example,
> but I don't think anyone understood me. So they gave me a shirt, I
> guess to get rid of me, and only when I was unpacking did I notice it
> was only a Large. Alas.
>
> geir
>
> --
> Geir Magnusson Jr. geirm@optonline.net
> 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!
Re: What about Barracuda?
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Christian Cryder wrote:
>
> 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).
That's ok. I prollie haven't read much of the XSLC docs :)
>
> > 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.
I would be interested to know what motivated this premise.
> 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.
I have a bit of issue there with the phrase 'programming logic'. Why?
Because while it is totally accurate, it's a little misleading : I
believe that designers need the ability to use basic logic for design
and navigation - as long as that logic isn't "business logic", then I
think there is nothing wrong with it.
It does tend to lead to the designer taking over some of the application
flow control, and while MVC fundamentalists might whine, it seems to
work very well in practice.
> 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).
Does that require the maintenance of two things to render one page? One
'valid' template, and one id-to-directive mapping?
> > 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.
I scanned it, and I suppose I am very guilty of the smudging of the
lines myself. However, I don't agree with your premise as it seems to
be based on the assumption that there is a component+interface
requirement for MVC, whereas my understanding of MVC was based more on
the existance of a change / user-event notification system between the
parts of some kind, rather than a specific notion like 'interface',
which is language dependant.
Granted, I (and others, I guess) tend to glob C&M together (V can't
distinguish between - all interaction tends to be between V and C due to
architectural constraints of webapps).
> > 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
I assume you mean 'component' as in 'object'? Where does the mapping
come from to tell you how to do this?
> -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...
Honestly, not really - but it does motivate me to take a look. I think
that it will turn out (when we both do more homework) that Velocity is
even lower level - it's simply a templating system, and it makes very
little demands upon the architecture used. The only demand is that it
must be fed - it doesn't forage for itself -> there must be a mechanism
to populate the context to 'back' the references in the templates, as
there is no 'new' or other object instantiation mechanism. This is what
we believe makes it so safe. I have heard it argued that Velocity's
allowance of walking down the 'method path'
$foo.bar().woogie().doThis().doThat()
is unsafe, as effectively allows new objects to be created, but I don't
buy it.
It's only when you use it in something like Turbine, Struts, or the
various home-grown frameworks that it acquires more of a real
architectural shape.
> > 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.
Right - I am interested in knowing the motivation behind that.
> > 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?
Of course! It think it's very doable. Because Velocity is 'nothing
more' than a template spec and the engine, it's easy to adapt.
There is an example already for using Velocity with Enhyrda, done by
Dave Bryson. It is in our CVS under contrib/temporary/enhydra-velocity,
but that may not be Barracuda.
> > 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).
Lets do it :)
> > 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?)
People deal : someone has worked out how to get Dreamweaver to do it,
and we have been tossing around making an input filter to remove <% and
%>.
Note that I would argue that <%foo%> isn't really valid markup. :)
> 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)
This I don't get. Velocity offers something I call 'introspective
polymorphism' - it allows you to use as the backing 'data object'
anything that has the right 'shape'. By this I mean if you had a
reference in a template :
$address.city
you could satisfy this in a few ways. First, a formal object or two
public class AddressData
{
public String getCity();
}
or
public class AddressData
{
public String get( String which );
}
or be lazy and just use a Map
map.put("city", "Baltimore");
and when you put any of these in the context associated with 'address'
AddressData addressData = new AddressData();
context.put("address", addressData);
or
context.put("address", map );
then it will work - Velocity isn't tightly bound to the specific class
of object to resolve a reference.
The point is that if you are concerned that a template contrains the
data model used for rendering, it doesn't. You as the programmer have
tremendous freedom in satisfying the agreed upon 'data API'.
> 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...
I am interested in seeing this work. I stopped by the enhydra booth at
JavaOne to pitch Velocity, to talk about putting together an example,
but I don't think anyone understood me. So they gave me a shirt, I
guess to get rid of me, and only when I was unpacking did I notice it
was only a Large. Alas.
geir
--
Geir Magnusson Jr. geirm@optonline.net
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!
RE: What about Barracuda?
Posted by Christian Cryder <ch...@enhydra.org>.
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 [christianc@enhydra.org]
Barracuda - MVC Component Framework for Webapps
http://barracuda.enhydra.org
------------------------------------------------
"What a great time to be a Geek"
> -----Original Message-----
> From: gmj@mta6.srv.hcvlny.cv.net [mailto:gmj@mta6.srv.hcvlny.cv.net]On
> Behalf Of Geir Magnusson Jr.
> Sent: Saturday, June 09, 2001 12:28 PM
> To: turbine-user@jakarta.apache.org
> 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. geirm@optonline.net
> 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: turbine-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-user-help@jakarta.apache.org
>
Re: What about Barracuda? (Was Re: JavaOne Struts BOF)
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
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. geirm@optonline.net
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: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
RE: What about Barracuda? (Was Re: JavaOne Struts BOF)
Posted by Christian Cryder <ch...@enhydra.org>.
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.
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.
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.
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.
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.
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.
> 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.
> There may be many other non-obvious differences.
Barracuda focuses on delivering 4 key pieces of technology:
1. Strongly typed MVC Component Model - we've beaten this to death up above.
2. Event Model - convert requests into first class even objects and deliver
them to interested listeners. This provides the Model 2 flow control aspects
of the system. It also enables you to add server-side listeners to
components and get notified when client-side events occur (again, just like
in Swing)
3. Form Mapping and Validation framework - convert HTTP Req params into
first class objects and validate them
4. Localization services - automatically localize templates based on values
found in properties files; you can then load the appropriate template for a
given locale (it'll find the closest match, just like with ResourceBundles)
Each of these is designed to be used independantly, so you can pick and
choose which part makes sense for you.
If you want more information on this, you should really refer to the
Barracuda site and ask questions there. I don't want to take up any more
Turbine bandwidth discussing issues that would be better covered on the
Barracuda list.
Hope this helps,
Christian
------------------------------------------------
Christian Cryder [christianc@enhydra.org]
Barracuda - MVC Component Framework for Webapps
http://barracuda.enhydra.org
------------------------------------------------
"What a great time to be a Geek"
> -----Original Message-----
> From: Alex McLintock [mailto:alexmc@yahoo.com]
> Sent: Friday, June 08, 2001 3:28 AM
> To: turbine-user@jakarta.apache.org
> Subject: Re: What about Barracuda? (Was Re: JavaOne Struts BOF)
>
>
>
> --- John Thorhauer <jo...@zenplex.com> wrote:
> > On Friday 08 June 2001 01:09, Bruno Unna wrote:
> > >
> > > Nonetheless, since the time I started to use Turbine, Lutris came out
> > > with their first beta release of Barracuda, and since I'm yet in the
> > > early stages of my first project with Turbine, I'm feeling just as a
> > > fifteen years old girl about to make *the* decision of her life... :)
> >
> > I dont know much about Barracuda but if you tell us what it
> does, maybe we
> > can help you understand how turbine might accomplish the saem thing,
> >
> > John
>
> I think the poster was hoping that we had already evaluated Barracuda.
> It appears to be a component orientated framework for building
> web applications.
> The main difference between Turbine and Barracuda that I read
> about on the
> website seems to be the choice between Velocity or XMLC2
>
> But since you can plug in any templating system you like into Turbine that
> seems a bit of a moot point.
>
> There may be many other non-obvious differences.
>
>
> If evaluating the two systems you need to look at two things
>
> 1) The current codebase.
> 2) the people involved in doing future development.
>
> I am not in a position compare the code - you should do it
> yourself - you can download
> both since they are open source. However I have looked at a lot
> of Apache Java code
> and in general I find it of very high quality.
>
> The latter is definitely a personal opinion. Enhydra appears to
> be far glossier
> than Apache with better logos and graphic design on the website. Apache
> Turbine suffers from a rather steep learning curve - you need to learn
> a lot to get things going, but maybe this list will help improve matters.
>
> -----------
>
> To paraphrase one vociferous Turbine developer who said something like:
>
> "You could use Enhydra, but then you'd have to use XMLC, and that
> would be horrible".
>
> However maybe XMLC2 is better than XMLC and maybe better than Velocity?
> I'd be surprised though. Velocity has had enough people using it
> and developing
> it to satisfy me.
>
> Alex McLintock
>
>
>
> =====
> Alex McLintock alex@OWAL.co.uk
> OpenWeb Analysts Ltd, http://www.OWAL.co.uk/
> DR WHO COMPETITION:
http://www.diversebooks.com/cgi-bin/caption/captions.cgi?date=200104
Get Your XML T-Shirt <t-shirt/> at http://www.inversity.co.uk/
____________________________________________________________
Do You Yahoo!?
Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk
or your free @yahoo.ie address at http://mail.yahoo.ie
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: What about Barracuda? (Was Re: JavaOne Struts BOF)
Posted by Alex McLintock <al...@yahoo.com>.
--- John Thorhauer <jo...@zenplex.com> wrote:
> On Friday 08 June 2001 01:09, Bruno Unna wrote:
> >
> > Nonetheless, since the time I started to use Turbine, Lutris came out
> > with their first beta release of Barracuda, and since I'm yet in the
> > early stages of my first project with Turbine, I'm feeling just as a
> > fifteen years old girl about to make *the* decision of her life... :)
>
> I dont know much about Barracuda but if you tell us what it does, maybe we
> can help you understand how turbine might accomplish the saem thing,
>
> John
I think the poster was hoping that we had already evaluated Barracuda.
It appears to be a component orientated framework for building web applications.
The main difference between Turbine and Barracuda that I read about on the
website seems to be the choice between Velocity or XMLC2
But since you can plug in any templating system you like into Turbine that
seems a bit of a moot point.
There may be many other non-obvious differences.
If evaluating the two systems you need to look at two things
1) The current codebase.
2) the people involved in doing future development.
I am not in a position compare the code - you should do it yourself - you can download
both since they are open source. However I have looked at a lot of Apache Java code
and in general I find it of very high quality.
The latter is definitely a personal opinion. Enhydra appears to be far glossier
than Apache with better logos and graphic design on the website. Apache
Turbine suffers from a rather steep learning curve - you need to learn
a lot to get things going, but maybe this list will help improve matters.
-----------
To paraphrase one vociferous Turbine developer who said something like:
"You could use Enhydra, but then you'd have to use XMLC, and that would be horrible".
However maybe XMLC2 is better than XMLC and maybe better than Velocity?
I'd be surprised though. Velocity has had enough people using it and developing
it to satisfy me.
Alex McLintock
=====
Alex McLintock alex@OWAL.co.uk
OpenWeb Analysts Ltd, http://www.OWAL.co.uk/
DR WHO COMPETITION: http://www.diversebooks.com/cgi-bin/caption/captions.cgi?date=200104
Get Your XML T-Shirt <t-shirt/> at http://www.inversity.co.uk/
____________________________________________________________
Do You Yahoo!?
Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk
or your free @yahoo.ie address at http://mail.yahoo.ie
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org