Jon Stevens wrote:
> 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.
Fair enough. I think there's a combination of misguidance and timing at
work here though. While some points are due to me missing points about
Turbine, some seem to be related to that when I first looked at Turbine
(=day after you awarded me the first prize in the MyComponents.com
contest) there was no mention of "pull" in Turbine (AFAICT). Since I
wanted to use a pull HMVC framework, and I simply couldn't find one (at
all), I began doing one. AFAIK I wasn't reinventing the wheel since I
hadn't seen any pull HMVC frameworks at that time. (Still haven't,
although your claim that Turbine *is* that may be valid).
BTW, the "pull vs push" email Jon wrote on the Scarab list was some time
after I had already written the core of WebWork. So, when I read that I
thought "done that" and imagined that it would take Turbine quite a
while to get that kind of model. Especially, since my impressions of
Turbine (and I have now re-read the Turbine docs, and haven't seen
anything I might have missed the first time) was that it was a push MVC
model with too much API. So, instead of trying to push the WebWork ideas
into Turbine (which would have been an option, certainly) I continued,
and it has been going very well.
> 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.
True, Turbine has a larger scope than XMLC, but the reason I mentioned
them in the same sentence was because of the "push MVC" usage of both.
> 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.
True. I mentioned it as a common way to get multi-client support. If
Turbine has other ways to do that, please point me to do docs on how to
accomplish that.
> 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).
I have only looked at your documentation, and they mostly use ECS. And
when I looked at ECS (http://jakarta.apache.org/ecs/) I couldn't find
any. JavaDoc is fine, but not enough.
> 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>
I know, and I saw your original posting with this. Again, this was some
time after I had already written what you talk about, and while I think
it's excellent that you're very motivated towards pull MVC, we've
already done it. You're however welcome to steal any ideas from WebWork
that you find useful. Take enough of it, and I might consider dropping
WebWork in favor of Turbine.
> 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.
This is good, but doesn't help much if the API's you need to know to get
started is too much. But it's definitely a good thing to have.
> 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.
Precisely the deal with WebWork. Although from what I've seen the
minimum API needed to be productive with WebWork is much less than
Turbine.
> 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?
I didn't intend for it to be a real analysis. Those three were *enough*
(not complete) to not go any further in my analysis. There may be
hundreds more reasons not to like it, and there may be hundreds more
reasons *to* like it, but the reasons mentioned were enough not to go
further.
> Therefore, if you had truly analyzed Turbine, you would have not made the
> statements that you made.
They do not change the statements I made. Actually, they enforce my
statements. Or what did I miss in that analysis that was pro-Turbine?
> >> 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. :-)
Similar approach, but WebWork is cleaner and easier to code to. WebWork
is more of a perfection of how Struts work than a radical new way.
> > 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.
Almost true. There are still factors that you can judge these things by,
such as size of API, intuitivenes, and similarity to how "regular
programming" works. Since we have focused on using the JavaBeans
programming model and the JavaBeans API (PropertyEditors for example) it
does indeed becomes easier to work with. Statements by new users on our
mailing lists seem to verify this.
> 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.
Ok. I will though, motivated as above.
> > 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.
There is nada docs on the ECS homepage.
> It also has very good javadoc.
That doesn't bring much though in terms of "getting started".
> 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.
It's not difficult, it's just plain ugly. I will never ever use a
framework that relies on putting HTML in code. Been there, done that,
didn't like it.
> 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.
Again, I've re-read the Turbine docs at your site, and still haven't
found anything that says this. Please give me a pointer to how to use
another presentation model.
> > Yes, WebWork is two things:
> > 1) A Model-2 pull HMVC servlet/action API for controller JavaBeans
>
> So is Turbine.
1) HMVC has not been mentioned in any Turbine docs. Only MVC.
2) The only mention of "pull" is in your post, and "this is how we
should do" postings. Not "we do pull".
> > 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...
Sure, that would be one possibility.
> > 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.
Please point to how-to's on using JSP with Turbine.
> > 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.
That's one viewpoint. For me that would have been like if you had joined
the JBoss development and said "hey guys, EJB is dead, let's do a JDO
impl instead". Turbine seemed to be the same "what" but very different
"how".
regards,
Rickard
--
Rickard Öberg
Email: [EMAIL PROTECTED]
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
