More good points.
The good news is that IMHO we don't have an architecture problem so much as
a documentation problem. People ~should~ be able to get started in tapestry
with a simple "hello world" type of application without having to grock
everything at once. That is just overwhelming.
Here are some further ideas to help things in this regard:
-) HiveDocs - It would be nice if the class/interface param of each service
definition included an href link to the JavaDoc counterpart for the class.
If this is an xsl translation (which I think it is), it's probably not more
than a 15 minute exercise to make happen.
-) Previous mentions of consolodating documentation combined with providing
a quick & easy to use reference for the core things you'll need + elmination
of .library/.application will go a looooongg way towards helping.
-) Don't know if it's possbile/feasible, but the current HiveDocs are also a
little overwhelming in length....For the majority of users about 80% of what
is in there will never be used. It's probably not a reality that we'll be
able to define one global sort of tapestry.xml hivemodule that has all of
the core services aliased into one easy to read file, but we can certainly
provide xdoc style maven2 documentation on the core service points people
will need within the tapestry umbrella.
To this day I still don't know how Howard managed to create 2 frameworks &&
maintain the communities && somehow earn a living. It's not human ;)
I still strongly believe that the majority of our issues all revolve around
the backwards compatibility going from 3->4. It shows in the documentation
and in things like .library/.application still existing.
It would be very interesting to see what a set of documentation that only
included the relevant 4.0 features would look like. The current 4.0 site is
sort of a rats nest of links / pages...It's not anyone's fault - but also
not that hard of a problem to solve.
So, we shall see. I haven't converted the current docs to maven2 xdoc / apt
yet but when it does happen I think we'll all be pleasantly surprised. Just
as long as that conversion is combined with removing old cruft + documenting
the new additions James has been adding.
my 2 cents..
On 6/16/06, Robert Zeigler <[EMAIL PROTECTED]> wrote:
>> 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]
--
Jesse Kuhnert
Tacos/Tapestry, team member/developer
Open source based consulting work centered around
dojo/tapestry/tacos/hivemind.
