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/04/29 22:19:24 UTC
T5: What is NOT beautiful about Tapestry?
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
Re: T5: What is NOT beautiful about Tapestry?
Posted by Otho <ta...@googlemail.com>.
Some interesting points here.
2009/4/30 kranga <kr...@k2d2.org>
> 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.
Yes. That is the main time-eater. Finding out how non-trivial things are
supposed to work. But that is a "feature" of most OS project's
documentation:
a) hello world
b) some simplistic blog/calendar/whatever without any relevance to real
world projects
c) bits and pieces all over the net.
And this is already good documentation as far as OS goes...
The main problem here is that non comitters probably cannot help in writing
the docs, since they just don't know enough. The result would not be better
as what is there.
One example of an excellent documentation in OS projects was Stripes
Framework original docs by Tim Fennel. Since I didn't check the project for
a long time I don't know about its current state.
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).
There is no debate. One just has to look at the sources of well known and
big scripted projects and the difficulties they have to maintain them. In
the end there is no difference between the ugly php hacks and the more
recent varieties of languages. If it is easy to program bad, then it will be
done. Especially under time pressure. Statically typed languages make a lot
of the more annoying mistakes hard to do, like typos which are only caught
at runtime or wrong assignments like assigning a char sequence to a variable
which is meant to be int and calculated upon. again only caught at runtime.
Not having to implement an interface makes it easier for tapestry to change
implicit contracts. That is a totally different beast when talking about
interfaces with methods. But if it would be only marker interfaces there is
anyways no difference between a certain package requirement or implementing
an interface, so no reason to change anything.
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.
True. But since components are easy to make in Tapestry the market would
probably be very limited anyways. All the important building parts are
already there and for 95% of cases you get along with not more code than it
would need to adapt to a premade component. JSF components are shiny and
all, but they all require you to adapt to their needs while in Tapestry you
can tailor components for your specific needs with relatively low effort.
That said, some more premades would be nice :)
> 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.
>
Yes, JSF gets all the hype because it is a standard. But reading in Java
magazines makes it clear very fast, that even simple problems have quite
complicated solutions. It is an endless well of articles for the mags and so
the visibility even rises _because_ it is terribly designed. And a standard.
And because it has shiny components with slick buttons.
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
Re: T5: What is NOT beautiful about Tapestry?
Posted by Inge Solvoll <in...@gmail.com>.
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 Alex Kotchnev <ak...@gmail.com>.
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 kranga <kr...@k2d2.org>.
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
Re: T5: What is NOT beautiful about Tapestry?
Posted by Pedro Januário <pr...@gmail.com>.
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
Re: T5: What is NOT beautiful about Tapestry?
Posted by 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
RE: T5: What is NOT beautiful about Tapestry?
Posted by "Blower, Andy" <An...@proquest.co.uk>.
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
Re: T5: What is NOT beautiful about Tapestry?
Posted by Carl Crowder <ca...@taptu.com>.
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
Re: T5: What is NOT beautiful about Tapestry?
Posted by Pedro Januário <pr...@gmail.com>.
Ok, i will try to expose one of my issues.
<t:delegate t:to="activeMode"/>
<t:block id="processFormFields_1">
<----- Other fields---->
<select t:id="subject" t:type="select"
t:model="prop:subjectModel" t:value="prop:subject"
t:mixins="ck/OnEvent" event="change"
onCompleteCallback="updateSubsubjects"/>
<----- Other fields---->
</t:block>
<t:block id="processFormFields_2">
<----- Other fields---->
<select t:id="subject" t:type="select"
t:model="prop:subjectModel" t:value="prop:subject"
t:mixins="ck/OnEvent" event="change"
onCompleteCallback="updateSubsubjects"/>
<----- Other fields---->
</t:block>
The two blocks will never be displayed together, and i need the id of the
component because i need to have component on the server side.
I have solutionated my problem with a uggly solution.
<t:delegate t:to="activeMode"/>
<t:block id="processFormFields_1">
<----- Other fields---->
<t:delegate t:to="subjectBlock"/>
<----- Other fields---->
</t:block>
<t:block id="processFormFields_2">
<----- Other fields---->
<t:delegate t:to="subjectBlock"/>
<----- Other fields---->
</t:block>
<t:block id="subjectBlock">
<select t:id="subject" t:type="select"
t:model="prop:subjectModel" t:value="prop:subject"
t:mixins="ck/OnEvent" event="change"
onCompleteCallback="updateSubsubjects"/>
</t:block>
This was one of the multiple times (and that i remember :D ) that i have
faced this issue.
I have worked with dynamic structure and liked that kind of behaviour but i
know that dynamic structure my have some serious and dificult problems to
solve.
2009/4/30 Christian Edward Gruber <ch...@gmail.com>
> I'm interested about this - can you elaborate what you mean by this? What
> about the structure is too static, and what dynamism are you looking for?
>
> Christian.
>
> On 29-Apr-09, at 19:16 , Pedro Januário wrote:
>
> - The static structure and dynamic behaviour need.
>>
>
> Christian Edward Gruber
> e-mail: christianedwardgruber@gmail.com
> weblog: http://www.geekinasuit.com/
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
Cumprimentos...
Pedro Januário
Re: T5: What is NOT beautiful about Tapestry?
Posted by Christian Edward Gruber <ch...@gmail.com>.
I'm interested about this - can you elaborate what you mean by this?
What about the structure is too static, and what dynamism are you
looking for?
Christian.
On 29-Apr-09, at 19:16 , Pedro Januário wrote:
> - The static structure and dynamic behaviour need.
Christian Edward Gruber
e-mail: christianedwardgruber@gmail.com
weblog: http://www.geekinasuit.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 Pedro Januário <pr...@gmail.com>.
I'm working with tapestry for 6 months and my main problems were:
- The lack of "good" documentation and common problems solutions
documentation;
- The static structure and dynamic behaviour need.
Sometimes it's painfull when you need to have a reference for the component
on the java code, when we want to have two exlusive blocks with the some
field inside.
2009/4/29 manuel aldana <al...@gmx.de>
> Inge Solvoll schrieb:
>
>> 1. What, politically, made it hard to introduce T5 in your organisation?
>> Who
>> resisted, and why?
>>
>>
> I am sure there a two things which could help at promotion for convincing
> decision makers: Real big live sites running under tapestry and a good up to
> date book.
>
> 2. What, technically, made it hard to introduce/teach T5 among your
>> programmer colleagues? (some already mentioned documentation)
>>
> As bigger sites hardly start from scratch, I see the legacy reason as a big
> technical point. Usually big codebases rely on action/command focused
> frameworks (e.g. struts, spring mvc) and it is extremely hard to refactor
> them to page and component based ones. Also I see that frontend people are
> being used to work with JSP, freemarker etc. and are a bit hesitating to
> look at "yet another" templating technology.
>
> I really like tapestry concepts and helps a lot to think in different
> directions even if you don't use it in daily job. About tap-ioc I really
> like to java-code style injection and configuration instead for XML.
>
> - manuel aldana
> aldana@gmx.de
> software-engineering blog: http://www.aldana-online.de
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
Cumprimentos...
Pedro Januário
Re: T5: What is NOT beautiful about Tapestry?
Posted by manuel aldana <al...@gmx.de>.
Inge Solvoll schrieb:
> 1. What, politically, made it hard to introduce T5 in your organisation? Who
> resisted, and why?
>
I am sure there a two things which could help at promotion for
convincing decision makers: Real big live sites running under tapestry
and a good up to date book.
> 2. What, technically, made it hard to introduce/teach T5 among your
> programmer colleagues? (some already mentioned documentation)
As bigger sites hardly start from scratch, I see the legacy reason as a
big technical point. Usually big codebases rely on action/command
focused frameworks (e.g. struts, spring mvc) and it is extremely hard to
refactor them to page and component based ones. Also I see that frontend
people are being used to work with JSP, freemarker etc. and are a bit
hesitating to look at "yet another" templating technology.
I really like tapestry concepts and helps a lot to think in different
directions even if you don't use it in daily job. About tap-ioc I really
like to java-code style injection and configuration instead for XML.
-
manuel aldana
aldana@gmx.de
software-engineering blog: http://www.aldana-online.de
---------------------------------------------------------------------
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>.
Let's say that the "don't get me wrong, I love Tapestry"-part is implicit in
all replies to this thread, so we're all covered :)
Some more questions:
1. What, politically, made it hard to introduce T5 in your organisation? Who
resisted, and why?
2. What, technically, made it hard to introduce/teach T5 among your
programmer colleagues? (some already mentioned documentation)
3. Why is JSF more popular than Tapestry? Other than the obvious "standard
from Sun"? Something about documentation again maybe? Ask the Spring guys
about fighting against standards from Sun. They beat EJB... :)
On Thu, Apr 30, 2009 at 12:08 AM, Robert Zeigler <ro...@scazdl.org> wrote:
> So, we've clearly hit on documentation being an issue. ;)
>
> Two other things that I think are problematic for newcomers to tapestry:
>
> * static structure, dynamic behavior.
> I agree with HLS's choice on this, but it does create a barrier for a
> lot of people; the programming model in, eg, Wicket is just easier to wrap
> your head around: how do I dynamically get some different component on the
> page? Instantiate it.... Again, I'm not advocating changing static
> structure, dynamic behavior, but I wonder if there's a way that we can
> "hurdle" the barrier here... I have no ideas on this as yet.
> * Related to above, having pages that exist for no other reason than to
> be "holders" for components that will be dynamically injected seems a bit...
> ugly. Maybe we could have a dedicated "dynamic component holder"? At the
> very least, having a simple annotation such as: @DynamicComponentHolder on
> the page classes, and having tapestry recognize that the page isn't actually
> a page meant to be rendered directly, and take steps accordingly (shut down
> requests for those pages, etc.) might be nice.
>
> * Ajax.
> Zones rock, but otherwise, ajax in tapestry is still... lacking, IMHO.
> I think tapestry could go a /long/ way toward making things easier here.
> For instance, the form injector component: it's useful, but I find it
> painful to use, and, it's really only interesting if you're planning on
> dynamically adding additional form elements (or removing them). But things
> like dynamic updates of bits and pieces of forms are painful... tapestry
> really go out of its way to ensure that the same state available in
> rendering the request, or in a full post, is available during an ajax
> request (I'm thinking particularly of the fact that the Form isn't in the
> environment (unless you use form injector).
>
> Robert
>
>
>
> On Apr 29, 2009, at 4/294:04 PM , Pete Poulos wrote:
>
> I am currently learning tapestry and while I agree with the concept of
>> "Convention over Configuration," as newbie I would really like to see
>> all of the conventions clearly documented in one location. As it is
>> right now I feel that I have to hunt around for them and I am worried
>> that there are conventions that I am not aware of.
>>
>> Also, the documentation seems to dive into the details fairly quickly.
>> It would be nice to see a page which clearly defines the
>> breadth/scope of Tapestry. What components/modules are there? What
>> can they do? Where are they located? How can I learn more about them?
>>
>> I am impressed with what I have seen so far, but it has been hard to
>> figure out how to start and to clearly answer the following question:
>> "What parts of Tapestry should I have under my belt before I can claim
>> that I know Tapestry?"
>>
>> Maybe some of these answers are there already and I have either
>> overlooked them or been unable to find them.
>>
>> Pete
>>
>> ---------------------------------------------------------------------
>> 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 Robert Zeigler <ro...@scazdl.org>.
So, we've clearly hit on documentation being an issue. ;)
Two other things that I think are problematic for newcomers to tapestry:
* static structure, dynamic behavior.
I agree with HLS's choice on this, but it does create a barrier
for a lot of people; the programming model in, eg, Wicket is just
easier to wrap your head around: how do I dynamically get some
different component on the page? Instantiate it.... Again, I'm not
advocating changing static structure, dynamic behavior, but I wonder
if there's a way that we can "hurdle" the barrier here... I have no
ideas on this as yet.
* Related to above, having pages that exist for no other reason
than to be "holders" for components that will be dynamically injected
seems a bit... ugly. Maybe we could have a dedicated "dynamic
component holder"? At the very least, having a simple annotation such
as: @DynamicComponentHolder on the page classes, and having tapestry
recognize that the page isn't actually a page meant to be rendered
directly, and take steps accordingly (shut down requests for those
pages, etc.) might be nice.
* Ajax.
Zones rock, but otherwise, ajax in tapestry is still...
lacking, IMHO. I think tapestry could go a /long/ way toward making
things easier here. For instance, the form injector component: it's
useful, but I find it painful to use, and, it's really only
interesting if you're planning on dynamically adding additional form
elements (or removing them). But things like dynamic updates of bits
and pieces of forms are painful... tapestry really go out of its way
to ensure that the same state available in rendering the request, or
in a full post, is available during an ajax request (I'm thinking
particularly of the fact that the Form isn't in the environment
(unless you use form injector).
Robert
On Apr 29, 2009, at 4/294:04 PM , Pete Poulos wrote:
> I am currently learning tapestry and while I agree with the concept of
> "Convention over Configuration," as newbie I would really like to see
> all of the conventions clearly documented in one location. As it is
> right now I feel that I have to hunt around for them and I am worried
> that there are conventions that I am not aware of.
>
> Also, the documentation seems to dive into the details fairly quickly.
> It would be nice to see a page which clearly defines the
> breadth/scope of Tapestry. What components/modules are there? What
> can they do? Where are they located? How can I learn more about them?
>
> I am impressed with what I have seen so far, but it has been hard to
> figure out how to start and to clearly answer the following question:
> "What parts of Tapestry should I have under my belt before I can claim
> that I know Tapestry?"
>
> Maybe some of these answers are there already and I have either
> overlooked them or been unable to find them.
>
> Pete
>
> ---------------------------------------------------------------------
> 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 Imants Firsts <im...@inbox.lv>.
The problem probably lies with the fact that many of us have learned T5 gradually while it was being developed and that is why most of the things seem easy and natural. It might not be so when you see the T5 for the first time. Don't get me wrong, I think everything is ok with the framework, but some more examples would certainly help.
---------------------------------------------------------------------
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 Pete Poulos <pe...@gmail.com>.
I am currently learning tapestry and while I agree with the concept of
"Convention over Configuration," as newbie I would really like to see
all of the conventions clearly documented in one location. As it is
right now I feel that I have to hunt around for them and I am worried
that there are conventions that I am not aware of.
Also, the documentation seems to dive into the details fairly quickly.
It would be nice to see a page which clearly defines the
breadth/scope of Tapestry. What components/modules are there? What
can they do? Where are they located? How can I learn more about them?
I am impressed with what I have seen so far, but it has been hard to
figure out how to start and to clearly answer the following question:
"What parts of Tapestry should I have under my belt before I can claim
that I know Tapestry?"
Maybe some of these answers are there already and I have either
overlooked them or been unable to find them.
Pete
---------------------------------------------------------------------
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 Daniel Jue <te...@gmail.com>.
I agree, I think this will be a constructive thread.
So things that are not beautiful yet are a lack of tooling, aside from the
helpful Loom plugin. I only use eclipse here, so I'm not sure if there are
plugins for other IDEs.
Sometimes I wish there were more industry type examples out there, since I
often find myself writing something that is overly verbose. I find myself
looking at code on http://www.google.com/codesearch . Maybe a reproduction
of the T4 Showcase app would make a good archetype.
Maven usage used to be a problem for some, but I think most of us have
gotten used to it or have worked around it.
On Wed, Apr 29, 2009 at 4:19 PM, Inge Solvoll <in...@gmail.com>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
>
Re: T5: What is NOT beautiful about Tapestry?
Posted by Hugo Palma <hu...@gmail.com>.
As someone that usually tries to "sell" the idea of using Tapestry to
others the main resistance points have been:
- People love drag&drop and autocompletion :o) . It's a major letdown
when i tell people they won't have any IDE integration with this
framework.
- The backwards compatibility thingy always comes into play. I always
explain that with T5 that shouldn't be a problem but people always
make the "yeah right, that's what you said about T4". I guess this one
will work itself out in time.
As a developer:
- The eternal documentation problem.
- Support for AJAX is still very limited compared to the huge potential here.
- No one works issues out except Howard. At least my experience as an
issue creator is that the only developer to ever pick up on the issues
i created and resolve them is Howard except some 1 or 2 cases. This
obviously leads to longer times in issue resolution. Also, this leads
back to the "one man show" problem tapestry has had although i feel
that it's much better than a few years ago. I guess what i'm trying to
say is that it's about time the other developers have a more active
role on the development of the framework.
On Wed, Apr 29, 2009 at 9:19 PM, Inge Solvoll <in...@gmail.com> 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
Re: T5: What is NOT beautiful about Tapestry?
Posted by "Joost Schouten (mailing lists)" <jo...@jsportal.com>.
The flexibility of T5, in that almost every task it performs is
handled by a different service that can be overwritten has a downfall.
It sometimes takes me a long time to figure out what service handles
what task and how can it be overwritten (the under documentation
argument obviously plays a role here). Some of the reflection can make
debugging harder at times and annotations over POJO's takes some time
to get used to (but maybe that is a java5+ wide argument).
My 2 cents,
Joost
On Thu, Apr 30, 2009 at 8:19 AM, Inge Solvoll <in...@gmail.com> 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