I will echo Kranga's #1 and #2 and add a couple. I'm all for
convention over configuration, but when you have to dig out the
convention out of source code, mailing list, or somewhere else, I'd
wish I had a well defined interface that I could just implement. The
not-so-pojo aspect becomes too apparent when you have to write some
test cases against the said components and you start scratching you
head about "now, how do I make all of those magical annotations work
if I don't do the whole IoC bit where it will inject everything".
One additional difficulty is that T5's model is so different in
respect to AJAX that it takes a while to wrap (or warp) your head
around what you need to do in order to do something seemingly simple
w/ a known Javascript framework (e.g. think Dojo, Prototype, jQuery).
There are a plethora of people out there that know how to make up a
snazzy ajaxy interface; however, when it comes down to T5 you have to
jump through a couple of hoops just to get the URL to which the Ajax
code will hook into (e.g. the componentResources.createPageLink ,
createEventLink, etc). Componetization support and all within T5 is
nice, but when you have to climb a big hill of learning a lot of T5
before you can do a silly autocompletion example for Dojo or jQuery,
it just makes it harder than necessary. Certainly not a boon.
Finally, it's great that T5 is so well decomposed into small
interfaces , so that you can override anything you want. However, too
many small classes/interfaces + a bunch of dependencies on each other
(which are really easy to do when IoC can magically inject
dependencies for you) starts being a drag when you want to
implement/override one, and then you realize that in order to do one,
you need to figure out a bunch more things that need to be injected
(or something like that). It's really easy to get into a rabbit hole
of "oh, I wanted to implement this one thing, now I have to understand
these other three before I can implement the first one"
Otho,
I don't think the point of this thread is for us to prove that the
issues that are brought up are not actually issues. The fact that
people bring them up, means that those issues still exist. I doubt
that someone will go through the trouble of typing up a big email
regarding his troubles w/ T5 if these were not issues that he/she has
dealt with.
Cheers,
Alex K
On Thu, Apr 30, 2009 at 9:28 AM, kranga <kra...@k2d2.org> wrote:
> 1) Documentation: It is one thing to remove dependencies on framework
> interfaces but quite another to leave the developer hanging with no
> documentation. Programming by convention is programming in the dark if
the
> convention is not known.
> 2) Although Tapestry claims to be POJO, you still have to have a
> contract
> (whether it is methods by convention or annotated methods). In the long
run
> whether this is really better than interface implementation is not
> fully
> proven (much like the current debate of whether dynamically typed
languages
> will prove more difficult to maintain in the long run).
> 3) Lack of a component marketplace: Wow, 4 years on and this is still
> on
my
> list. We wrote a gigantic application in Tapestry 3 which is still in
> production. But we've decided to write all new apps in JSF with the aim
of
> quickly adopting 2.0 when the spec is released. The main reason - a
plethora
> of components to choose from.
> 4) Developer mindshare: Our analysis with Tapestry 3 shows that for
> every
> developer we hire, we have to write off 2-4 weeks until they become
> well
> versed in Tapestry. I don't believe T5 will be any different. You
> cannot
> argue against a standard like JSF that is supported by vendors. The
> lack
of
> penetration of JSF speaks to its terrible initial design which
> hopefully
> will be rectified in 2.0
>
> I don't believe Tapestry will dwindle and die but I don't see it
> becoming
> the defacto standard ala Struts in the early 2000s.
>
> --------------------------------------------------
> From: "Pedro Januário" <prnjanua...@gmail.com>
> Sent: Thursday, April 30, 2009 5:43 AM
> To: "Tapestry users" <users@tapestry.apache.org>
> Subject: Re: T5: What is NOT beautiful about Tapestry?
>
>> I totally agree with Hugo's ideia.
>> The wiki sounds good and should be a easy to make documentation about
>> common
>> problems.
>>
>> 2009/4/30 Hugo Palma <hugo.m.pa...@gmail.com>
>>
>>> I agree a book would be great, what happened to the tapestry5-book
>>> project http://code.google.com/p/tapestry5-book/ ?
>>>
>>> Still, i think a lot better could be done with the online
documentation.
>>> I believe the structure of the online documentation should be very
>>> similar to a book, it should start with the basics and evolve to more
>>> "hardcore" stuff from there. Just the fact that the current
>>> documentation is structured with only one level of depth and the list
>>> of item is ordered alphabetically makes the task of finding some
>>> information much more difficult.
>>>
>>> I for example really like how the hibernate documentation is
>>> structure, i usually have to problem finding what i'm looking for
>>> there.
>>> So, maybe the wiki could be a starting place for the birth of a
>>> documentation with such a structure.
>>>
>>> On Thu, Apr 30, 2009 at 10:06 AM, Blower, Andy
>>> <andy.blo...@proquest.co.uk> wrote:
>>> > I think you hit the nail on the head Carl. The documentation is
>>> > okay
>>> generally (some bits poor, some very good) but there is not enough to
tie
>>> it
>>> all together and guide new developers so they know what they can do
with
>>> T5.
>>> I'm not convinced that the main documentation should attempt this on
its
>>> own, or whether it should strive to be a great reference with some
>>> more
>>> higher level introductory/discovery bits along with a good published
book
>>> to
>>> handle introducing everything and tying it together. Having the only
>>> published book for T5 being so out of date is a huge problem for the
>>> framework in my opinion.
>>> >
>>> > I don't think a wiki is the answer to this, I really like knowing
that
>>> the documentation that I'm looking at is for a specific version of
>>> Tapestry
>>> and is updated when the code is - I would not want to lose that.
>>> >
>>> > Andy.
>>> >
>>> >> -----Original Message-----
>>> >> From: Carl Crowder [mailto:carl.crow...@taptu.com]
>>> >> Sent: 29 April 2009 22:04
>>> >> To: Tapestry users
>>> >> Subject: Re: T5: What is NOT beautiful about Tapestry?
>>> >>
>>> >> Discovery of it's parts. Franky the documentation is lacking and
even
>>> >> with reading the mailing list, reading the howtos wiki, buying the
>>> >> Tapestry 5 book and working with it for over a year I still come
>>> >> >>
>>> >> across
>>> >> things I never knew existed that would have solved a problem I've
had.
>>> >> I
>>> >> often spend ages writing something myself after searching for a
>>> >> solution.
>>> >>
>>> >> What's beautiful about Tapestry? That almost every problem has a
>>> >> >>
>>> >> simple
>>> >> solution built in. What's not beautiful about Tapestry? That I
>>> >> generally
>>> >> find these solutions by accident, and way after I've written my
>>> >> own!
>>> >>
>>> >> Lots of things are obvious and easy to understand once you know
>>> >> what
>>> >> they are but it's learning what they are that is the problem. I've
>>
>>> >> been
>>> >> waxing lyrical about Tapestry where I work and while the
>>> >> developers
>>
>>> >> who
>>> >> tried it love it, their main gripe is always that it's difficult
>>> >> to
>>> >> understand what it can do.
>>> >>
>>> >> The cookbook is the right idea but it's only got 5 entries right
now.
>>> >> It
>>> >> needs to be way more comprehensive
>>> >>
>>> >> Inge Solvoll wrote:
>>> >> > Hi!
>>> >> >
>>> >> > I have been reading the "beautiful" thread and added my opinion
>>> >> > >>
>
>>> >> > about
>>> >> what's
>>> >> > great about Tapestry. It's nice to sum up why we all are so
excited
>>> >> about
>>> >> > this, it obviously makes both us and the creator(s) feel good
about
>>> >> > ourselves. But for a little while, I challenge us all to stop >>
>>> >> > >
>>> >> > tapping
>>> >> each
>>> >> > others' backs and go into depth about what's not to like about
>>> >> > our
>>> >> beloved
>>> >> > framework.
>>> >> >
>>> >> > The most obvious questions that could be asked probably have
>>> >> > some
>>> >> very
>>> >> > obvious answers. But T5, as I see it, is all about addressing
stuff
>>> >> that
>>> >> > other frameworks have given up on and create excellent
>>> >> implementations
>>> >> > rather than just looking the other way. Difficult and
uncomfortable
>>> >> > questions should be addressed the same way.
>>> >> >
>>> >> > So:
>>> >> >
>>> >> > What are the main reasons that T5 isn't one of the "big ones",
when
>>> >> we all
>>> >> > seem to agree that it is so much better than most other
>>> >> > frameworks
>>> >> out
>>> >> > there? Why is T5 NOT beautiful?
>>> >> >
>>> >> > Hope I'm not insulting anyone, I'm a big fan too, I just think
this
>>> >> actually
>>> >> > could lead to significant insight :)
>>> >> >
>>> >> > Regards
>>> >> >
>>> >> > Inge
>>> >> >
>>> >>
>>> >>
---------------------------------------------------------------------
>>> >> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
>>> >> For additional commands, e-mail: users-h...@tapestry.apache.org
>>> >>
>>> >
>>> >
>>> >
>>> > ---------------------------------------------------------------------
>>> > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
>>> > For additional commands, e-mail: users-h...@tapestry.apache.org
>>> >
>>> >
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
>>> For additional commands, e-mail: users-h...@tapestry.apache.org
>>>
>>>
>>
>>
>> --
>> Cumprimentos...
>> Pedro Januário
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
