You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Inge Solvoll <in...@gmail.com> on 2009/05/01 00:09:02 UTC
Re: T5: What is NOT beautiful about Tapestry?
Agree with Alex on the last comment about proving that issues don't exist!
I have one example of a trivial thing that I have found difficult to
implement in all Tapestry versions I have used(3, 4, 5):
- A form with a loop in it.
This is extremely common in the pages I make, and my mind always struggles
when trying to find how this is done in the new Tapestry version. I never
figured out a way to do it in 3 and 4 that made sense to me and looked
correct.
It also happened in T5. Maybe I'm stupid, but I really had to struggle hard
to track down the details needed to implement this correctly, using
encoders, initializing my form objects in the correct method in the correct
way, and so on. I didn't find an example in the docs showing me the best
practice for this (for me) very trivial and very common pattern.
On Thu, Apr 30, 2009 at 11:17 PM, Alex Kotchnev <ak...@gmail.com> wrote:
> 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 <kr...@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" <pr...@gmail.com>
> > Sent: Thursday, April 30, 2009 5:43 AM
> > To: "Tapestry users" <us...@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 <hu...@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
> >>> <An...@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.crowder@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-unsubscribe@tapestry.apache.org
> >>> >> For additional commands, e-mail: users-help@tapestry.apache.org
> >>> >>
> >>> >
> >>> >
> >>> >
> >>> > ---------------------------------------------------------------------
> >>> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> >>> > For additional commands, e-mail: users-help@tapestry.apache.org
> >>> >
> >>> >
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> >>> For additional commands, e-mail: users-help@tapestry.apache.org
> >>>
> >>>
> >>
> >>
> >> --
> >> Cumprimentos...
> >> Pedro Januário
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: users-help@tapestry.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
Re: T5: What is NOT beautiful about Tapestry?
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Fri, 01 May 2009 11:36:46 -0300, Tony Giaccone <tg...@gmail.com>
escreveu:
> That said, I'm not familiar at all with the changes in T5. However, the
> one thing that in the past has been a constant source of difficulty for
> everyone at my organization who's worked to learn Tapestry is the
> painful process of rewinding loops.
Welcome to Tapestry 5, that has no rewinding phase! :) Yes, the rewiding
in T4 was really hard to understand, so it was one of the first major
differences between T4 and T5.
--
Thiago H. de Paula Figueiredo
Independent Java consultant, developer, and instructor
http://www.arsmachina.com.br/thiago
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5: What is NOT beautiful about Tapestry?
Posted by Tony Giaccone <tg...@gmail.com>.
Let me second this point. I know Howard used his experience with
WebObjects as the starting point for Tapestry. I wish that starting point
included the kind of loop rendering that WebObjects provides. It's clear,
simple, straight forward. I imagine it wasn't used because it requires that
an instance of the object that represents the rendered page be bound to the
users session for an extended period of time, instead of going back into the
pool when the request is done. I assume this was done to improve
performance, and scalability. In my humble opinion, the trade off wasn't
worth it. :-)
Personally, having been familiar with and written 20 or 30 WebObjects Apps,
Tapestry was close enough, and yet different enough to be really both a joy
and totally annoying.
I haven't used T5 yet, we're going to continue using 4.1 for the foreseeable
future. We managed to get the funding to rewrite our app from an internally
developed toolset to T4, but I'm sure I wouldn't be able to get the funding
to do another major rewrite.
That said, I'm not familiar at all with the changes in T5. However, the one
thing that in the past has been a constant source of difficulty for everyone
at my organization who's worked to learn Tapestry is the painful process of
rewinding loops.
Tony Giaccone
On Thu, Apr 30, 2009 at 6:09 PM, Inge Solvoll <in...@gmail.com>wrote:
> Agree with Alex on the last comment about proving that issues don't exist!
>
> I have one example of a trivial thing that I have found difficult to
> implement in all Tapestry versions I have used(3, 4, 5):
>
> - A form with a loop in it.
>
> This is extremely common in the pages I make, and my mind always struggles
> when trying to find how this is done in the new Tapestry version. I never
> figured out a way to do it in 3 and 4 that made sense to me and looked
> correct.
>
> It also happened in T5. Maybe I'm stupid, but I really had to struggle hard
> to track down the details needed to implement this correctly, using
> encoders, initializing my form objects in the correct method in the correct
> way, and so on. I didn't find an example in the docs showing me the best
> practice for this (for me) very trivial and very common pattern.
>
>
> On Thu, Apr 30, 2009 at 11:17 PM, Alex Kotchnev <ak...@gmail.com>
> wrote:
>
> > 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 <kr...@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" <pr...@gmail.com>
> > > Sent: Thursday, April 30, 2009 5:43 AM
> > > To: "Tapestry users" <us...@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 <hu...@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
> > >>> <An...@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.crowder@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-unsubscribe@tapestry.apache.org
> > >>> >> For additional commands, e-mail: users-help@tapestry.apache.org
> > >>> >>
> > >>> >
> > >>> >
> > >>> >
> > >>> >
> ---------------------------------------------------------------------
> > >>> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > >>> > For additional commands, e-mail: users-help@tapestry.apache.org
> > >>> >
> > >>> >
> > >>>
> > >>> ---------------------------------------------------------------------
> > >>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > >>> For additional commands, e-mail: users-help@tapestry.apache.org
> > >>>
> > >>>
> > >>
> > >>
> > >> --
> > >> Cumprimentos...
> > >> Pedro Januário
> > >>
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > > For additional commands, e-mail: users-help@tapestry.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: users-help@tapestry.apache.org
> >
> >
>
RE: T5: What is NOT beautiful about Tapestry?
Posted by alanearl <al...@dash.com.ph>.
Yup, its true the only problem of Tapestry 5.
It lacks full documents that can help many newbies
to learn this framework.
As long as its FREE I will be a Tapestry lover...
Not all things in this world is EASY!
Newham, Cameron wrote:
>
> 3) Documentation - Good solid reference examples of how to do do simple
> apps, explained in detail. Most developers want a framework to be like
> lego
> building blocks. I do A, B, C and D and I get E. I assemble a dozen
> different pieces and I have my app. Really how complicated are most web
> apps? They are forms and workflow and validation. To get developers to
> use
> your framework you need good examples of how to do each, laid out and
> described in simple guaranteed to work steps. There need to be examples
> of
> these in both Netbeans and Eclipse; preferably several examples of
> each.
>
> -----------
>
> All good points, but this above all others I think. Developers never
> seem to fully appreciate this - or if they do, they make it a lesser
> priority.
>
> Documentation is critical. It doesn't matter how good something is (and
> that those "in the know" know it), it's rendered useless if the
> documentation doesn't exist or is not up to scratch. Tapestry 5
> documentation is not up to scratch. I'll repeat that: Tapestry 5
> documentation is not up to scratch.
>
> Why?
>
> Unfortunately there are a plethora of places to look in if you want to
> find how to do something. It's not only annoying for people who are
> developing in Tapestry, it is off-putting to new developers who are
> looking at this as a possible solution to a development problem.
>
> We've now reached a stage in web development where things should be easy
> to put together (Lego building blocks). I used to hate web development
> and Tapestry 3 was the first thing I found which helped me dislike it a
> lot less. Tapestry 5 even more so. However, having no good set of
> central documentation, how-tos, cookbook solutions, etc makes the
> development process that much harder and not like Lego blocks. I really
> only want to have to think about business logic and know only the basics
> of how Tapestry works. Turning to the source code should be a last
> resort and I've had to do that once so far with Tapestry 5 because the
> documentation I required was inadequate (can't remember what it was now,
> but it wasn't even anything exotic I was trying to do!)
>
> That said, I think this mailing list is fantastic and has certainly
> ridden to my rescue on numerous occasions. The only off-putting thing is
> the fear of asking the "dumb question". Sure, no questions are dumb, but
> I always feel a lot better if I know I've made an effort to find out how
> to do something before asking on here. Again, lack of good docs makes
> that effort so much harder and also increases the traffic on here by the
> same questions being asked multiple times.
>
> **************************************************************************
>
> Experience the British Library online at www.bl.uk
>
> The British Library's new interactive Annual Report and Accounts 2007/08 :
> www.bl.uk/knowledge
>
> Help the British Library conserve the world's knowledge. Adopt a Book.
> www.bl.uk/adoptabook
>
> The Library's St Pancras site is WiFi - enabled
>
> *************************************************************************
>
> The information contained in this e-mail is confidential and may be
> legally privileged. It is intended for the addressee(s) only. If you are
> not the intended recipient, please delete this e-mail and notify the
> postmaster@bl.uk : The contents of this e-mail must not be disclosed or
> copied without the sender's consent.
>
> The statements and opinions expressed in this message are those of the
> author and do not necessarily reflect those of the British Library. The
> British Library does not take any responsibility for the views of the
> author.
>
> *************************************************************************
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
>
--
View this message in context: http://old.nabble.com/T5%3A-What-is-NOT-beautiful-about-Tapestry--tp23304774p26603363.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
RE: T5: What is NOT beautiful about Tapestry?
Posted by "Newham, Cameron" <ca...@bl.uk>.
3) Documentation - Good solid reference examples of how to do do simple
apps, explained in detail. Most developers want a framework to be like
lego
building blocks. I do A, B, C and D and I get E. I assemble a dozen
different pieces and I have my app. Really how complicated are most web
apps? They are forms and workflow and validation. To get developers to
use
your framework you need good examples of how to do each, laid out and
described in simple guaranteed to work steps. There need to be examples
of
these in both Netbeans and Eclipse; preferably several examples of
each.
-----------
All good points, but this above all others I think. Developers never
seem to fully appreciate this - or if they do, they make it a lesser
priority.
Documentation is critical. It doesn't matter how good something is (and
that those "in the know" know it), it's rendered useless if the
documentation doesn't exist or is not up to scratch. Tapestry 5
documentation is not up to scratch. I'll repeat that: Tapestry 5
documentation is not up to scratch.
Why?
Unfortunately there are a plethora of places to look in if you want to
find how to do something. It's not only annoying for people who are
developing in Tapestry, it is off-putting to new developers who are
looking at this as a possible solution to a development problem.
We've now reached a stage in web development where things should be easy
to put together (Lego building blocks). I used to hate web development
and Tapestry 3 was the first thing I found which helped me dislike it a
lot less. Tapestry 5 even more so. However, having no good set of
central documentation, how-tos, cookbook solutions, etc makes the
development process that much harder and not like Lego blocks. I really
only want to have to think about business logic and know only the basics
of how Tapestry works. Turning to the source code should be a last
resort and I've had to do that once so far with Tapestry 5 because the
documentation I required was inadequate (can't remember what it was now,
but it wasn't even anything exotic I was trying to do!)
That said, I think this mailing list is fantastic and has certainly
ridden to my rescue on numerous occasions. The only off-putting thing is
the fear of asking the "dumb question". Sure, no questions are dumb, but
I always feel a lot better if I know I've made an effort to find out how
to do something before asking on here. Again, lack of good docs makes
that effort so much harder and also increases the traffic on here by the
same questions being asked multiple times.
**************************************************************************
Experience the British Library online at www.bl.uk
The British Library's new interactive Annual Report and Accounts 2007/08 : www.bl.uk/knowledge
Help the British Library conserve the world's knowledge. Adopt a Book. www.bl.uk/adoptabook
The Library's St Pancras site is WiFi - enabled
*************************************************************************
The information contained in this e-mail is confidential and may be legally privileged. It is intended for the addressee(s) only. If you are not the intended recipient, please delete this e-mail and notify the postmaster@bl.uk : The contents of this e-mail must not be disclosed or copied without the sender's consent.
The statements and opinions expressed in this message are those of the author and do not necessarily reflect those of the British Library. The British Library does not take any responsibility for the views of the author.
*************************************************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5: What is NOT beautiful about Tapestry?
Posted by Howard Lewis Ship <hl...@gmail.com>.
>
> Now as far as funding documentation is concerned. Yeah, that's the problem
> isn't it. Who pays, who does the work, where does it happen. I have the
> good luck right now, of being like the the consultants in that old
> commercial by UPS professional services. The one where two consultants
> propose a plan for improving upgrading and streamlining a company's business
> process and the CEO says. "Ok, great I love this plan let's do it!". At
> which point the consultants start to laugh... "Dot it? Do it!, We don't DO
> the work, we just tell you what needs to be done." :-)
>
> At some point, I'd be happy to contribute some hours to a task like that,
> but at the present moment, my own chaotic life has my full attention.
>
> Tony
>
The essence of documentation, good documentation, is that it can't be
done in dribs and drabs. It takes time, and focus, and organization.
That's why its tough.
--
Howard M. Lewis Ship
Creator of Apache Tapestry
Director of Open Source Technology at Formos
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5: What is NOT beautiful about Tapestry?
Posted by Tony Giaccone <tg...@gmail.com>.
On Fri, May 1, 2009 at 11:30 AM, Howard Lewis Ship <hl...@gmail.com> wrote:
>
>
> >
> > 4) Stability - you need to lay down a road map that shows management and
> > developers that they can count on a stable environment for the
> foreseeable
> > future. Howard, T6 can't be so different from T5 that you have to
> rewrite
> > apps. Tapestry has a bad reputation and if you want general adoption, you
> > personally have to assure everyone that the days of major changes in the
> > framework have ended.
>
> Now you are citing yourself as a newbie. Anyone who's followed this
> mailing list has seen Tapestry 6 come up and everyone, including
> myself, strike it down. Sure, there's a couple of things that I'd do
> differently now, but not enough to address the kind of effort involved
> in yet another rewrite. Again, 5.1 is a demonstration of the future
> path, where new features can be added non-disruptively.
>
>
>
Well the issue of version numbers is always a case of shifting sands. One
person's point release is another's major version. Certainly Tapestry will
continue to improve, over time. The version numbers will continue to
increase.. and at some point version 5.9.9 will yield. ;-) Or perhaps we'll
stay at 5 for the foreseeable future, in which case, the point change from
5.x to 5.y becomes a major set of feature enhancements. I don't want to
argue that point, I just want to say that I've been doing work with tapestry
since 2005, so I may be a newbie to the list, but I've had to support the
choice of Tapestry in a variety of circumstances. Stability is a concern
when trying to convince an organization to adopt a technology and one that's
not been helped by major changes in architecture. Also one that can only be
addressed by time.
Now as far as funding documentation is concerned. Yeah, that's the problem
isn't it. Who pays, who does the work, where does it happen. I have the
good luck right now, of being like the the consultants in that old
commercial by UPS professional services. The one where two consultants
propose a plan for improving upgrading and streamlining a company's business
process and the CEO says. "Ok, great I love this plan let's do it!". At
which point the consultants start to laugh... "Dot it? Do it!, We don't DO
the work, we just tell you what needs to be done." :-)
At some point, I'd be happy to contribute some hours to a task like that,
but at the present moment, my own chaotic life has my full attention.
Tony
Re: T5: What is NOT beautiful about Tapestry?
Posted by Markus Joschko <ma...@gmail.com>.
The documentation point is often raised and of course it is never
enough documentation and a book like writing that guides carefully
through tapestry would be really great.
However I think that the available documentation is still very, very
good. Most of the things I need to know I find in the regular docs. If
that doesn't help the javadocs are extremely helpful. There aren't
that many open source projects that have such a decent documentation.
I have to confess that I sometimes have to browse a couple of pages
before I find the information. Maybe an integrated search in the site
would help
On Fri, May 1, 2009 at 7:39 PM, Ulrich Stärk <ul...@spielviel.de> wrote:
>> Nobody likes to do documentation. That's a problem in a volunteer
>> effort. If Tapestry's committers reported to me, I'd be parceling out
>> the kind of documentation you're talking about. That's not how it
>> works.
>
> Why don't you create JIRA issues for those documenation tasks? This would
> show that documentation is as important as improvements/bugfixes and
> enhances Tapestrys overall quality. This could also lead to the community
> being able to contribute something to the framework. I for one like to pick
> myself some simple issue like localizing message catalogs or improving
> documentation and contribute and I could imagine that others might do the
> same.
>
> Uli
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5: What is NOT beautiful about Tapestry?
Posted by Ulrich Stärk <ul...@spielviel.de>.
> Nobody likes to do documentation. That's a problem in a volunteer
> effort. If Tapestry's committers reported to me, I'd be parceling out
> the kind of documentation you're talking about. That's not how it
> works.
Why don't you create JIRA issues for those documenation tasks? This would show that documentation is
as important as improvements/bugfixes and enhances Tapestrys overall quality. This could also lead
to the community being able to contribute something to the framework. I for one like to pick myself
some simple issue like localizing message catalogs or improving documentation and contribute and I
could imagine that others might do the same.
Uli
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5: What is NOT beautiful about Tapestry?
Posted by Howard Lewis Ship <hl...@gmail.com>.
On Fri, May 1, 2009 at 8:01 AM, Tony Giaccone <tg...@gmail.com> wrote:
> I'll give my opinion on this, and I think I can speak with some authority as
> I used to work in WebObjects which at the time was by far head and shoulders
> above the rest of the pack of web development frameworks. In fact I would
> say that WebObject still in many ways leads the pack of Frameworks and it's
> pretty much been stagnant for the last 5 years. In addition while I've not
> worked with T5 yet, I have done work in both T3 and T4.
I hope you get a chance to use T5 soon; it's the same "flavor" as T4,
but a whole new recipe ... the differences are more than the sum of
the deltas.
>
> 1) Tapestry has a deserved reputation for being a framework who's foundation
> is on shifting sands. The changes from T3 to T4, and then from T4 to T5
> have been enormous. In the enterprise world, that's a major disadvantage.
> That the code is not backwards compliant, means that for an enterprise to
> stick with T5 it has to either continue on a framework that's become
> stagnant, or worse dead. Or invest a large amount of money re-writing an app
> to support a new architecture.
I'll accept the shifting sands from Tx upto T4. One of the reasons
I'm very interested in getting T5.1 out the door is to demonstrate my
contention that T5's new architecture supports adding significant new
features (i.e., performance boosts, better templates, gzip
compression, javascript aggregation) without breaking backwards
compatibility.
>
> 2) Hivemind - Learning Tapestry for many developers was an uphill battle.
> Understanding Hivemind and how to make use of it, was more like Mt Everest.
> Documentation was miserable, examples sparse. I was able to get the
> Hivemind to spin up services and work with Spring but boy it wasn't easy.
> Hivemind is gone in T5? The IOC container has to be well understood, well
> described, and documented with examples at the same level as Tapestry
> rendering frameworks.
I think the new IoC container is much easier to understand, and
there's no XML. People still stumble over the concept of service
configurations. However, there's a lot more examples now, in the
cookbooks and elsewhere.
>
> 3) Documentation - Good solid reference examples of how to do do simple
> apps, explained in detail. Most developers want a framework to be like lego
> building blocks. I do A, B, C and D and I get E. I assemble a dozen
> different pieces and I have my app. Really how complicated are most web
> apps? They are forms and workflow and validation. To get developers to use
> your framework you need good examples of how to do each, laid out and
> described in simple guaranteed to work steps. There need to be examples of
> these in both Netbeans and Eclipse; preferably several examples of each.
Are you willing to fund this kind of effort? Didn't think so.
Documentation is *hard*. I think Tapestry should get some kudos that
the documentation is at least accurate. There's a wealth of very rich
JavaDoc, the component reference, and lots of hand-tooled reference
documentation.
Nobody likes to do documentation. That's a problem in a volunteer
effort. If Tapestry's committers reported to me, I'd be parceling out
the kind of documentation you're talking about. That's not how it
works.
In a separate thread, I'm promoting the use of a wiki as the basis of
future documentation. I think opening up documentation to the
community is the only way of bridging the gap ... but that brings in
its own problems w.r.t. oversight and accuracy (not to mention
readability and consistency).
>
> 4) Stability - you need to lay down a road map that shows management and
> developers that they can count on a stable environment for the foreseeable
> future. Howard, T6 can't be so different from T5 that you have to rewrite
> apps. Tapestry has a bad reputation and if you want general adoption, you
> personally have to assure everyone that the days of major changes in the
> framework have ended.
Now you are citing yourself as a newbie. Anyone who's followed this
mailing list has seen Tapestry 6 come up and everyone, including
myself, strike it down. Sure, there's a couple of things that I'd do
differently now, but not enough to address the kind of effort involved
in yet another rewrite. Again, 5.1 is a demonstration of the future
path, where new features can be added non-disruptively.
>
> My personal opinion is that those four things are the starting point. They
> may not be enough, but if you can't get them done, you won't get anywhere in
> terms of major commercial adoption. WebObjects had most of those advantages
> and a few others ( an integrated object relational management system that
> blows away Hibernate for example), but it got killed because it wasn't
> "Standards compliant". However, the truth is no one was willing to trust
> Apple, to provide them with a web development framework. They used the
> "Standards compliant" argument to discard what they really didn't want in
> the first place. If they hadn't had that argument, they would have found
> another.
>
> Tapestry has similar problems. The standard arguments I've heard against
> using Tapestry are:
>
> 1) The framework changes too much from release to release.
> 2) The team of developers who commit to the code base is too small.
> 3) It's hard to learn.
> 4) It's not standards compliant.
> 5) We can't find developers to hire who are trained in the use of the
> framework.
>
>
> Perception is probably more important than reality when it comes to what
> frameworks are in vogue. Mindshare is key.
>
> Now on the other hand, WebObjects was often viewed as a competitive
> advantage by our customers. We had a lot of clients who wouldn't let us
> write up success stories because they didn't want their competitors to
> learn what framework they were using. Tapestry has a lot going for it, so
> it's nice to use a framework that is, "stealth".
>
--
Howard M. Lewis Ship
Creator of Apache Tapestry
Director of Open Source Technology at Formos
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5: What is NOT beautiful about Tapestry?
Posted by Tony Giaccone <tg...@gmail.com>.
I'll give my opinion on this, and I think I can speak with some authority as
I used to work in WebObjects which at the time was by far head and shoulders
above the rest of the pack of web development frameworks. In fact I would
say that WebObject still in many ways leads the pack of Frameworks and it's
pretty much been stagnant for the last 5 years. In addition while I've not
worked with T5 yet, I have done work in both T3 and T4.
1) Tapestry has a deserved reputation for being a framework who's foundation
is on shifting sands. The changes from T3 to T4, and then from T4 to T5
have been enormous. In the enterprise world, that's a major disadvantage.
That the code is not backwards compliant, means that for an enterprise to
stick with T5 it has to either continue on a framework that's become
stagnant, or worse dead. Or invest a large amount of money re-writing an app
to support a new architecture.
2) Hivemind - Learning Tapestry for many developers was an uphill battle.
Understanding Hivemind and how to make use of it, was more like Mt Everest.
Documentation was miserable, examples sparse. I was able to get the
Hivemind to spin up services and work with Spring but boy it wasn't easy.
Hivemind is gone in T5? The IOC container has to be well understood, well
described, and documented with examples at the same level as Tapestry
rendering frameworks.
3) Documentation - Good solid reference examples of how to do do simple
apps, explained in detail. Most developers want a framework to be like lego
building blocks. I do A, B, C and D and I get E. I assemble a dozen
different pieces and I have my app. Really how complicated are most web
apps? They are forms and workflow and validation. To get developers to use
your framework you need good examples of how to do each, laid out and
described in simple guaranteed to work steps. There need to be examples of
these in both Netbeans and Eclipse; preferably several examples of each.
4) Stability - you need to lay down a road map that shows management and
developers that they can count on a stable environment for the foreseeable
future. Howard, T6 can't be so different from T5 that you have to rewrite
apps. Tapestry has a bad reputation and if you want general adoption, you
personally have to assure everyone that the days of major changes in the
framework have ended.
My personal opinion is that those four things are the starting point. They
may not be enough, but if you can't get them done, you won't get anywhere in
terms of major commercial adoption. WebObjects had most of those advantages
and a few others ( an integrated object relational management system that
blows away Hibernate for example), but it got killed because it wasn't
"Standards compliant". However, the truth is no one was willing to trust
Apple, to provide them with a web development framework. They used the
"Standards compliant" argument to discard what they really didn't want in
the first place. If they hadn't had that argument, they would have found
another.
Tapestry has similar problems. The standard arguments I've heard against
using Tapestry are:
1) The framework changes too much from release to release.
2) The team of developers who commit to the code base is too small.
3) It's hard to learn.
4) It's not standards compliant.
5) We can't find developers to hire who are trained in the use of the
framework.
Perception is probably more important than reality when it comes to what
frameworks are in vogue. Mindshare is key.
Now on the other hand, WebObjects was often viewed as a competitive
advantage by our customers. We had a lot of clients who wouldn't let us
write up success stories because they didn't want their competitors to
learn what framework they were using. Tapestry has a lot going for it, so
it's nice to use a framework that is, "stealth".
Tony Giaccone
On Fri, May 1, 2009 at 3:07 AM, Inge Solvoll <in...@gmail.com>wrote:
> To possibly bring the discussion to a higher level:
>
> Why is T5 so far from being the DE FACTO STANDARD web framework?
>
> Is getting web developers to use T5 comparable to encouraging 80-year-olds
> to throw away their radio and use MP3 instead?
>
> The two actually seem related:
> - There's a learning curve (probably more intimidating seen from a
> distance)
> - There exists a strong standard that feels comfortable, familiar and
> somewhat sufficient
> - The supporters of the alternative are not your age, not your kind of
> people, and they don't hang where you hang.
>
> So who are we? Are we the new cool teenagers drawing the shape of the
> future, or are we the crazy religious people committing suicide together to
> try to get to the sacred planet?
>
> Inge
>
> On Fri, May 1, 2009 at 8:16 AM, Otho <ta...@googlemail.com> wrote:
>
> > alex,
> > sorry you are right. I was blown away on points 2 & 4.
> >
> >
> > 2009/5/1 kranga <kr...@k2d2.org>
> >
> > > For Tap 3, we had a very elaborate form with loop implementation and we
> > > added Ajax-validation such that you only write validation code once in
> > Java
> > > and for javascript validation, an ajax call is made to run the same
> > > validation code and bring back the results. The error handling could
> > > correctly handle n-input fields in a form all generated via a loop.
> > Needless
> > > to say the code was quite complex and horrendously convoluted and now
> is
> > > outdated :( haha
> > >
> > > --------------------------------------------------
> > > From: "Inge Solvoll" <in...@gmail.com>
> > > Sent: Thursday, April 30, 2009 6:09 PM
> > >
> > > To: "Tapestry users" <us...@tapestry.apache.org>
> > > Subject: Re: T5: What is NOT beautiful about Tapestry?
> > >
> > > Agree with Alex on the last comment about proving that issues don't
> > exist!
> > >>
> > >> I have one example of a trivial thing that I have found difficult to
> > >> implement in all Tapestry versions I have used(3, 4, 5):
> > >>
> > >> - A form with a loop in it.
> > >>
> > >> This is extremely common in the pages I make, and my mind always
> > struggles
> > >> when trying to find how this is done in the new Tapestry version. I
> > never
> > >> figured out a way to do it in 3 and 4 that made sense to me and looked
> > >> correct.
> > >>
> > >> It also happened in T5. Maybe I'm stupid, but I really had to struggle
> > >> hard
> > >> to track down the details needed to implement this correctly, using
> > >> encoders, initializing my form objects in the correct method in the
> > >> correct
> > >> way, and so on. I didn't find an example in the docs showing me the
> best
> > >> practice for this (for me) very trivial and very common pattern.
> > >>
> > >>
> > >> On Thu, Apr 30, 2009 at 11:17 PM, Alex Kotchnev <ak...@gmail.com>
> > >> wrote:
> > >>
> > >> 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 <kr...@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" <pr...@gmail.com>
> > >>> > Sent: Thursday, April 30, 2009 5:43 AM
> > >>> > To: "Tapestry users" <us...@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 <hu...@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
> > >>> >>> <An...@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.crowder@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-unsubscribe@tapestry.apache.org
> > >>> >>> >> For additional commands, e-mail:
> users-help@tapestry.apache.org
> > >>> >>> >>
> > >>> >>> >
> > >>> >>> >
> > >>> >>> >
> > >>> >>> >
> > >>> ---------------------------------------------------------------------
> > >>> >>> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > >>> >>> > For additional commands, e-mail:
> users-help@tapestry.apache.org
> > >>> >>> >
> > >>> >>> >
> > >>> >>>
> > >>> >>>
> > ---------------------------------------------------------------------
> > >>> >>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > >>> >>> For additional commands, e-mail: users-help@tapestry.apache.org
> > >>> >>>
> > >>> >>>
> > >>> >>
> > >>> >>
> > >>> >> --
> > >>> >> Cumprimentos...
> > >>> >> Pedro Januário
> > >>> >>
> > >>> >
> > >>> >
> ---------------------------------------------------------------------
> > >>> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > >>> > For additional commands, e-mail: users-help@tapestry.apache.org
> > >>> >
> > >>> >
> > >>>
> > >>> ---------------------------------------------------------------------
> > >>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > >>> For additional commands, e-mail: users-help@tapestry.apache.org
> > >>>
> > >>>
> > >>>
> > >>
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > > For additional commands, e-mail: users-help@tapestry.apache.org
> > >
> > >
> >
>
Re: T5: What is NOT beautiful about Tapestry?
Posted by Inge Solvoll <in...@gmail.com>.
To possibly bring the discussion to a higher level:
Why is T5 so far from being the DE FACTO STANDARD web framework?
Is getting web developers to use T5 comparable to encouraging 80-year-olds
to throw away their radio and use MP3 instead?
The two actually seem related:
- There's a learning curve (probably more intimidating seen from a distance)
- There exists a strong standard that feels comfortable, familiar and
somewhat sufficient
- The supporters of the alternative are not your age, not your kind of
people, and they don't hang where you hang.
So who are we? Are we the new cool teenagers drawing the shape of the
future, or are we the crazy religious people committing suicide together to
try to get to the sacred planet?
Inge
On Fri, May 1, 2009 at 8:16 AM, Otho <ta...@googlemail.com> wrote:
> alex,
> sorry you are right. I was blown away on points 2 & 4.
>
>
> 2009/5/1 kranga <kr...@k2d2.org>
>
> > For Tap 3, we had a very elaborate form with loop implementation and we
> > added Ajax-validation such that you only write validation code once in
> Java
> > and for javascript validation, an ajax call is made to run the same
> > validation code and bring back the results. The error handling could
> > correctly handle n-input fields in a form all generated via a loop.
> Needless
> > to say the code was quite complex and horrendously convoluted and now is
> > outdated :( haha
> >
> > --------------------------------------------------
> > From: "Inge Solvoll" <in...@gmail.com>
> > Sent: Thursday, April 30, 2009 6:09 PM
> >
> > To: "Tapestry users" <us...@tapestry.apache.org>
> > Subject: Re: T5: What is NOT beautiful about Tapestry?
> >
> > Agree with Alex on the last comment about proving that issues don't
> exist!
> >>
> >> I have one example of a trivial thing that I have found difficult to
> >> implement in all Tapestry versions I have used(3, 4, 5):
> >>
> >> - A form with a loop in it.
> >>
> >> This is extremely common in the pages I make, and my mind always
> struggles
> >> when trying to find how this is done in the new Tapestry version. I
> never
> >> figured out a way to do it in 3 and 4 that made sense to me and looked
> >> correct.
> >>
> >> It also happened in T5. Maybe I'm stupid, but I really had to struggle
> >> hard
> >> to track down the details needed to implement this correctly, using
> >> encoders, initializing my form objects in the correct method in the
> >> correct
> >> way, and so on. I didn't find an example in the docs showing me the best
> >> practice for this (for me) very trivial and very common pattern.
> >>
> >>
> >> On Thu, Apr 30, 2009 at 11:17 PM, Alex Kotchnev <ak...@gmail.com>
> >> wrote:
> >>
> >> 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 <kr...@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" <pr...@gmail.com>
> >>> > Sent: Thursday, April 30, 2009 5:43 AM
> >>> > To: "Tapestry users" <us...@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 <hu...@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
> >>> >>> <An...@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.crowder@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-unsubscribe@tapestry.apache.org
> >>> >>> >> For additional commands, e-mail: users-help@tapestry.apache.org
> >>> >>> >>
> >>> >>> >
> >>> >>> >
> >>> >>> >
> >>> >>> >
> >>> ---------------------------------------------------------------------
> >>> >>> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> >>> >>> > For additional commands, e-mail: users-help@tapestry.apache.org
> >>> >>> >
> >>> >>> >
> >>> >>>
> >>> >>>
> ---------------------------------------------------------------------
> >>> >>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> >>> >>> For additional commands, e-mail: users-help@tapestry.apache.org
> >>> >>>
> >>> >>>
> >>> >>
> >>> >>
> >>> >> --
> >>> >> Cumprimentos...
> >>> >> Pedro Januário
> >>> >>
> >>> >
> >>> > ---------------------------------------------------------------------
> >>> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> >>> > For additional commands, e-mail: users-help@tapestry.apache.org
> >>> >
> >>> >
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> >>> For additional commands, e-mail: users-help@tapestry.apache.org
> >>>
> >>>
> >>>
> >>
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: users-help@tapestry.apache.org
> >
> >
>
Re: T5: What is NOT beautiful about Tapestry?
Posted by Otho <ta...@googlemail.com>.
alex,
sorry you are right. I was blown away on points 2 & 4.
2009/5/1 kranga <kr...@k2d2.org>
> For Tap 3, we had a very elaborate form with loop implementation and we
> added Ajax-validation such that you only write validation code once in Java
> and for javascript validation, an ajax call is made to run the same
> validation code and bring back the results. The error handling could
> correctly handle n-input fields in a form all generated via a loop. Needless
> to say the code was quite complex and horrendously convoluted and now is
> outdated :( haha
>
> --------------------------------------------------
> From: "Inge Solvoll" <in...@gmail.com>
> Sent: Thursday, April 30, 2009 6:09 PM
>
> To: "Tapestry users" <us...@tapestry.apache.org>
> Subject: Re: T5: What is NOT beautiful about Tapestry?
>
> Agree with Alex on the last comment about proving that issues don't exist!
>>
>> I have one example of a trivial thing that I have found difficult to
>> implement in all Tapestry versions I have used(3, 4, 5):
>>
>> - A form with a loop in it.
>>
>> This is extremely common in the pages I make, and my mind always struggles
>> when trying to find how this is done in the new Tapestry version. I never
>> figured out a way to do it in 3 and 4 that made sense to me and looked
>> correct.
>>
>> It also happened in T5. Maybe I'm stupid, but I really had to struggle
>> hard
>> to track down the details needed to implement this correctly, using
>> encoders, initializing my form objects in the correct method in the
>> correct
>> way, and so on. I didn't find an example in the docs showing me the best
>> practice for this (for me) very trivial and very common pattern.
>>
>>
>> On Thu, Apr 30, 2009 at 11:17 PM, Alex Kotchnev <ak...@gmail.com>
>> wrote:
>>
>> 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 <kr...@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" <pr...@gmail.com>
>>> > Sent: Thursday, April 30, 2009 5:43 AM
>>> > To: "Tapestry users" <us...@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 <hu...@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
>>> >>> <An...@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.crowder@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-unsubscribe@tapestry.apache.org
>>> >>> >> For additional commands, e-mail: users-help@tapestry.apache.org
>>> >>> >>
>>> >>> >
>>> >>> >
>>> >>> >
>>> >>> >
>>> ---------------------------------------------------------------------
>>> >>> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>> >>> > For additional commands, e-mail: users-help@tapestry.apache.org
>>> >>> >
>>> >>> >
>>> >>>
>>> >>> ---------------------------------------------------------------------
>>> >>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>> >>> For additional commands, e-mail: users-help@tapestry.apache.org
>>> >>>
>>> >>>
>>> >>
>>> >>
>>> >> --
>>> >> Cumprimentos...
>>> >> Pedro Januário
>>> >>
>>> >
>>> > ---------------------------------------------------------------------
>>> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>> > For additional commands, e-mail: users-help@tapestry.apache.org
>>> >
>>> >
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>
>>>
>>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
Re: T5: What is NOT beautiful about Tapestry?
Posted by kranga <kr...@k2d2.org>.
For Tap 3, we had a very elaborate form with loop implementation and we
added Ajax-validation such that you only write validation code once in Java
and for javascript validation, an ajax call is made to run the same
validation code and bring back the results. The error handling could
correctly handle n-input fields in a form all generated via a loop. Needless
to say the code was quite complex and horrendously convoluted and now is
outdated :( haha
--------------------------------------------------
From: "Inge Solvoll" <in...@gmail.com>
Sent: Thursday, April 30, 2009 6:09 PM
To: "Tapestry users" <us...@tapestry.apache.org>
Subject: Re: T5: What is NOT beautiful about Tapestry?
> Agree with Alex on the last comment about proving that issues don't exist!
>
> I have one example of a trivial thing that I have found difficult to
> implement in all Tapestry versions I have used(3, 4, 5):
>
> - A form with a loop in it.
>
> This is extremely common in the pages I make, and my mind always struggles
> when trying to find how this is done in the new Tapestry version. I never
> figured out a way to do it in 3 and 4 that made sense to me and looked
> correct.
>
> It also happened in T5. Maybe I'm stupid, but I really had to struggle
> hard
> to track down the details needed to implement this correctly, using
> encoders, initializing my form objects in the correct method in the
> correct
> way, and so on. I didn't find an example in the docs showing me the best
> practice for this (for me) very trivial and very common pattern.
>
>
> On Thu, Apr 30, 2009 at 11:17 PM, Alex Kotchnev <ak...@gmail.com>
> wrote:
>
>> 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 <kr...@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" <pr...@gmail.com>
>> > Sent: Thursday, April 30, 2009 5:43 AM
>> > To: "Tapestry users" <us...@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 <hu...@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
>> >>> <An...@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.crowder@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-unsubscribe@tapestry.apache.org
>> >>> >> For additional commands, e-mail: users-help@tapestry.apache.org
>> >>> >>
>> >>> >
>> >>> >
>> >>> >
>> >>> > ---------------------------------------------------------------------
>> >>> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> >>> > For additional commands, e-mail: users-help@tapestry.apache.org
>> >>> >
>> >>> >
>> >>>
>> >>> ---------------------------------------------------------------------
>> >>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> >>> For additional commands, e-mail: users-help@tapestry.apache.org
>> >>>
>> >>>
>> >>
>> >>
>> >> --
>> >> Cumprimentos...
>> >> Pedro Januário
>> >>
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> > For additional commands, e-mail: users-help@tapestry.apache.org
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org