Hi all,
This isn't meant to start a flame war. But, I am going to respond in such a
way as to hopefully not even entice a response from you Rickard. I just want
to clarify a few of your statements because your views of Turbine are
clearly misguided somehow.
p.s. I'm happy now that you are starting your own framework. I think that
you are going to end up spending a lot of time explaining to others why your
framework is different from other frameworks (you are already having to do
that). Oh well. Good luck with it.
-jon
on 1/11/01 4:47 AM, "Rickard Öberg" <[EMAIL PROTECTED]> wrote:
> I'm the main author of WebWork. While it is somewhat apparent that Jon
> hasn't really looked at WebWork, I will try to answer as best as I can.
Actually. I did.
> Anyway, I have made a comparison with Turbine. Just haven't copied it
> into the docs yet:
> http://www.geocrawler.com/archives/3/7709/2000/12/0/4763903/
I disagree. Your statements about Turbine are not factual at all. Let me
explain why:
> (XMLC and Turbine for example)
You are placing Turbine with XMLC. Right there you have a serious disconnect
into what Turbine and/or XMLC is. Turbine is a framework. XMLC is a
presentation layer.
Next, if your email, you go on to talk about XML and XSLT. Turbine doesn't
push or require that at all. I hate XSLT.
You are next comparing ECS and WebMacro. Two things that are considered
fairly deprecated within Turbine at this point (yes, we still support WM,
but we encourage the use of Velocity and ECS as a presentation layer has
been deprecated for about a year now).
Let me also state that we are also *very* motivated towards the Pull MVC
model and very against the Push MVC model. I even went as far as documenting
something on the website along those lines...
<http://java.apache.org/turbine/pullmodel.html>
In response to your claim about Turbine being hard to learn, let me also
state that we have been working hard on a Turbine Developers Kit, which is a
bundle of *everything* you need to get started with Turbine all in one
pre-configured and ready to go package. We are on our 10th alpha revision of
it now.
I will state that your framework will eventually get large and hard to learn
as well. We have been doing this for over three years now with over 35
people contributing, of course we are going to provide you with a lot of
software. However, not all of it needs to be learned on the first day. You
learn as you develop your applications and they grow to need the features
that Turbine provides.
Lastly, in your email, you have really only stated about three partial
sentences about why you don't like Turbine. Do *you* consider that a real
analysis? Let me point you at:
<http://barracuda.enhydra.org/Barracuda/docs/landscape.html>
At least they made a real effort to do comparisons of not only Turbine, but
several other frameworks as well. I think that is highly valuable.
Therefore, if you had truly analyzed Turbine, you would have not made the
statements that you made.
>> I also would argue that competing
>> with Struts is stupid as well.
>
> Because..?
Because your framework is doing something similar to what Struts is doing.
It is that reinvention of the wheel that you claim you hate. :-)
>> Anyone who has worked in the web app framework area long enough knows that
>> they all grow to the point where it is to large for *someone* to be able to
>> understand it.
>
> Oh really. Universal truth of the day, eh?
>
> WebWork has been specifically designed so that there is a minimal
> initial learning curve, and you can then learn the additional features
> as they become needed.
What is minimal to one person is not to another. You are well aware of how
your framework works. Just like I am of Turbine. However, *anyone* who isn't
is still going to have a learning curve. Be it simply learning Java all the
way to learning the ins and outs of your framework.
Therefore, claiming that your framework has a minimal initial learning curve
really cannot be made. I wouldn't make that for *any* piece of software, let
alone a framework level tool.
> Compare this with Turbine where there's quite a bit of API's you need to
> understand before you can even begin to do things. Not to mention some
> of the needed API's are not very well documented, such as ECS.
ECS is actually very well documented, not by us, by the company that we
cloned it from BEA. It also has very good javadoc. Every method and every
class is javadoc documented. So is Turbine btw. Regardless, though, ECS is
very easy to use. I'm not sure how:
B b = new B("duh");
b.toString();
Is so difficult for you and others to learn.
If you are working within Turbine however, you won't even write a single
line of ECS. If you had truly analyzed Turbine you would have seen that.
> Yes, WebWork is two things:
> 1) A Model-2 pull HMVC servlet/action API for controller JavaBeans
So is Turbine.
> 2) A taglib for JSP views that want to extract the results from the
> JavaBeans
Turbine is not that in that it doesn't attempt to focus on JSP as much as
you do and that is probably the largest disconnect. If one was going to use
taglibs with JSP with Turbine, I would suggest that they use the Jakarta
Taglibs project stuff...in which case, I would also suggest that you
contribute your taglibs to the Jakarta project as well instead of creating
your own taglibs project. That is the *point* of the Jakarta Taglibs
project...
> The two can be used separately or together. Our examples use both, but
> it would be ok to use (for example) WebMacro or similar as the view
> technique instead. Or another taglib.
Exactly what Turbine does. If you look at Turbine, we provide WebMacro,
Velocity, JSP, Freemarker, ECS...blah blah blah integration out of the box.
> Almost: we're solving the exact same problems in quite a different way.
How? Actually, don't answer that. It isn't worth the flame war.
> If I were to say "our way of solving the problem is superior to how
> Turbine does it, so please stop working on that and come help us
> instead" would you do that? Probably not.
I would say that you should have joined Turbine in the first place and
attempted to fix the problems you saw in Turbine.
> And since we are convinced that we do in fact have a superior way of
> solving the problem, why would we want to work on Turbine instead? That
> doesn't make any sense.
Because you clearly don't have an understanding of how Turbine really works.
> I didn't expect you to give a fair judgment of WebWork, but you haven't
> really tried, so...
Actually, how can you make that statement? For what it is worth, I spent
about 2 hours looking over your source code.
thanks,
-jon
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
