>> Please just consider the balance between flexibility in the framework and
>> intuitiveness / learnability for the users.
>
>
> My theory on this is that the documentation makes the difference. Spring
> and
> hibernate are not straightforward at all but they have large documentations
> that make it easy to get a project going.
>
>
> Thanks,
>
> Henri.
>
It's true that good documentation helps a great deal. However... too
much documentation can be a bad thing; if a system requires hundreds of
pages of documentation to understand it, isn't it possible that it's the
system with the problem, not the documentation? You brought up hibernate
which, imo, is a case in point. Now, I haven't tried to use hibernate
in a long time, and I hope that things are better now. However, I tried
using it a long time ago. When I had spent the better part of a day
reading documentation and had less of an idea what I was doing at the
end of the day than at the beginning, I got frustrated and looked at
alternatives. I ended up in the sweet spot that is cayenne; in less
than two hours, not only had I been through the documentation, and
understood it, but I had my db laid out, my objects mapped, my db
created, all of my objects created, and I was merrily on my way writing
/my/ code for /my/ project. Ultimately, what all frameworks have to
realize is that users are using the framework to make their lives
easier/better. The point at which a user perceives the complexity of
the framework as greater than the complexity of the task at hand is the
point at where that user will either code the task themselves or find
another framework. In that respect, I wonder if Tapestry's current
state of hivemind incorporation has crossed the threshold. In a typical
setup, users will now learn:
Spring
Hivemind
Hibernate
Tapestry
And all of that is just to get started. For a large chunk of
applications, I could write my application faster using straight
servlets and jdbc. And they would run faster and consume less memory.
In the "namespace" thread, Bryan and Geoff expressed their desire to be
exposed less to Hivemind; I'm definitely +1 on that. One of the main
things preventing me from upgrading my apps from 3.0 to 4.0 (and
therefore preventing me from upgrading my contributed components from
3.0 to 4.0) is the burden of time required to learn how Hivemind makes
everything fit together.
I'm not saying I'm opposed to Hivemind integration in tapestry; I
suspect that it has made the code cleaner, better, more customizable,
etc. I would just like to see it much more transparent in tapestry. I
want to learn tapestry to write webapps; I'm not interested in learning
Hivemind to write frameworks.
Robert
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
