You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@turbine.apache.org by "C. R. Oldham" <cr...@ncacasi.org> on 2001/06/30 05:37:31 UTC
Comparison between Enhydra+Barracuda, ACS 4.0.1, Tomcat+Turbine+Cocoon
Greetings,
I am a new lurker over the past few days. I haven't been through all of
the mailing list archives yet. We built a lot of our website with the
ArsDigita Community System version 3.4. We were pleased with it, as it
enabled us in many cases to focus on the problem at hand and not on the
tool (much).
Now we are faced with building some more complicated database-driven web
applications and might need to add staff. TCL programmers are a little
hard to come by, and ACS Java as it stands I don't think is ready for
prime time. ACS 5 will go beta in a few weeks, but there is lots of
question about the future of ArsDigita since the departure of Philip
Greenspun. OpenACS is possibly a viable alternative, but that would
keep us in the TCL world and I don't know if I want to stay there.
I really like the idea of the MVC paradigm--that kind of thing is
totally absent from the 3.x series of the ACS. I was wondering if any
of the list members had experience with Enhydra, ACS (Java or TCL), and
(obviously) Turbine, possibly in conjunction with Cocoon. Can anyone
comment (objectively :-) ) on why they would pick one over another?
And regarding Turbine directly, something that concerns me greatly is
the way a Turbine app has to interface with the database--via the Peer
objects, right? The ACS has a great database API that makes handling
selects easy, but most of your SQL statements end up in the page code
itself. I'd really like to leave most of the business logic in the
database, is it easy to do that with Turbine? Is working with the Peer
objects a real pain? What if I need to slap a quick page on our site
that pulls a query from the database and shows it in a table. In
Turbine, is that easy, or not?
Sorry about the ramble--I'm having a hard time getting my head around
this development model...Thanks in advance for any help.
--cro
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: Comparison between Enhydra+Barracuda,
ACS 4.0.1,Tomcat+Turbine+Cocoon
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Gary Lawrence Murphy wrote:
> If, on the other hand, you decide to use Turbine with the Velocity
> template service and the Torque OM service, and you provide your own
> $data service that provides a method to effect the query and return
> a list of results, the page you describe is simply
>
> #foreach $item in $data.getList
> <tr><td>$item.col1</td><td>$item.col2</td></tr>
> #end
>
> which is pretty darn simple.
>
> (those who know velocity macros better than I could probably craft a
> better example)
The only thing I would suggest is using parenthesis :)
#foreach( $item in $data.getList)
...
#end
And yes, you can wrap this in a VM :
#macro( mytable $list )
<table>
#foreach( $i in $list )
<tr><td>$i.col1</td><td>$i.col2</td></tr>
#end
</table>
#end
and use
#mytable( $data.getList )
but really, that doesn't buy you much until you want to start doing nice
formatting, which VMs really help with.
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: Comparison between Enhydra+Barracuda, ACS 4.0.1, Tomcat+Turbine+Cocoon
Posted by Gary Lawrence Murphy <ga...@canada.com>.
>>>>> "C" == C R Oldham <cr...@ncacasi.org> writes:
C> And regarding Turbine directly, something that concerns me
C> greatly is the way a Turbine app has to interface with the
C> database--via the Peer objects, right?
Not quite; when Jon says Turbine offers options, he refers to the history
of Turbine as a collection of tools (which I believe is stated on the
website) and that is exactly what you get, a collection of tools. If
peers works for you, it's there, and if not, you ignore it. Even the
core Turbine servlet, which is intended for session-managed multi-page
web applications, will be overkill for many situations --- no problem,
you just leave it out of your app and use it as a model for building
your own session-less website using all the other great tools in the kit.
C> ... Is working with the Peer objects a real pain?
Buddha said that suffering arises from attachment, and this is just as
true with software ;) All Turbine means by "peer" is that where one
object represents the table row, the peer contains the static methods
used to move rows in and out of the database. It makes no sense to ask
an object to return 100 dissimilar objects of the same type, so instead
you ask the peer of that class to do the lookup and fetch the list.
Where it becomes a pain is where you _know_ what you want to do in SQL
and stored procedures and you try to force the Torque model to do this
within its simple object-database mapping; fortunately, Torque
_extends_ JDBC, it does not replace it: If you know how to get the
effect you want in SQL, just use normal JDBC execute/query calls to do
it. Torque is just a convenience tool for the general case of
fetching records from one or more tables according to some criteria.
C> What if I need to slap a quick page on our site
C> that pulls a query from the database and shows it in a table.
C> In Turbine, is that easy, or not?
In _Turbine_ it is impossible; strictly speaking, turbine is just a
web-app framework servlet that allows for hooking services and
templates together with session management and multi-level
authentication.
If, on the other hand, you decide to use Turbine with the Velocity
template service and the Torque OM service, and you provide your own
$data service that provides a method to effect the query and return
a list of results, the page you describe is simply
#foreach $item in $data.getList
<tr><td>$item.col1</td><td>$item.col2</td></tr>
#end
which is pretty darn simple.
(those who know velocity macros better than I could probably craft a
better example)
If Velocity is not your thing, use WebMacro or JSP or plug in your
own. If Torque doesn't turn your crank, use Castor or whatever you
like. The services bundled with Turbine are just examples of useful
(Apache licenced) tools. You are free to use them, change them, steal
from them, or ignore them.
C> Sorry about the ramble--I'm having a hard time getting my head
C> around this development model...Thanks in advance for any help.
As with any new technology, I know where you're coming from: You are
looking at a package and wondering if it would take more time (=money)
to learn it than to re-write it, or whether some other application
framework might cost less to implement; any response that does not
provide this information or demands your placing a sizeable investment
of time (=money) is not all that helpful (it just makes Turbine more
expensive and thus less attractive).
You should know up front that Turbine is not a product, it is not a
service by one company to another. It has no business case or sales
pitch to give you, no salesman will ever call ;) To my mind, this is a
great advantage because, unlike ACS or WebSphere, Turbine is not the
worm on the end of a hook that eventually wants to make money off you,
but is instead a community thing that really wants and honestly
invites your participation to help make things better for the whole
community. Working together, we can (and do) blow WebSphere out of
the water.
Turbine is just a collection of web-application-oriented code, amassed
by fellow developers as they needed it, modified by others as they saw
fit, and kept in sync and order by a few volunteers. There's no
guarantee, no promises and we can't really tell you if it works for
your project because we are all busy on our own projects; the best
endorsement we can offer is a word-count for the number of times the
phrase "Turbine rocks" shows up in the mailing list ;)
Personally, the total control of having a stake in Turbine
development, the freedom of being a participant rather than a
consumer, and the power to determine my own production schedules and
not be at the mercy of some corporate todo list, all of these abstract
business-case features more than compensate for the inconvenience of
having to reverse-engineer Turbine to use it.
--
Gary Lawrence Murphy <ga...@teledyn.com> TeleDynamics Communications Inc
Business Innovations Through Open Source Systems: http://www.teledyn.com
"Computers are useless. They can only give you answers."(Pablo Picasso)
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: Comparison between Enhydra+Barracuda, ACS 4.0.1, Tomcat+Turbine+Cocoon
Posted by Eric Dobbs <er...@dobbse.net>.
Sorry to join the conversation late. I might be able to add just a bit
to what Gary offered (nice post, Gary).
On Friday, June 29, 2001, at 09:37 PM, C. R. Oldham wrote:
> I really like the idea of the MVC paradigm--that kind of thing is
> totally absent from the 3.x series of the ACS. I was wondering if any
> of the list members had experience with Enhydra, ACS (Java or TCL), and
> (obviously) Turbine, possibly in conjunction with Cocoon. Can anyone
> comment (objectively :-) ) on why they would pick one over another?
Can't say anything about Enhydra+Barracuda, nor about much about
Cocoon. I did go through ArsDigita's training for the ACS about
a year ago (so my ACS knowledge is a year old).
ACS and Turbine have pretty different world views.
For example, in ACS the web application is a thin interface over
a beefy Oracle database (or PostgreSQL for OpenACS). In Turbine
the database is abstracted through database adaptors so that it
does not have to depend on any one database. As Gary and Jon
mentioned, there's nothing about Turbine that will keep you from
leveraging your investment in Oracle specific features. But that
may not be obvious as you browse the documentation and the list
archive.
You've already identified another significant difference. The
ACS use of TCL compares quite closely with common practices in
ASP, JSP, PHP, Cold Fusion, Tango, and others. Basically, embed
code in html pages. Turbine applies the MVC pattern to web
development. I think this is an exceptionally good move. The
use of actions also brings something of an event driven model to
web development. (I think ACS modules tend to use 302 redirects
to do something analogous to Turbine's actions, but I like the
actions better).
Another big difference is that the modules that come with a base
installation of the ACS are much further along than what you will
find in the TDK. As Gary said, Turbine is a toolkit for building
web applications. Whereas I think ACS has a suite of web
applications that must be customized and extended. You might
have a little more work to do to get started with Turbine, than
you are accustomed to with ACS.
ACS is under a GPL, Turbine is under APL. Insert the usual debate
here.
Hope that helps.
-Eric
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: Comparison between Enhydra+Barracuda, ACS 4.0.1,
Tomcat+Turbine+Cocoon
Posted by Jon Stevens <jo...@latchkey.com>.
on 6/29/01 8:37 PM, "C. R. Oldham" <cr...@ncacasi.org> wrote:
> And regarding Turbine directly, something that concerns me greatly is
> the way a Turbine app has to interface with the database--via the Peer
> objects, right?
Not at all.
<repeat>
The first thing that you need to learn about Turbine is that it doesn't
force you to do anything any particular way. It presents options of things
to use and it is up to you to decide whether or not you want to use them.
</repeat>
> The ACS has a great database API that makes handling
> selects easy, but most of your SQL statements end up in the page code
> itself. I'd really like to leave most of the business logic in the
> database, is it easy to do that with Turbine?
The Peer objects make that easy. But, what confuses me greatly is here you
are asking for a feature, we provide a solution to that problem and you are
saying that it "concerns you greatly"...I don't get it.
> Is working with the Peer
> objects a real pain?
<sarcastic>
Yes, the goal of Turbine is to make working with it and its tools as hard as
possible.
</sarcastic>
> What if I need to slap a quick page on our site
> that pulls a query from the database and shows it in a table. In
> Turbine, is that easy, or not?
"Easy" is relative.
> Sorry about the ramble--I'm having a hard time getting my head around
> this development model...Thanks in advance for any help.
Spend some more time reading and playing...we have spent a great deal of
time creating the TDK, the least you could do is spend time playing with it
and seeing for yourself.
Thanks,
-jon
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org