--
If you are not an intended recipient of this e-mail, please notify the sender,
delete it and do not read, act upon, print, disclose, copy, retain or
redistribute it. Please visit http://www.albourne.com/email.html for important
additional terms relating to this e-mail.
> I've also thought about this, and my only conclusion is that Tapestry is too
> difficult to master. Especially when it comes to tapestry-ioc and
> getting productive
> with it.
Only because of the lack of good docs and tutorials... its a pity though
because it may appear daunting to begin with, but when you do learn it, it is
so simple its sick.
regards,
Peter
----- Original Message -----
From: "Piero Sartini" <li...@pierosartini.de>
To: "Tapestry users" <users@tapestry.apache.org>
Sent: Wednesday, 23 December, 2009 12:28:35 GMT +02:00 Athens, Beirut,
Bucharest, Istanbul
Subject: Re: Discussion
> Having seen some discussions in the past about the history of Tapestry, I'm
> wondering what the status of Tapestry with CDI support will be. In other
> words, is it again going to result a new major release incompatible with
> previous versions? I think CDI in it's current form, if should be supported,
> would require some fundamental changes to the core of Tapestry's IoC that
> would definitely result in API break. At least the Spring guys also say so
> about their framework.
I am not sure if it is possible or not to integrate CDI without
breaking backwards
compatibility... but it is something we should find out. Spring guys
are no reliable
source, they want to sell their product and if I were them, I would
fear CDI as well.
> I have an idea, may be a controversial one. I've seen much about Tapestry
> and think it's a nice Framework. But what I still don't understand is why
> it's not widely in use. It existed before Wicket but Wicket is far more
> popular. I don't think it's only because it's users are very vocal. There is
> also a saying that a good product sometimes sells itself.
I've also thought about this, and my only conclusion is that Tapestry is too
difficult to master. Especially when it comes to tapestry-ioc and
getting productive
with it.
I am not talking about building the frontend and components.. this is
easy and IMHO
the thing where tapestry really shines.
But there are way too less integrations - see my tapestry-jpa experiment for an
example. It works, but it would need some love from some smarter people than me
to get proper unit tests and some missing parts.
If I look at Wicket or other frameworks there are lots and lots of
integration modules
for just everything. Why is that? My answer is because it is way
easier to write them.
> My proposition is why not let Tapestry and Wicket join hands, migrate some
> of the nice ideas to Wicket and lets try to go standardize Wicket as a JSR.
I am not sure I would like this. I've tried wicket in the past, and
for me it is too verbose.
I don't like the "Swing"-Approach and these inner classes everywhere.
Tapestry's approach
to the front-end programming is excellent, I don't want to trade this.
But I would be perfectly fine trading the IoC container...
Piero
---------------------------------------------------------------------
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
