alex, sorry you are right. I was blown away on points 2 & 4.
2009/5/1 kranga <kra...@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" <inge.tapes...@gmail.com> > Sent: Thursday, April 30, 2009 6:09 PM > > To: "Tapestry users" <users@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 <akoch...@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 <kra...@k2d2.org> wrote: >>> > 1) Documentation: It is one thing to remove dependencies on framework >>> > interfaces but quite another to leave the developer hanging with no >>> > documentation. Programming by convention is programming in the dark if >>> the >>> > convention is not known. >>> > 2) Although Tapestry claims to be POJO, you still have to have a > >>> contract >>> > (whether it is methods by convention or annotated methods). In the long >>> run >>> > whether this is really better than interface implementation is not > >>> fully >>> > proven (much like the current debate of whether dynamically typed >>> languages >>> > will prove more difficult to maintain in the long run). >>> > 3) Lack of a component marketplace: Wow, 4 years on and this is still > >>> on >>> my >>> > list. We wrote a gigantic application in Tapestry 3 which is still in >>> > production. But we've decided to write all new apps in JSF with the aim >>> of >>> > quickly adopting 2.0 when the spec is released. The main reason - a >>> plethora >>> > of components to choose from. >>> > 4) Developer mindshare: Our analysis with Tapestry 3 shows that for > >>> every >>> > developer we hire, we have to write off 2-4 weeks until they become > >>> well >>> > versed in Tapestry. I don't believe T5 will be any different. You > >>> cannot >>> > argue against a standard like JSF that is supported by vendors. The > >>> lack >>> of >>> > penetration of JSF speaks to its terrible initial design which > >>> hopefully >>> > will be rectified in 2.0 >>> > >>> > I don't believe Tapestry will dwindle and die but I don't see it > >>> becoming >>> > the defacto standard ala Struts in the early 2000s. >>> > >>> > -------------------------------------------------- >>> > From: "Pedro Januário" <prnjanua...@gmail.com> >>> > Sent: Thursday, April 30, 2009 5:43 AM >>> > To: "Tapestry users" <users@tapestry.apache.org> >>> > Subject: Re: T5: What is NOT beautiful about Tapestry? >>> > >>> >> I totally agree with Hugo's ideia. >>> >> The wiki sounds good and should be a easy to make documentation about >>> >> common >>> >> problems. >>> >> >>> >> 2009/4/30 Hugo Palma <hugo.m.pa...@gmail.com> >>> >> >>> >>> I agree a book would be great, what happened to the tapestry5-book >>> >>> project http://code.google.com/p/tapestry5-book/ ? >>> >>> >>> >>> Still, i think a lot better could be done with the online >>> documentation. >>> >>> I believe the structure of the online documentation should be very >>> >>> similar to a book, it should start with the basics and evolve to more >>> >>> "hardcore" stuff from there. Just the fact that the current >>> >>> documentation is structured with only one level of depth and the list >>> >>> of item is ordered alphabetically makes the task of finding some >>> >>> information much more difficult. >>> >>> >>> >>> I for example really like how the hibernate documentation is >>> >>> structure, i usually have to problem finding what i'm looking for >>> >>> there. >>> >>> So, maybe the wiki could be a starting place for the birth of a >>> >>> documentation with such a structure. >>> >>> >>> >>> On Thu, Apr 30, 2009 at 10:06 AM, Blower, Andy >>> >>> <andy.blo...@proquest.co.uk> wrote: >>> >>> > I think you hit the nail on the head Carl. The documentation is >>> >>> > okay >>> >>> generally (some bits poor, some very good) but there is not enough to >>> tie >>> >>> it >>> >>> all together and guide new developers so they know what they can do >>> with >>> >>> T5. >>> >>> I'm not convinced that the main documentation should attempt this on >>> its >>> >>> own, or whether it should strive to be a great reference with some >>> >>> more >>> >>> higher level introductory/discovery bits along with a good published >>> book >>> >>> to >>> >>> handle introducing everything and tying it together. Having the only >>> >>> published book for T5 being so out of date is a huge problem for the >>> >>> framework in my opinion. >>> >>> > >>> >>> > I don't think a wiki is the answer to this, I really like knowing >>> that >>> >>> the documentation that I'm looking at is for a specific version of >>> >>> Tapestry >>> >>> and is updated when the code is - I would not want to lose that. >>> >>> > >>> >>> > Andy. >>> >>> > >>> >>> >> -----Original Message----- >>> >>> >> From: Carl Crowder [mailto:carl.crow...@taptu.com] >>> >>> >> Sent: 29 April 2009 22:04 >>> >>> >> To: Tapestry users >>> >>> >> Subject: Re: T5: What is NOT beautiful about Tapestry? >>> >>> >> >>> >>> >> Discovery of it's parts. Franky the documentation is lacking and >>> even >>> >>> >> with reading the mailing list, reading the howtos wiki, buying the >>> >>> >> Tapestry 5 book and working with it for over a year I still come >>> >>> >> >> >>> >>> >> across >>> >>> >> things I never knew existed that would have solved a problem I've >>> had. >>> >>> >> I >>> >>> >> often spend ages writing something myself after searching for a >>> >>> >> solution. >>> >>> >> >>> >>> >> What's beautiful about Tapestry? That almost every problem has a >>> >>> >> >> >>> >>> >> simple >>> >>> >> solution built in. What's not beautiful about Tapestry? That I >>> >>> >> generally >>> >>> >> find these solutions by accident, and way after I've written my >>> >>> >> own! >>> >>> >> >>> >>> >> Lots of things are obvious and easy to understand once you know >>> >>> >> what >>> >>> >> they are but it's learning what they are that is the problem. I've >>> >> >>> >>> >> been >>> >>> >> waxing lyrical about Tapestry where I work and while the >>> >> >>> developers >>> >> >>> >>> >> who >>> >>> >> tried it love it, their main gripe is always that it's difficult >>> >>> >> to >>> >>> >> understand what it can do. >>> >>> >> >>> >>> >> The cookbook is the right idea but it's only got 5 entries right >>> now. >>> >>> >> It >>> >>> >> needs to be way more comprehensive >>> >>> >> >>> >>> >> Inge Solvoll wrote: >>> >>> >> > Hi! >>> >>> >> > >>> >>> >> > I have been reading the "beautiful" thread and added my opinion >>> >>> >> > >> >>> > >>> >>> >> > about >>> >>> >> what's >>> >>> >> > great about Tapestry. It's nice to sum up why we all are so >>> excited >>> >>> >> about >>> >>> >> > this, it obviously makes both us and the creator(s) feel good >>> about >>> >>> >> > ourselves. But for a little while, I challenge us all to stop >> >>> >>> >> > > >>> >>> >> > tapping >>> >>> >> each >>> >>> >> > others' backs and go into depth about what's not to like about >>> >>> >> > our >>> >>> >> beloved >>> >>> >> > framework. >>> >>> >> > >>> >>> >> > The most obvious questions that could be asked probably have >>> >>> >> > some >>> >>> >> very >>> >>> >> > obvious answers. But T5, as I see it, is all about addressing >>> stuff >>> >>> >> that >>> >>> >> > other frameworks have given up on and create excellent >>> >>> >> implementations >>> >>> >> > rather than just looking the other way. Difficult and >>> uncomfortable >>> >>> >> > questions should be addressed the same way. >>> >>> >> > >>> >>> >> > So: >>> >>> >> > >>> >>> >> > What are the main reasons that T5 isn't one of the "big ones", >>> when >>> >>> >> we all >>> >>> >> > seem to agree that it is so much better than most other >>> >> > >>> frameworks >>> >>> >> out >>> >>> >> > there? Why is T5 NOT beautiful? >>> >>> >> > >>> >>> >> > Hope I'm not insulting anyone, I'm a big fan too, I just think >>> this >>> >>> >> actually >>> >>> >> > could lead to significant insight :) >>> >>> >> > >>> >>> >> > Regards >>> >>> >> > >>> >>> >> > Inge >>> >>> >> > >>> >>> >> >>> >>> >> >>> --------------------------------------------------------------------- >>> >>> >> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >>> >>> >> For additional commands, e-mail: users-h...@tapestry.apache.org >>> >>> >> >>> >>> > >>> >>> > >>> >>> > >>> >>> > >>> --------------------------------------------------------------------- >>> >>> > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >>> >>> > For additional commands, e-mail: users-h...@tapestry.apache.org >>> >>> > >>> >>> > >>> >>> >>> >>> --------------------------------------------------------------------- >>> >>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >>> >>> For additional commands, e-mail: users-h...@tapestry.apache.org >>> >>> >>> >>> >>> >> >>> >> >>> >> -- >>> >> Cumprimentos... >>> >> Pedro Januário >>> >> >>> > >>> > --------------------------------------------------------------------- >>> > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >>> > For additional commands, e-mail: users-h...@tapestry.apache.org >>> > >>> > >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >>> For additional commands, e-mail: users-h...@tapestry.apache.org >>> >>> >>> >> > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > >
