You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Banchi Liko <ba...@gmail.com> on 2009/12/22 15:45:20 UTC
Discussion
Hi guys,
There is a discussion going on here
http://www.theserverside.com/news/thread.tss?thread_id=58858 and seems like
Tapestry ihas already been ruled out as a viable and serious web framework.
Wicket seems to be the favorite. I'm sad Tapestry has lost the battle and
afraid it might die soon. Please go and contribute and let your voice be
heard before Tapestry dies a horrible death.
Banchi
Re: Discussion
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Tue, 22 Dec 2009 19:53:46 -0200, Gerald Bauer <gt...@gmail.com>
escreveu:
> Robert,
>
> You need to be a Tapestry evangelist as well. Remember, Howard wants to
> make money- he wants to strike it rich. Please co-operate to make his
> dream come true. Don't be a free loader, man!
Gerald,
I hope you're being sarcastic. Otherwise, as we say here in Brazil, you've
just missed a good opportunity to remain silent. :)
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, software architect and developer, Ars Machina Tecnologia da
Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Discussion
Posted by Gerald Bauer <gt...@gmail.com>.
Robert,
You need to be a Tapestry evangelist as well. Remember, Howard wants to make
money- he wants to strike it rich. Please co-operate to make his dream come
true. Don't be a free loader, man!
On Tue, Dec 22, 2009 at 10:28 PM, Robert Zeigler <ro...@scazdl.org> wrote:
> I like to think that's because the Tapestry users are using Tapestry to be
> productive, instead of just talking about it making them productive. ;)
> But we could all certainly step our publicity up a bit.
>
> Cheers,
>
> Robert
>
>
> On Dec 22, 2009, at 12/221:21 PM , Howard Lewis Ship wrote:
>
> Exactly ... I have yet to figure out why the Tapestry community as a
>> whole is somewhat passive whereas other communities (such as Wicket
>> and Rails) are extremely vocal. Out in the larger world, the best
>> impression of Tapestry comes not from its creators, but from its
>> users, and the users do not talk enough about Tapestry outside of
>> these mailing lists. More blogging, please!
>>
>> On Tue, Dec 22, 2009 at 10:06 AM, Vangel V. Ajanovski <aj...@ii.edu.mk>
>> wrote:
>>
>>> On 22.12.2009 17:41, Alfonso Quiroga wrote:
>>>
>>>> I agree with Thiago, but I've never used Wicket. I've used tapestry5
>>>> and I really like it. Both frameworks are component-based, maybe some
>>>> day I'll try wicket. But if tap5 works for me... why do I have to
>>>> discuss in server-side? I prefer to share my solutions and workarounds
>>>> in this list, where there are people really interested in T5.
>>>>
>>>> I agree on the discussions.
>>>
>>> I think that (if needed) best promotion of Tapestry would be if everyone
>>> that is actually using it (and liking it) created a post somewhere or
>>> blogged about the reasons for choosing Tapestry and preferable to link
>>> such pages from the central documentation.
>>>
>>> The thing is that people who are new to all this, have to look somewhere
>>> and decide which technology to choose. There are not many comparisons
>>> where Tapestry is mentioned and most of them are not really favourable
>>> and mainly point out that Tapestry is too hard to learn.
>>> ... It is not.
>>>
>>> I was in this position two years ago, I had experience with Oracle Web
>>> PL/SQL and APEX, JSP, JSF, ASP and PHP and I am creating web sites from
>>> 1996 and I had the responsibility to choose something better. Even with
>>> such experience and even I was ready to learn from scratch it was hard
>>> to choose the technology for the next task. I decided to start with
>>> Tapestry bacause it was supposedly the hardest :)...
>>> .... It was not and it solved many problems I had with the others.
>>>
>>>
>>>
>>
>>
>> --
>> Howard M. Lewis Ship
>>
>> Creator of Apache Tapestry
>>
>> The source for Tapestry training, mentoring and support. Contact me to
>> learn how I can get you up and productive in Tapestry fast!
>>
>> (971) 678-5210
>> http://howardlewisship.com
>>
>> ---------------------------------------------------------------------
>> 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: Discussion
Posted by Robert Zeigler <ro...@scazdl.org>.
I like to think that's because the Tapestry users are using Tapestry
to be productive, instead of just talking about it making them
productive. ;) But we could all certainly step our publicity up a bit.
Cheers,
Robert
On Dec 22, 2009, at 12/221:21 PM , Howard Lewis Ship wrote:
> Exactly ... I have yet to figure out why the Tapestry community as a
> whole is somewhat passive whereas other communities (such as Wicket
> and Rails) are extremely vocal. Out in the larger world, the best
> impression of Tapestry comes not from its creators, but from its
> users, and the users do not talk enough about Tapestry outside of
> these mailing lists. More blogging, please!
>
> On Tue, Dec 22, 2009 at 10:06 AM, Vangel V. Ajanovski
> <aj...@ii.edu.mk> wrote:
>> On 22.12.2009 17:41, Alfonso Quiroga wrote:
>>> I agree with Thiago, but I've never used Wicket. I've used tapestry5
>>> and I really like it. Both frameworks are component-based, maybe
>>> some
>>> day I'll try wicket. But if tap5 works for me... why do I have to
>>> discuss in server-side? I prefer to share my solutions and
>>> workarounds
>>> in this list, where there are people really interested in T5.
>>>
>> I agree on the discussions.
>>
>> I think that (if needed) best promotion of Tapestry would be if
>> everyone
>> that is actually using it (and liking it) created a post somewhere or
>> blogged about the reasons for choosing Tapestry and preferable to
>> link
>> such pages from the central documentation.
>>
>> The thing is that people who are new to all this, have to look
>> somewhere
>> and decide which technology to choose. There are not many comparisons
>> where Tapestry is mentioned and most of them are not really
>> favourable
>> and mainly point out that Tapestry is too hard to learn.
>> ... It is not.
>>
>> I was in this position two years ago, I had experience with Oracle
>> Web
>> PL/SQL and APEX, JSP, JSF, ASP and PHP and I am creating web sites
>> from
>> 1996 and I had the responsibility to choose something better. Even
>> with
>> such experience and even I was ready to learn from scratch it was
>> hard
>> to choose the technology for the next task. I decided to start with
>> Tapestry bacause it was supposedly the hardest :)...
>> .... It was not and it solved many problems I had with the others.
>>
>>
>
>
>
> --
> Howard M. Lewis Ship
>
> Creator of Apache Tapestry
>
> The source for Tapestry training, mentoring and support. Contact me to
> learn how I can get you up and productive in Tapestry fast!
>
> (971) 678-5210
> http://howardlewisship.com
>
> ---------------------------------------------------------------------
> 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: Discussion
Posted by Howard Lewis Ship <hl...@gmail.com>.
Exactly ... I have yet to figure out why the Tapestry community as a
whole is somewhat passive whereas other communities (such as Wicket
and Rails) are extremely vocal. Out in the larger world, the best
impression of Tapestry comes not from its creators, but from its
users, and the users do not talk enough about Tapestry outside of
these mailing lists. More blogging, please!
On Tue, Dec 22, 2009 at 10:06 AM, Vangel V. Ajanovski <aj...@ii.edu.mk> wrote:
> On 22.12.2009 17:41, Alfonso Quiroga wrote:
>> I agree with Thiago, but I've never used Wicket. I've used tapestry5
>> and I really like it. Both frameworks are component-based, maybe some
>> day I'll try wicket. But if tap5 works for me... why do I have to
>> discuss in server-side? I prefer to share my solutions and workarounds
>> in this list, where there are people really interested in T5.
>>
> I agree on the discussions.
>
> I think that (if needed) best promotion of Tapestry would be if everyone
> that is actually using it (and liking it) created a post somewhere or
> blogged about the reasons for choosing Tapestry and preferable to link
> such pages from the central documentation.
>
> The thing is that people who are new to all this, have to look somewhere
> and decide which technology to choose. There are not many comparisons
> where Tapestry is mentioned and most of them are not really favourable
> and mainly point out that Tapestry is too hard to learn.
> ... It is not.
>
> I was in this position two years ago, I had experience with Oracle Web
> PL/SQL and APEX, JSP, JSF, ASP and PHP and I am creating web sites from
> 1996 and I had the responsibility to choose something better. Even with
> such experience and even I was ready to learn from scratch it was hard
> to choose the technology for the next task. I decided to start with
> Tapestry bacause it was supposedly the hardest :)...
> .... It was not and it solved many problems I had with the others.
>
>
--
Howard M. Lewis Ship
Creator of Apache Tapestry
The source for Tapestry training, mentoring and support. Contact me to
learn how I can get you up and productive in Tapestry fast!
(971) 678-5210
http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Discussion
Posted by "Vangel V. Ajanovski" <aj...@ii.edu.mk>.
On 22.12.2009 17:41, Alfonso Quiroga wrote:
> I agree with Thiago, but I've never used Wicket. I've used tapestry5
> and I really like it. Both frameworks are component-based, maybe some
> day I'll try wicket. But if tap5 works for me... why do I have to
> discuss in server-side? I prefer to share my solutions and workarounds
> in this list, where there are people really interested in T5.
>
I agree on the discussions.
I think that (if needed) best promotion of Tapestry would be if everyone
that is actually using it (and liking it) created a post somewhere or
blogged about the reasons for choosing Tapestry and preferable to link
such pages from the central documentation.
The thing is that people who are new to all this, have to look somewhere
and decide which technology to choose. There are not many comparisons
where Tapestry is mentioned and most of them are not really favourable
and mainly point out that Tapestry is too hard to learn.
... It is not.
I was in this position two years ago, I had experience with Oracle Web
PL/SQL and APEX, JSP, JSF, ASP and PHP and I am creating web sites from
1996 and I had the responsibility to choose something better. Even with
such experience and even I was ready to learn from scratch it was hard
to choose the technology for the next task. I decided to start with
Tapestry bacause it was supposedly the hardest :)...
.... It was not and it solved many problems I had with the others.
Re: Discussion
Posted by Alfonso Quiroga <al...@gmail.com>.
I agree with Thiago, but I've never used Wicket. I've used tapestry5
and I really like it. Both frameworks are component-based, maybe some
day I'll try wicket. But if tap5 works for me... why do I have to
discuss in server-side? I prefer to share my solutions and workarounds
in this list, where there are people really interested in T5.
Ah! greeting to Thiago from Messi's country, :) :)
On Tue, Dec 22, 2009 at 12:25 PM, Thiago H. de Paula Figueiredo
<th...@gmail.com> wrote:
> Em Tue, 22 Dec 2009 12:45:20 -0200, Banchi Liko <ba...@gmail.com>
> escreveu:
>
>> Hi guys,
>
> Hi!
>
>> There is a discussion going on here
>> http://www.theserverside.com/news/thread.tss?thread_id=58858 and seems
>> like Tapestry ihas already been ruled out as a viable and serious web
>> framework.
>
> TheServerSide comments has too many trolls to have a good, reasonable
> discussion there.
>
>> Wicket seems to be the favorite.
>
> Some people who bother to post there like Wicket. Most people who like
> Tapestry, maybe all of them, don't bother to post there.
>
>> I'm sad Tapestry has lost the battle and afraid it might die soon.
>
> Please source or explain your statements or you'll be treated like a troll
> here.
>
>> Please go and contribute and let your voice be
>> heard before Tapestry dies a horrible death.
>
> No, thank you. Posting there will not change Tapestry's fate. Using it,
> exchanging ideas in the mailing lists and contributing code will (and
> already is).
>
> --
> Thiago H. de Paula Figueiredo
> Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and
> instructor
> Owner, software architect and developer, Ars Machina Tecnologia da
> Informação Ltda.
> http://www.arsmachina.com.br
>
> ---------------------------------------------------------------------
> 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: Discussion
Posted by Howard Lewis Ship <hl...@gmail.com>.
Noe, I've been down this path before, regrettably. The ONLY thing to
do it to ignore the trolls.
On Tue, Dec 22, 2009 at 11:29 PM, Newham, Cameron <ca...@bl.uk> wrote:
> I don't agree with the OP that the ServerSide discussion shows Tapestry "has lost the battle" - two posters state they don't want to see Tapestry mentioned. That's all there is.
>
> However, I can't agree with you Thiago. The old saying is "if you say it enough times then people will believe it is true".
>
> If you are just going to stand by and let "trolls" post bad things about Tapestry unchallenged then they have won the argument - regardless of how bad their argument may be and how incorrect their views may be.
>
> After all, someone pitching up and wanting a framework will read what they've written and believe it. Who is to say these anti-Tapestry people are wrong? Not you - because you won't counter their arguments! :-)
>
> Sure - don't feed the trolls. But all that is necessary is to say something positive; not engage them in an argument.
>
> Merry Xmas everyone.
>
>
> -----Original Message-----
> From: Thiago H. de Paula Figueiredo [mailto:thiagohp@gmail.com]
> Sent: 22 December 2009 15:26
> To: Tapestry users
> Subject: Re: Discussion
>
> Em Tue, 22 Dec 2009 12:45:20 -0200, Banchi Liko <ba...@gmail.com>
> escreveu:
>
>> Hi guys,
>
> Hi!
>
>> There is a discussion going on here
>> http://www.theserverside.com/news/thread.tss?thread_id=58858 and seems
>> like Tapestry ihas already been ruled out as a viable and serious web
>> framework.
>
> TheServerSide comments has too many trolls to have a good, reasonable
> discussion there.
>
>> Wicket seems to be the favorite.
>
> Some people who bother to post there like Wicket. Most people who like
> Tapestry, maybe all of them, don't bother to post there.
>
>> I'm sad Tapestry has lost the battle and afraid it might die soon.
>
> Please source or explain your statements or you'll be treated like a troll
> here.
>
>> Please go and contribute and let your voice be
>> heard before Tapestry dies a horrible death.
>
> No, thank you. Posting there will not change Tapestry's fate. Using it,
> exchanging ideas in the mailing lists and contributing code will (and
> already is).
>
> --
> Thiago H. de Paula Figueiredo
> Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
> and instructor
> Owner, software architect and developer, Ars Machina Tecnologia da
> Informação Ltda.
> http://www.arsmachina.com.br
>
> ---------------------------------------------------------------------
> 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
>
>
--
Howard M. Lewis Ship
Creator of Apache Tapestry
The source for Tapestry training, mentoring and support. Contact me to
learn how I can get you up and productive in Tapestry fast!
(971) 678-5210
http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
RE: Discussion
Posted by "Newham, Cameron" <ca...@bl.uk>.
I don't agree with the OP that the ServerSide discussion shows Tapestry "has lost the battle" - two posters state they don't want to see Tapestry mentioned. That's all there is.
However, I can't agree with you Thiago. The old saying is "if you say it enough times then people will believe it is true".
If you are just going to stand by and let "trolls" post bad things about Tapestry unchallenged then they have won the argument - regardless of how bad their argument may be and how incorrect their views may be.
After all, someone pitching up and wanting a framework will read what they've written and believe it. Who is to say these anti-Tapestry people are wrong? Not you - because you won't counter their arguments! :-)
Sure - don't feed the trolls. But all that is necessary is to say something positive; not engage them in an argument.
Merry Xmas everyone.
-----Original Message-----
From: Thiago H. de Paula Figueiredo [mailto:thiagohp@gmail.com]
Sent: 22 December 2009 15:26
To: Tapestry users
Subject: Re: Discussion
Em Tue, 22 Dec 2009 12:45:20 -0200, Banchi Liko <ba...@gmail.com>
escreveu:
> Hi guys,
Hi!
> There is a discussion going on here
> http://www.theserverside.com/news/thread.tss?thread_id=58858 and seems
> like Tapestry ihas already been ruled out as a viable and serious web
> framework.
TheServerSide comments has too many trolls to have a good, reasonable
discussion there.
> Wicket seems to be the favorite.
Some people who bother to post there like Wicket. Most people who like
Tapestry, maybe all of them, don't bother to post there.
> I'm sad Tapestry has lost the battle and afraid it might die soon.
Please source or explain your statements or you'll be treated like a troll
here.
> Please go and contribute and let your voice be
> heard before Tapestry dies a horrible death.
No, thank you. Posting there will not change Tapestry's fate. Using it,
exchanging ideas in the mailing lists and contributing code will (and
already is).
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, software architect and developer, Ars Machina Tecnologia da
Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
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: Discussion
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Tue, 22 Dec 2009 12:45:20 -0200, Banchi Liko <ba...@gmail.com>
escreveu:
> Hi guys,
Hi!
> There is a discussion going on here
> http://www.theserverside.com/news/thread.tss?thread_id=58858 and seems
> like Tapestry ihas already been ruled out as a viable and serious web
> framework.
TheServerSide comments has too many trolls to have a good, reasonable
discussion there.
> Wicket seems to be the favorite.
Some people who bother to post there like Wicket. Most people who like
Tapestry, maybe all of them, don't bother to post there.
> I'm sad Tapestry has lost the battle and afraid it might die soon.
Please source or explain your statements or you'll be treated like a troll
here.
> Please go and contribute and let your voice be
> heard before Tapestry dies a horrible death.
No, thank you. Posting there will not change Tapestry's fate. Using it,
exchanging ideas in the mailing lists and contributing code will (and
already is).
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, software architect and developer, Ars Machina Tecnologia da
Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Discussion
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Wed, 23 Dec 2009 12:07:21 -0200, Alessandro Bottoni
<al...@gmail.com> escreveu:
> Hence, the relatively scarce fame of Tapestry can be considered a
> problem in itself. If few people know Tapestry and few people write few
> code and support it, then the whole framework became less palatable.
> Maybe, we should do something about it...
You've hit the head of the nail. ;)
> For what regards me, I still hope to be able to write some
> docu/article/marketing stuff in the near future (with the help of the
> members of this list, of course). Let's hope this helps.
It surely helps.
> Well, I'm not sure that the T5 IoC container is completely innocent. It
> is true that T5 IoC is much lighter and much more manageable than the
> Spring's one. It is also true that its mechanism of configuration is
> very elegant.
:)
> Nevertheless, I wonder if its original architecture represents a barrier
> for the programmers used to Spring IoC or other containers.
It will be a barrier for anyone used to another IoC container. The
architecture of IoC containers, AFAIK, is very similar to each other. You
have beans/services, dependency injection, AOP, no much beyond that.
> Maybe it is just a matter of pre-existing skills and programming habits.
I don't know if this is an issue, but it is for almost anything in
software development. That's exactly why I think many people still use
Struts when there are many better alternatives. Inertia.
> Maybe a "compatibility layer" could help (for example: accepting both
> the T5 and the Spring configuration sintax).
This could be added to the Spring integration, except the XML part, that
is awful.
> Or, maybe, it is a subtle matter of compatibility between the T5 IoC
> container and the modules we try to integrate (given that most of them
> were designed to work with other types of IoC containers).
The Spring integration does that. We could also do similar integrations
with EJB3, Weld (for CDI), etc.
> I wonder, for example, if there is some Spring IoC (or other IoC
> container) feature that is missing in the T5 IoC and that can make any
> difference. Could it be a (maybe obscure) missing feature the reason why
> a few programmers find so hard to develop a module integration library?
I don't think so. IoC containers features are similar. Comparing
Spring-Core, Tapestry-IoC and Guice, AFAIK, Spring has no feature that the
others don't have. On the other hand, Spring is way older (1.0 released in
2004!) and they have a company behind it, so they can pay people to work
on it full time.
I still think it's more a matter of someone having the time and need.
> Anyway, these are JM2C.
Thanks for contributing to the discussion. :)
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, software architect and developer, Ars Machina Tecnologia da
Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Discussion
Posted by Alessandro Bottoni <al...@gmail.com>.
Il 23/12/2009 13:45, Thiago H. de Paula Figueiredo ha scritto:
> I think you're looking for the cause in the wrong places. I guess these
> integratiosn weren't written just because, unfortunately, Tapestry is
> not very well-known, so few people use it and write extensions and
> integrations.
Hence, the relatively scarce fame of Tapestry can be considered a
problem in itself. If few people know Tapestry and few people write few
code and support it, then the whole framework became less palatable.
Maybe, we should do something about it...
For what regards me, I still hope to be able to write some
docu/article/marketing stuff in the near future (with the help of the
members of this list, of course). Let's hope this helps.
>> I wonder: is it possible to improve the existing integration mechanism
>> of Tapestry (that is: the existing IoC container)? How?
>
> It would be better to discuss actual integration problems and them
> attack them. If anyone has already had them, please post they here.
>
>> Or should we replace it with a different/new one? Which one?
>
> I don't see any reason at all to replace it. If it has shortcomings,
> let's fix them! :)
Well, I'm not sure that the T5 IoC container is completely innocent. It
is true that T5 IoC is much lighter and much more manageable than the
Spring's one. It is also true that its mechanism of configuration is
very elegant.
Nevertheless, I wonder if its original architecture represents a barrier
for the programmers used to Spring IoC or other containers.
Maybe it is just a matter of pre-existing skills and programming habits.
Maybe a "compatibility layer" could help (for example: accepting both
the T5 and the Spring configuration sintax).
Or, maybe, it is a subtle matter of compatibility between the T5 IoC
container and the modules we try to integrate (given that most of them
were designed to work with other types of IoC containers).
I wonder, for example, if there is some Spring IoC (or other IoC
container) feature that is missing in the T5 IoC and that can make any
difference. Could it be a (maybe obscure) missing feature the reason why
a few programmers find so hard to develop a module integration library?
Anyway, these are JM2C.
--
Alessandro Bottoni
Website: http://www.alessandrobottoni.it/
Hofstadter's Law: It always takes longer than you expect, even when you
take into account Hofstadter's Law.
— Douglas Hofstadter, Gödel, Escher, Bach: An Eternal Golden Braid
Re: Discussion
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Wed, 23 Dec 2009 10:14:53 -0200, Alessandro Bottoni
<al...@gmail.com> escreveu:
> As a newbie, I have to say that learning Tapestry (5) is actually a
> little bit more complicated than what you could expect after having read
> the available "marketing" documentation.
This is a known issue.
> Maybe this (apparently steep)
> learning curve has kept the "masses" of developers/users away from
> Tapestry.
You can use Tapestry almost without using Tapestry-IoC, so I don't thin
> BEWARE: I'm not saying that Wicket /is/ better or more complete than
> Tapestry. I'm just saying that Wicket is /presented/ (or /offered/) to
> the public in a better way.
I think you're probably right.
> I do not know if the IoC container is the real and sole source of the
> scarce appreciation of Tapestry (if even exists such a scarce
> appreciation) but... see below.
I don't think so.
> I'm afraid you are right: /this/ seems to be the main, real weak point
> of Tapestry. I do not know Tapestry well enough to have a solid opinion
> about this topic but it seems to me quite evident that writing an
> integration module is somehow (much?) more difficult than it should be.
I think you're looking for the cause in the wrong places. I guess these
integratiosn weren't written just because, unfortunately, Tapestry is not
very well-known, so few people use it and write extensions and
integrations. Or Tapestry users didn't have the need to write them. The
recentness of Tapestry doesn't help either.
Take a look at the t5-restful-webservices project written by Bill
Holloway:
http://code.google.com/p/t5-restful-webservices/wiki/GettingStarted. It
implements JSR 311: JAX-RS: The JavaTM API for RESTful Web Services for
Tapestry. Take a look at the sources. Just three classes, none of them
large. Spring integration has a small number of lines of code. 11 kb
total. There's integration with Tapestry Spring Security. It isn't hard,
people haven't had the time or need to write them.
> I wonder: is it possible to improve the existing integration mechanism
> of Tapestry (that is: the existing IoC container)? How?
It would be better to discuss actual integration problems and them attack
them. If anyone has already had them, please post they here.
> Or should we replace it with a different/new one? Which one?
I don't see any reason at all to replace it. If it has shortcomings, let's
fix them! :)
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, software architect and developer, Ars Machina Tecnologia da
Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Discussion
Posted by Alessandro Bottoni <al...@gmail.com>.
Il 23/12/2009 11:28, Piero Sartini ha scritto:
>> 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.
As a newbie, I have to say that learning Tapestry (5) is actually a
little bit more complicated than what you could expect after having read
the available "marketing" documentation. Maybe this (apparently steep)
learning curve has kept the "masses" of developers/users away from Tapestry.
Nevertheless, this apparent difficulty is in large part just a matter of
documentation and/or examples. From this point of view, Wicket seems to
be much more appetizing. Just have a look at these pages:
http://wicketstuff.org/wicket13/
http://sourceforge.net/projects/wicket-stuff/files/
It is not surprising that many developers could prefer a framework that
supply them with a lot of working, ready-to-use components and/or a lot
of code examples.
BEWARE: I'm not saying that Wicket /is/ better or more complete than
Tapestry. I'm just saying that Wicket is /presented/ (or /offered/) to
the public in a better way.
I think that it is possible to fill this gap, for example using Tynamo
and AppFuse as examples/codebases. At the end, it is just a matter of
documentation and support.
> I am not talking about building the frontend and components.. this is
> easy and IMHO
> the thing where tapestry really shines.
I agree. Tapestry is much more elegant than many other frameworks from
this point of view. This part of Tapestry should not be under discussion.
I do not know if the IoC container is the real and sole source of the
scarce appreciation of Tapestry (if even exists such a scarce
appreciation) but... see below.
> 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.
I'm afraid you are right: /this/ seems to be the main, real weak point
of Tapestry. I do not know Tapestry well enough to have a solid opinion
about this topic but it seems to me quite evident that writing an
integration module is somehow (much?) more difficult than it should be.
Unfortunately, this can be a heavy limit for Tapestry. A real webapp
very often uses many external modules and the simple fact of not having
a easy way to write and/or integrate them can be a good reason for
abandoning this framework.
I came from the Python world and, as you probably know, a large part of
the success of Python is related to the easyness of integrating existing
C and C++ library with the Python interpreter (using SIP or SWIG). It
seems to me a lesson to learn.
I wonder: is it possible to improve the existing integration mechanism
of Tapestry (that is: the existing IoC container)? How? Or should we
replace it with a different/new one? Which one?
JM2C
--
Alessandro Bottoni
Website: http://www.alessandrobottoni.it/
Who wants to remember that escape-x-alt-control-left shift-b puts you
into super-edit-debug-compile mode?
-- (Discussion in comp.os.linux.misc on the intuitiveness of
commands, especially Emacs.)
Re: Discussion
Posted by Peter Stavrinides <P....@albourne.com>.
--
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" <us...@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-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: Discussion
Posted by "Blower, Andy" <An...@proquest.co.uk>.
I have to agree with most of the points that Piero raises, to understand T5 you just have to delve into the code at present. Not necessarily a bad thing for very advanced / obscure stuff, but it makes it much harder to learn Tapestry because it's so widespread even for simple stuff. Better docs, examples (Jumpstart is priceless BTW) and books should help a lot.
Piero is right, Tapestry 5 *IS* complex. Yes, it allows a lot of stuff to be done easily and quickly (when you know how) and a lot of hard stuff to be done as well - but that doesn't make the framework simple or learning it even remotely simple.
Basically what I'm saying is listen to this guy, he obviously cares about T5 and makes some very good points. (and is willing to spend the time expressing these thoughts)
Andy.
> -----Original Message-----
> From: ps@sartini-its.com [mailto:ps@sartini-its.com] On Behalf Of Piero
> Sartini
> Sent: 23 December 2009 17:42
> To: Tapestry users
> Subject: Re: Discussion
>
> > Select models out of beans could be improved. My Tapestry CRUD
> package has a
> > solution for that.
>
> I know... but your CRUD package is not tapestry.
>
> > You're talking about a snapshot. This behaviour was changed and now
> > everything in the context is allowed.
>
> Hey.. this was no complain, you asked where documentation could be
> improved ;-)
>
> >> In the backend, it gets more complicated: contributing services,
> >> decorating services, overriding services...
> >
> > I don't think they're complicated.
>
> That's your oppinion... my feeling is the opposite. On its own, these
> things are simple - but in context of a complex framework like
> tapestry, its hard to get the "big picture".
>
> >> You should know I've tried ;-) BTW the libraries are spread all over
> >> the web (google code, kenai, github, tap360..).
> >
> > There are links to them in http://tapestry.apache.org/.
>
> The problem is that tapestry.apache.org is static. It can be edited by
> the commiters only. My feeling is that this forces the community to a
> single place: the mailing lists. I am not sure if this is enough to
> build an opensource community around a framework like tapestry.
>
> Of course there is the wiki - but it is "hidden" behind lots of menu
> entries.
>
> > CDI and JPA were released few weeks ago and they were mostly written
> to be
> > used inside an EJB container. Implementing CDI is not a piece of
> cake.
>
> JPA is available since over 3 years. And I disagree: it is not mainly
> written to be used inside an EJB container.
> JPA2 is new.. but maybe you know that there is a half-finnished module
> available.
>
> > All it does is to provide Spring beans as Tapestry services. :)
>
> Not the other way as well(tapestry services as spring beans?) .. ?
>
> > You're changing the output generated by some. Try to do the same in
> another
> > framework. ;) The documentation could mention it, of course.
>
> In other frameworks the output is not that static... and such basic
> things like where to add the error messages is easy to change. Take
> Struts2 for an example: <s:error for="fieldName">Error message for
> Field</s:error>
>
> > There are many ways of modeling and implementing authentication and
> > authorization, so I think it's not a Tapestry responsibility.
>
> I think it is - security is something needed by the majority of
> webapps. Tapestry wants to be my web framework - so why doesn't it
> help me? Using container based authentication is not possible. Its
> hard for newbies to get around this. Not more and not less.
>
> > Besides the proxy issue, you're wrong: it wouldn't be difficult to
> integrate with Tapestry-Hibernate now it would be hard to something
> that would work with other
> > persistence options.
>
> I was not aware of the proxy issue, but I was right that it can't be
> too easy. Anyway, IMHO we should need to think about a more general
> way of handling persistence. ORMs (aka JPA and Hibernate) are just one
> part of the persistence arena..
>
> > I strongly suggest you to not make bold statements about frameworks
> you
> > don't know very well. ;) It makes you sound like an uninformed troll,
> but I
> > know you're not one, as you made some very good points in this
> discussion.
>
> If I sound like an uninformed troll, that is because I did not manage
> to understand everything good enough. One possibility is that I am
> just too dumb, the other one would be that tapestry is quite complex
> (what is my whole point above)... (please resist to answer this
> question ;-)
>
> Piero
>
> ---------------------------------------------------------------------
> 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: Discussion
Posted by Alessandro Bottoni <al...@gmail.com>.
Il 26/12/2009 19:24, Thiago H. de Paula Figueiredo ha scritto:
>> I think that what the newbie (like me) and the end-user/dev are
>> expecting from T5+Tynamo is something like a "Drupal on steroids": a
>> empty CMS (coming from a Maven archetype) that can be easily configured
>
> I beg to differ. A web framework has a very different objective from a
> CMS. You can build a CMS with Tapestry, but T5, AFAIK, never had the
> goal of being one.
Yes, of course. I said T5+Tynamo just to underline this detail. T5 alone
cannot play this role. T5+Tynamo, on the other side, do have to offer
this level of readiness.
Thinking at T5 (alone) as the underlining technology of Tynamo (or of a
general purpose CMS) can make easier to spot what is missing and what is
wrong. After all, what the poor developer will have to build is
something very similar to Tynamo (or to Drupal).
CU
--
Alessandro Bottoni
Website: http://www.alessandrobottoni.it/
"When future stopped to be a promise and started to be a threat?"
-- Street wall graffiti, Bologna, 1999
Re: Discussion
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Thu, 24 Dec 2009 10:31:15 -0200, Alessandro Bottoni
<al...@gmail.com> escreveu:
> Regarding this topics, let me remind the ML people that there are at
> least two projects that tries to supply Tapestry 5 with the remaining
> components needed to build a full-stack framework (or something like
> that): Tynamo (formerly known as "Trails") and AppFuse. T5 can be a
> "simple" framework but Tynamo and AppFuse are much more than this.
I guess you can add the Ars Machina Project there, although the approach
is different (several focused packages vs one single framework) and I
didn't have time to write the documentation yet. I'm already using them in
my projects: If you're adventurous enough, take a look at the sources:
http://ars-machina.svn.sourceforge.net/viewvc/ars-machina/ :) Warning: the
newer code of most projects are in branches, not the trunk.
> I think that what the newbie (like me) and the end-user/dev are
> expecting from T5+Tynamo is something like a "Drupal on steroids": a
> empty CMS (coming from a Maven archetype) that can be easily configured
I beg to differ. A web framework has a very different objective from a
CMS. You can build a CMS with Tapestry, but T5, AFAIK, never had the goal
of being one.
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, software architect and developer, Ars Machina Tecnologia da
Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Discussion
Posted by Alessandro Bottoni <al...@gmail.com>.
Il 23/12/2009 19:48, Thiago H. de Paula Figueiredo ha scritto:
> Em Wed, 23 Dec 2009 16:22:49 -0200, Piero Sartini
>> I don't like it as well - but tapestry should provide an alternative.
>> Maybe the question is if tapestry wants to be a full-stack framework
>> or just deliver some building blocks. For being a full-stack
>> framework, there is not enough functionality available. To just
>> provide building blocks, it dictates too much (javascript library,
>> markup, and so on). Of course this is just my feeling.
>
> I cannot speak for the project, but I think Tapestry tries to be a Web
> framework, not a full stack. At least not yet. ;)
Regarding this topics, let me remind the ML people that there are at
least two projects that tries to supply Tapestry 5 with the remaining
components needed to build a full-stack framework (or something like
that): Tynamo (formerly known as "Trails") and AppFuse. T5 can be a
"simple" framework but Tynamo and AppFuse are much more than this.
Looking at T5 from this perspective, it looks very good.
T5 should/could supply us with just the fundamental blocks and
Tynamo/AppFuse could/should do the rest. Also, it should be much easier
to manage the whole dev process in this way.
I think that what the newbie (like me) and the end-user/dev are
expecting from T5+Tynamo is something like a "Drupal on steroids": a
empty CMS (coming from a Maven archetype) that can be easily configured
(like Drupal) and extended (Drupal is a pain to modify and extend, when
used for big and complex projects). In other words, a empty system than
can be used as a good starting point for a real-world (that is: quite
complex) web application.
Such a Maven archetype should supply all of the basic building blocks of
a real-world application:
- access control (Acegi/Spring security or something like that)
- i18n/i10n and language switching
- persistance (against MySQL, for example)
- user registration
- user administration
- captcha?
- e-mail verification (send/verify)
- etc.
To the end-user should remain the responsability to de/activate every
single feature and to configure them.
Such a system, being based on a well-engineered technology like T5,
would be immensely easier to extend and modify than CMSs like Drupal and
immensely more robust.
As long as I can see, T5 and Tynamo are already evolving together in
this way. It is just a matter of time to have such a Drupal-on-steroids
archetype.
As Piero said, at the moment T5 is probably enforcing some choice that
could/should be left to the end-user/dev (javascript library, markup,
etc.) but, as long as I can see, it should not be very hard to loosen
such requisites in future releases. Dojo and JQuery can already be used
together with T5 (cannot they?) and allowing the dev to use a different
mark-up should be just a matter to accept a different XML namespace (a
superset of the T5's). Am I wrong?
JM2C
--
Alessandro Bottoni
Website: http://www.alessandrobottoni.it/
"Perfection is finally attained not when there is no longer anything to
add but when there is no longer anything to take away."
-- Antoine de Saint-Exup�ry
Re: Discussion
Posted by Piero Sartini <li...@pierosartini.de>.
> Agreed. Don't forget to check the third-party packages in the Tapestry home
> page.
Talking about these..
It would be great to tag them defining what they are about:
* projects using tapestry (like InterLDAP)
* projects providing extensions
* showcase / tutorial projects
Outdated:
* Godcode Components joined effort with tapestry-components.
* t5Components is now chenillekit! (link broken on frontpage).
* loom-t5 is inactive
Piero
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Discussion
Posted by "Vangel V. Ajanovski" <aj...@ii.edu.mk>.
On 23.12.2009 22:37, Thiago H. de Paula Figueiredo wrote:
> Better documentation and examples are a very good idea. :)
> Demo projects would really help. Something like the Guice introduction
> would be nice.
I hope we (our team) will soon agree with the licencing issues of our
own project and open-source the part that is finished.
It might not be the best practice example, but it is a complete code
piece that is in production (60-70 database tables, >100 tapestry pages)
and an example what a dozen of students can do in 3-4 months (studying
other courses, learning tapestry included).
I would welcome others to do so in any matter possible (if it is possible).
The best way to learn is by example.
Re: Discussion
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Wed, 23 Dec 2009 19:19:17 -0200, Alfonso Quiroga
<al...@gmail.com> escreveu:
> Hi! very interesting thread. I use T5 since 1 year aprox, and it's
> true that T-IOC was the first "wall" I had, now I understand it and I
> like it a lot (my system does NOT use spring, all with t-ioc). I don't
> know which is the solution, because there is documentation about
> t-ioc, but maybe more documentation? or maybe a demo-project that uses
> basic t-ioc. I think is easier seeing something working, than reading
> t-ioc documentation and start from scratch.
Better documentation and examples are a very good idea. :)
Demo projects would really help. Something like the Guice introduction
would be nice.
> Another point.. I think it's impossible to use T5 without t-ioc, is
> this right? If it's possible, it would be a good idea uploading
> another demo-project without t-ioc.
It's impossible. T5 uses T-IoC in every way possible. T-IoC was created
for T5 because none of the IoC containers at that time provided everything
T5 needs.
> What else? js.. prototype-based, I know it's possible to have
> prototype+jquery together, but I can see lot of people heading jquery,
> so I have a long-term plan.. make a tapestry.js based on jquery, if I
> do it obviously I'll share it.
There's a plan not to switch from Prototype to jQuery. There's a plan to
have JavaScript stacks, one implemented with Prototype, another with
jQuery. No dates yet.
> But "the solution" for this would be a tapestry.js agnostic, so people
> can "inject" their favourite framework. So, maybe it could be shipped
> with a default prototype injection, but anyone could write a mootols
> injection, jquery injection, etc etc
The plan looks like your description. :) Lot of work to implement it,
though. It would be almost something like a JavaScript framework
abstraction layer.
> Last, it would be good more components (ui components).
Agreed. Don't forget to check the third-party packages in the Tapestry
home page.
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, software architect and developer, Ars Machina Tecnologia da
Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Discussion
Posted by Alfonso Quiroga <al...@gmail.com>.
Hi! very interesting thread. I use T5 since 1 year aprox, and it's
true that T-IOC was the first "wall" I had, now I understand it and I
like it a lot (my system does NOT use spring, all with t-ioc). I don't
know which is the solution, because there is documentation about
t-ioc, but maybe more documentation? or maybe a demo-project that uses
basic t-ioc. I think is easier seeing something working, than reading
t-ioc documentation and start from scratch.
Another point.. I think it's impossible to use T5 without t-ioc, is
this right? If it's possible, it would be a good idea uploading
another demo-project without t-ioc.
What else? js.. prototype-based, I know it's possible to have
prototype+jquery together, but I can see lot of people heading jquery,
so I have a long-term plan.. make a tapestry.js based on jquery, if I
do it obviously I'll share it.
But "the solution" for this would be a tapestry.js agnostic, so people
can "inject" their favourite framework. So, maybe it could be shipped
with a default prototype injection, but anyone could write a mootols
injection, jquery injection, etc etc
Last, it would be good more components (ui components).
I think I have no more suggestions
On Wed, Dec 23, 2009 at 5:08 PM, Thiago H. de Paula Figueiredo
<th...@gmail.com> wrote:
> Em Wed, 23 Dec 2009 17:37:24 -0200, Piero Sartini <li...@pierosartini.de>
> escreveu:
>
>> For me, authentication is an important part of a web framework and
>> should provide some standard way to do so.
>
> Wicket itself doesn't. Nor does JSF. (all this as far as I know and I google
> it)
>
> There is a third-party package for Wicket:
> http://wicketstuff.org/confluence/display/STUFFWIKI/Wicket-Security.
>
> For Tapestry, there's ChenilleKit Access:
> http://www.chenillekit.org/chenillekit-access/
>
>> Great! Really looking forward to this.
>
> Me too. :)
>
>> JDO on the other
>> hand does - it was designed from the ground up to support different
>> types of persistence engines.
>
> I never paid attention to JDO. Wouldn't be the case case as JPA regarding
> use of low-level APIs?
>
> Regarding JDO, its implementations need for class enhancement after
> compilation is something very annoying. Am I right?
>
> --
> Thiago H. de Paula Figueiredo
> Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and
> instructor
> Owner, software architect and developer, Ars Machina Tecnologia da
> Informação Ltda.
> http://www.arsmachina.com.br
>
> ---------------------------------------------------------------------
> 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: Discussion
Posted by Piero Sartini <li...@pierosartini.de>.
> Wicket itself doesn't. Nor does JSF. (all this as far as I know and I google
> it)
JSF does not qualify as framework IMHO. Seam brings security.
Agreed on chenillekit.
By the way, it would be nice to have something like wicketstuff.org :-)
> Regarding JDO, its implementations need for class enhancement after
> compilation is something very annoying. Am I right?
Yes, you are. Just wanted to mention that there is something not that
RDBMS specific than JPA.
I think I would prefer the native APIs as well - or maybe NeoDatis v2
if there exists a backend for the db to use. I like the easy to use
api and the clean queries.
Piero
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Discussion
Posted by Sergey Didenko <se...@gmail.com>.
A few thoughts from this discussion:
Tapestry site needs:
1. immediately visible search field over all valuable resources, like wiki.
We were discussing custom google search that makes it.
2. A few more diagrams, like
http://tapestry.apache.org/tapestry5.1/images/component-render-states.png
Re: Discussion
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Wed, 23 Dec 2009 17:37:24 -0200, Piero Sartini <li...@pierosartini.de>
escreveu:
> For me, authentication is an important part of a web framework and
> should provide some standard way to do so.
Wicket itself doesn't. Nor does JSF. (all this as far as I know and I
google it)
There is a third-party package for Wicket:
http://wicketstuff.org/confluence/display/STUFFWIKI/Wicket-Security.
For Tapestry, there's ChenilleKit Access:
http://www.chenillekit.org/chenillekit-access/
> Great! Really looking forward to this.
Me too. :)
> JDO on the other
> hand does - it was designed from the ground up to support different
> types of persistence engines.
I never paid attention to JDO. Wouldn't be the case case as JPA regarding
use of low-level APIs?
Regarding JDO, its implementations need for class enhancement after
compilation is something very annoying. Am I right?
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, software architect and developer, Ars Machina Tecnologia da
Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Discussion
Posted by Piero Sartini <li...@pierosartini.de>.
> More freedom, more control, more complex. Quite hard to avoid that.
Agreed. The challange is to define what parts need to be customized
often, and should be easy to change. For me, these bubbles should be
easy to change.. but as always, others may have a different oppinion.
> I cannot speak for the project, but I think Tapestry tries to be a Web
> framework, not a full stack. At least not yet. ;)
For me, authentication is an important part of a web framework and
should provide some standard way to do so.
> I was talking about a really generic tapestry-tx that could be used with any
> persistence technology, being it backed by relational database or not.
Great! Really looking forward to this.
> IMHO, using JPA or JDO over a non-relational database loses some of the
> benefits of it. I plan to write some projects to run on Google Application
> Engine and I'm going to use the low-level API.
Agreed. The native APIs are much easier in many cases. JPA as a whole
does not even fit well with non relational databases. JDO on the other
hand does - it was designed from the ground up to support different
types of persistence engines.
Piero
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Discussion
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Wed, 23 Dec 2009 16:22:49 -0200, Piero Sartini <li...@pierosartini.de>
escreveu:
>> I wrote that because of the @PersistenceContext. That's the only thing,
>> AFAIK, that would be different from tapestry-hibernate.
>
> From a users perspective, its a matter of injecting EntityManager
> instead of hibernate's Session.
> In the module itself there are more changes.
I don't know Tapestry-IoC from the inside (yet!), so I don't know how
difficult it would be to provide an injection for @PersistenceContext. It
would be straightforward for @Inject.
> Nope, that is the error message only. What I would like to define is
> where the message should be rendered.. and control the markup ;-)
This is done by ValidationDecorator. You can implement your own one and
overrid the "DefaultValidationDecorator" contribution to the
MarkupRenderer service. I have not tested yet, though.
> Right now, the client-side validation is kind of a "blackbox". It
> renders its bubbles with the messages... but if you don't want to have
> these bubbles but your own markup, you need to do things like override
> services you never heard about.
Or disable client-side validation entirely. Agreed with the rest.
> As said before, need to look at the ValidationDecorator again, but my
> feeling still is that this is not as easy as it should be.
> I really want to be able to define where my client-side error messages
> should appear inside the template (very important: how the markup
> should look like)
More freedom, more control, more complex. Quite hard to avoid that.
> I don't like it as well - but tapestry should provide an alternative.
> Maybe the question is if tapestry wants to be a full-stack framework
> or just deliver some building blocks. For being a full-stack
> framework, there is not enough functionality available. To just
> provide building blocks, it dictates too much (javascript library,
> markup, and so on). Of course this is just my feeling.
I cannot speak for the project, but I think Tapestry tries to be a Web
framework, not a full stack. At least not yet. ;)
> And don't get me wrong: I really like tapestry and hava already built
> some projects with it. My reason for all this complaining is just to
> make it even better :-)
:)
> Different ORM frameworks do share much more in common: see JPA2 for
> what is standardized between them.
> For other persistence solutions (like OODBMs, Google BigTable, HBase
> and so on) it gets more difficult... but JDO tries to provide a
> standard for all persistence needings.
I was talking about a really generic tapestry-tx that could be used with
any persistence technology, being it backed by relational database or not.
IMHO, using JPA or JDO over a non-relational database loses some of the
benefits of it. I plan to write some projects to run on Google Application
Engine and I'm going to use the low-level API.
> tapestry-tx could integrate with tapestry-jpa and tapestry-jdo ,-)
That's my plan. ;)
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, software architect and developer, Ars Machina Tecnologia da
Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Discussion
Posted by Piero Sartini <li...@pierosartini.de>.
> I wrote that because of the @PersistenceContext. That's the only thing,
> AFAIK, that would be different from tapestry-hibernate.
>From a users perspective, its a matter of injecting EntityManager
instead of hibernate's Session.
In the module itself there are more changes.
> You can do this in Tapestry too, but not in the template. It goes in
> app.properties. From
> http://tapestry.apache.org/tapestry5.1/guide/validation.html
>
> The first key checked is formId-fieldId-validatorName-message.
> formId: the local component id of the Form component
> fieldId: the local component id of the field (TextField, etc.)
> validatorName: the name of the validator, i.e., "required" or "minlength"
>
> If there is not message for that key, a second check is made, for
> fieldId-validatorName-message.
>
> If that does not match a message, then the built-in default validation
> message is used.
Nope, that is the error message only. What I would like to define is
where the message should be rendered.. and control the markup ;-)
Right now, the client-side validation is kind of a "blackbox". It
renders its bubbles with the messages... but if you don't want to have
these bubbles but your own markup, you need to do things like override
services you never heard about.
As said before, need to look at the ValidationDecorator again, but my
feeling still is that this is not as easy as it should be.
I really want to be able to define where my client-side error messages
should appear inside the template (very important: how the markup
should look like)
> I really dislike container-based authentication. I think it should be
> implemented by the application.
I don't like it as well - but tapestry should provide an alternative.
Maybe the question is if tapestry wants to be a full-stack framework
or just deliver some building blocks. For being a full-stack
framework, there is not enough functionality available. To just
provide building blocks, it dictates too much (javascript library,
markup, and so on). Of course this is just my feeling.
And don't get me wrong: I really like tapestry and hava already built
some projects with it. My reason for all this complaining is just to
make it even better :-)
> The only part I can think that can be the same across different ORM
> frameworks is transaction handling. And a tapestry-tx package is a dream of
> mine.
Different ORM frameworks do share much more in common: see JPA2 for
what is standardized between them.
For other persistence solutions (like OODBMs, Google BigTable, HBase
and so on) it gets more difficult... but JDO tries to provide a
standard for all persistence needings.
tapestry-tx could integrate with tapestry-jpa and tapestry-jdo ,-)
Piero
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Discussion
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Wed, 23 Dec 2009 15:42:20 -0200, Piero Sartini <li...@pierosartini.de>
escreveu:
> I know... but your CRUD package is not tapestry.
It's a Tapestry extension that I plan to contribute to Tapestry itself
when is good enough (a.k.a. it has unit tests).
> That's your oppinion... my feeling is the opposite. On its own, these
> things are simple - but in context of a complex framework like
> tapestry, its hard to get the "big picture".
If it's possible and easy to do what you want but you don't know how, then
I think we have an issue with the documentation, not with the framework
itself.
> The problem is that tapestry.apache.org is static. It can be edited by
> the commiters only.
Just post a JIRA and it's added there.
Of course, a more dynamic page would be a nicer solution.
>> CDI and JPA were released few weeks ago and they were mostly written to
>> be
>> used inside an EJB container. Implementing CDI is not a piece of cake.
>
> JPA is available since over 3 years. And I disagree: it is not mainly
> written to be used inside an EJB container.
I wrote that because of the @PersistenceContext. That's the only thing,
AFAIK, that would be different from tapestry-hibernate.
> JPA2 is new.. but maybe you know that there is a half-finnished module
> available.
Yes, I know. :)
>> All it does is to provide Spring beans as Tapestry services. :)
> Not the other way as well(tapestry services as spring beans?) .. ?
Tapestry-Spring supports both.
> In other frameworks the output is not that static... and such basic
> things like where to add the error messages is easy to change. Take
> Struts2 for an example: <s:error for="fieldName">Error message for
> Field</s:error>
You can do this in Tapestry too, but not in the template. It goes in
app.properties. From
http://tapestry.apache.org/tapestry5.1/guide/validation.html
The first key checked is formId-fieldId-validatorName-message.
formId: the local component id of the Form component
fieldId: the local component id of the field (TextField, etc.)
validatorName: the name of the validator, i.e., "required" or "minlength"
If there is not message for that key, a second check is made, for
fieldId-validatorName-message.
If that does not match a message, then the built-in default validation
message is used.
> I think it is - security is something needed by the majority of
> webapps. Tapestry wants to be my web framework - so why doesn't it
> help me? Using container based authentication is not possible. Its
> hard for newbies to get around this. Not more and not less.
I really dislike container-based authentication. I think it should be
implemented by the application.
> I was not aware of the proxy issue, but I was right that it can't be
> too easy. Anyway, IMHO we should need to think about a more general
> way of handling persistence. ORMs (aka JPA and Hibernate) are just one
> part of the persistence arena..
The only part I can think that can be the same across different ORM
frameworks is transaction handling. And a tapestry-tx package is a dream
of mine.
> If I sound like an uninformed troll,
You just sounded like a troll when you made several about why we don't
have more integrations in Tapestry-IoC without writing one. The rest is a
nice discussion. :)
> that is because I did not manage
> to understand everything good enough. One possibility is that I am
> just too dumb,
I guess not. :)
> the other one would be that tapestry is quite complex
> (what is my whole point above)... (please resist to answer this
> question ;-)
Different points of view, different minds, different opinions. Sorry, I
answered your question. :)
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, software architect and developer, Ars Machina Tecnologia da
Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Discussion
Posted by Piero Sartini <li...@pierosartini.de>.
> Select models out of beans could be improved. My Tapestry CRUD package has a
> solution for that.
I know... but your CRUD package is not tapestry.
> You're talking about a snapshot. This behaviour was changed and now
> everything in the context is allowed.
Hey.. this was no complain, you asked where documentation could be improved ;-)
>> In the backend, it gets more complicated: contributing services,
>> decorating services, overriding services...
>
> I don't think they're complicated.
That's your oppinion... my feeling is the opposite. On its own, these
things are simple - but in context of a complex framework like
tapestry, its hard to get the "big picture".
>> You should know I've tried ;-) BTW the libraries are spread all over
>> the web (google code, kenai, github, tap360..).
>
> There are links to them in http://tapestry.apache.org/.
The problem is that tapestry.apache.org is static. It can be edited by
the commiters only. My feeling is that this forces the community to a
single place: the mailing lists. I am not sure if this is enough to
build an opensource community around a framework like tapestry.
Of course there is the wiki - but it is "hidden" behind lots of menu entries.
> CDI and JPA were released few weeks ago and they were mostly written to be
> used inside an EJB container. Implementing CDI is not a piece of cake.
JPA is available since over 3 years. And I disagree: it is not mainly
written to be used inside an EJB container.
JPA2 is new.. but maybe you know that there is a half-finnished module
available.
> All it does is to provide Spring beans as Tapestry services. :)
Not the other way as well(tapestry services as spring beans?) .. ?
> You're changing the output generated by some. Try to do the same in another
> framework. ;) The documentation could mention it, of course.
In other frameworks the output is not that static... and such basic
things like where to add the error messages is easy to change. Take
Struts2 for an example: <s:error for="fieldName">Error message for
Field</s:error>
> There are many ways of modeling and implementing authentication and
> authorization, so I think it's not a Tapestry responsibility.
I think it is - security is something needed by the majority of
webapps. Tapestry wants to be my web framework - so why doesn't it
help me? Using container based authentication is not possible. Its
hard for newbies to get around this. Not more and not less.
> Besides the proxy issue, you're wrong: it wouldn't be difficult to integrate with Tapestry-Hibernate now it would be hard to something that would work with other
> persistence options.
I was not aware of the proxy issue, but I was right that it can't be
too easy. Anyway, IMHO we should need to think about a more general
way of handling persistence. ORMs (aka JPA and Hibernate) are just one
part of the persistence arena..
> I strongly suggest you to not make bold statements about frameworks you
> don't know very well. ;) It makes you sound like an uninformed troll, but I
> know you're not one, as you made some very good points in this discussion.
If I sound like an uninformed troll, that is because I did not manage
to understand everything good enough. One possibility is that I am
just too dumb, the other one would be that tapestry is quite complex
(what is my whole point above)... (please resist to answer this
question ;-)
Piero
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Discussion
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Wed, 23 Dec 2009 11:20:41 -0200, Piero Sartini <li...@pierosartini.de>
escreveu:
>> What concepts exactly?
>
> Starting in the frontend, there are concepts like the static
> structure, dynamic behaviour, the Environment and the Assets which are
> hard to get. Thats what I remind of fighting with some months ago.
> Also the lag of some functionality: select models out of beans (there
> is a wiki entry, why not include it into core?!), file system assets,
> etc.
There are all Tapestry issues, not Tapestry-IoC ones. I was discussing
Tapestry-IoC.
Static structure, dynamic behaviour won't change because it's Tapestry's
architecture. It allows faster execution and no need to put render state
into the session, allowing way less memory consumption. Its documentation
can be improved, of course. The same can be said about Environment (just a
stack of values) and Assets.
Select models out of beans could be improved. My Tapestry CRUD package has
a solution for that.
> in 5.2 I am currenty fighting how to white list my resources... some
> default examples to allow pictures, css, etc would be nice. (has been
> some time I looked, maybe its now there).
You're talking about a snapshot. This behaviour was changed and now
everything in the context is allowed.
> In the backend, it gets more complicated: contributing services,
> decorating services, overriding services...
I don't think they're complicated. The hard part is to find what to
contribute, decorate or override. But now we're diving inside Tapestry's
architecture, that is made of many small services to be easy to override.
The documentation can be improved about it.
> You should know I've tried ;-) BTW the libraries are spread all over
> the web (google code, kenai, github, tap360..).
There are links to them in http://tapestry.apache.org/.
> tapestry-cdi, tapestry-jpa2, tapestry-persistence in general (with
> transactions ;).
CDI and JPA were released few weeks ago and they were mostly written to be
used inside an EJB container. Implementing CDI is not a piece of cake.
> Also, the available examples are hard to understand..
> take tapestry-spring. It's poorly commented/documented and IMHO hard
> to understand what is going on. Sure, its very little code - but maybe
> that is why it is so hard :)
All it does is to provide Spring beans as Tapestry services. :)
> I know - but the component library uses prototype, and its not
> documented that integrating jquery is easy. There is no jquery module,
> etc.
There's not much need for a module. Just add $jQuery.noConflict(); and
properly-written jQuery plugins work.
> Yes.. I had, but will try again the next days. The point is: A custom
> ValidationDecorator is not documented anywhere. Also it seems a bit
> overcomplicated to just implement some custom markup.
You're changing the output generated by some. Try to do the same in
another framework. ;) The documentation could mention it, of course.
> Good to hear! One wish: Could you explain RegexAuthorizer and
> WhitelistAuthorizer in more detail, maybe with some common examples?
This will be done soon, I guess.
> Very good example: Security is another thing I had expected to just
> work out of the box in a web framework like tapestry. It does not, and
> is not that easy for a new user to come up with a solution (and to
> understand the concepts behind the explanations in the wiki).
There are many ways of modeling and implementing authentication and
authorization, so I think it's not a Tapestry responsibility. Of course,
we could have some integration with OpenID, OAuth and some security
implementation.
> Another argument: If it is that easy to build modules, where is the
> transaction module you want that badly?
1) I'm not paid to work on Tapestry. I wish I was, and I wish this badly.
I didn't have time to write them as I'm and independent developer and I
was trying to make my ends meet. All my time is devoted now to projects
that can help me earn some cash. (By the way, if anyone wants to hire
someone with Tapestry and Hibernate experience to implement something, I'm
here! :)
2) Now we've hit a Tapestry-IoC deficiency: annotations put in service
implementations aren't available in the service proxies. Again, I didn't
have time to fix this.
3) Implementing transaction management isn't so easy, specially when you
want to support pseudo-nested transactions.
> Or.. maybe tapestry-ioc gets in your way somehow?
In this specific scenario, #2 above gets in my way. I've never hit another
issue with Tapestry-IoC, and I built many packages on the top of it. You
can see for yourself here:
http://ars-machina.svn.sourceforge.net/viewvc/ars-machina/
> Maybe its hard to integrate
> with tapestry-hibernate ... or maybe its hard to come up with a
> solution that will be useable by other persistence modules as well.
> However, it seems to be not that easy :)
Besides the proxy issue, you're wrong: it wouldn't be difficult to
integrate with Tapestry-Hibernate now it would be hard to something that
would work with other persistence options.
I strongly suggest you to not make bold statements about frameworks you
don't know very well. ;) It makes you sound like an uninformed troll, but
I know you're not one, as you made some very good points in this
discussion.
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, software architect and developer, Ars Machina Tecnologia da
Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Discussion
Posted by Piero Sartini <li...@pierosartini.de>.
> There's also JavaConfig and use of annotations instead of XML, but
> Tapestry-IoC still looks better to me. And Spring doesn't have distributed
> configuration.
At the time I had a look at Spring it didn't have this ;-)
> What I meant is that it is hard to find your
>> way around the IoC concepts neccessary to master tapestry..
>
> What concepts exactly?
Starting in the frontend, there are concepts like the static
structure, dynamic behaviour, the Environment and the Assets which are
hard to get. Thats what I remind of fighting with some months ago.
Also the lag of some functionality: select models out of beans (there
is a wiki entry, why not include it into core?!), file system assets,
etc.
in 5.2 I am currenty fighting how to white list my resources... some
default examples to allow pictures, css, etc would be nice. (has been
some time I looked, maybe its now there).
In the backend, it gets more complicated: contributing services,
decorating services, overriding services... and most important: what
services to override to solve my problem - how are they playing
together. It is really MUCH to learn.
I agree that its very very powerful once you managed to get over the
initial learning curve. But this curve is _very_ steep. Available
books help (my luck to live in germany), but they do not cover more
detailed things like what I meantioned.
>> Some people say it is over engineered - I don't think so. But maybe
>> its exposing too much of its excellence to the user, forcing us to be
>> as excellent as the developers.
>
> Please give us some examples.
What examples do you want to hear? When I first looked at the tapestry
code I did not understand anything.. it took a lot of time to get into
parts of the architecture, and it will take a lot more to get the
whole picture.
>> Which brings me to another point: It
>> is hard to contribute to tapestry, because you need a very high
>> skillset to join the effort. It's _way_ easier to contribute to wicket
>> or struts2. Result is, of course, that their codebase is not nearly as
>> good as tapestry's.
>
> You can also contribute by writing libraries. ;)
You should know I've tried ;-) BTW the libraries are spread all over
the web (google code, kenai, github, tap360..). A central plugin would
be great.
Tap360's intention was good, but hosted commercially does not help to
gain trust. Also Howard left the company, and some plugins left.
Maybe a good structured wiki page with prominent link on the homepage
would be enough.
> Please give us some examples of hard-to-build modules.
tapestry-cdi, tapestry-jpa2, tapestry-persistence in general (with
transactions ;). Also, the available examples are hard to understand..
take tapestry-spring. It's poorly commented/documented and IMHO hard
to understand what is going on. Sure, its very little code - but maybe
that is why it is so hard :)
> This point was discussed a lot and
> I have a component that uses a very nice jQuery color picker and it works.
I know - but the component library uses prototype, and its not
documented that integrating jquery is easy. There is no jquery module,
etc.
> From a quick read (I'm busy writing a Tapestry course now), it seems that
> YAML is a CSS framework.
Yep - and also it defines common template structure for forms, regions, etc.
> The thread is here:
> http://old.nabble.com/Customize-markup-of-client-side-validation-to26668520s302.html#a26668520
> There was a solution proposed (your own ValidationDecorator). Have you had
> problems with this approach?
Yes.. I had, but will try again the next days. The point is: A custom
ValidationDecorator is not documented anywhere. Also it seems a bit
overcomplicated to just implement some custom markup.
> The documentation has been improved by Howard and you can see its progress
> here: http://tapestry.formos.com/nightly/tapestry5/
Good to hear! One wish: Could you explain RegexAuthorizer and
WhitelistAuthorizer in more detail, maybe with some common examples?
>> (and comes with warp-persist,
>> offering JPA and db4o integrations - transactions as well).
>
> In this case, it seems to me it's a matter of money. Many people at Google
> work on it in their paid time, while almost everyone working on Tapestry
> work in their free time.
Thats an explanation - but does not help.
> I'm sorry, but your examples weren't enough for me to understand.
> One counter-example: in my Ars Machina Project, I have authentication and
> authorization packages. I only need to add annotations to my page classes to
> inform if it needs a logged user and/or what roles the need use to be able
> to use that page. I have an access logger package that works just by adding
> it to the classpath.
Very good example: Security is another thing I had expected to just
work out of the box in a web framework like tapestry. It does not, and
is not that easy for a new user to come up with a solution (and to
understand the concepts behind the explanations in the wiki).
Like said before, tapestry is very powerful - but you need to invent a
lot of stuff yourself. And then this isn't something easy (as a
newbie).
Another argument: If it is that easy to build modules, where is the
transaction module you want that badly? It shouldn't be too
complicated, a matter of decorating annotated services. Or.. maybe
tapestry-ioc gets in your way somehow? Maybe its hard to integrate
with tapestry-hibernate ... or maybe its hard to come up with a
solution that will be useable by other persistence modules as well.
However, it seems to be not that easy :)
> The markup is responsibility of each component. You can write a mixin to
> change the generated markup or write your own components.
Mixins are no nice solution for this usecase. And writing my own
components just to change some structure?
That's not exactly the flexibility I would expect.
Piero
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Discussion
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Wed, 23 Dec 2009 09:20:05 -0200, Piero Sartini <li...@pierosartini.de>
escreveu:
> I never liked Spring because of its XML configuration.
There's also JavaConfig and use of annotations instead of XML, but
Tapestry-IoC still looks better to me. And Spring doesn't have distributed
configuration.
> I like guice and tapestry-ioc better.
Guice inspired Tapestry-IoC. :)
What I meant is that it is hard to find your
> way around the IoC concepts neccessary to master tapestry..
What concepts exactly?
> Some people say it is over engineered - I don't think so. But maybe
> its exposing too much of its excellence to the user, forcing us to be
> as excellent as the developers.
Please give us some examples.
> Which brings me to another point: It
> is hard to contribute to tapestry, because you need a very high
> skillset to join the effort. It's _way_ easier to contribute to wicket
> or struts2. Result is, of course, that their codebase is not nearly as
> good as tapestry's.
You can also contribute by writing libraries. ;)
> That may be one point. But our module landscape outside the core is
> really thin. And it is also hard to build some modules, because it
> would not be the tapestry way.
Please give us some examples of hard-to-build modules.
> Think about jQuery or other JS
> libraries (ExtJS, Dojo, etc) for example (IMHO the Prototype
> dependency frightened a lot of people).
This point was discussed a lot and
I have a component that uses a very nice jQuery color picker and it works.
> If you remember some weeks back, I was trying to integrate YAML (Yet
> another Multicolumn Layout: http://www.yaml.de) with tapestry... I
> gave up.
From a quick read (I'm busy writing a Tapestry course now), it seems that
YAML is a CSS framework.
The thread is here:
http://old.nabble.com/Customize-markup-of-client-side-validation-to26668520s302.html#a26668520
There was a solution proposed (your own ValidationDecorator). Have you had
problems with this approach?
> Maybe because of lacking tapestry documentation.. but it is
> really not as easy as it should be! Tapestry claims to be flexible..
> but adopting it to your needs is difficult (and not documented).
The documentation has been improved by Howard and you can see its progress
here: http://tapestry.formos.com/nightly/tapestry5/
>> The day you understand distributed configuration I guess you'll change
>> your mind. :)
>
> Guice does have all of this as well
Guice has distributed configuration, but not explicitly and not as easy as
in Tapestry-IoC.
> (and comes with warp-persist,
> offering JPA and db4o integrations - transactions as well).
In this case, it seems to me it's a matter of money. Many people at Google
work on it in their paid time, while almost everyone working on Tapestry
work in their free time.
> See above for two modules I tried to build with tapestry-ioc.
I'm sorry, but your examples weren't enough for me to understand.
One counter-example: in my Ars Machina Project, I have authentication and
authorization packages. I only need to add annotations to my page classes
to inform if it needs a logged user and/or what roles the need use to be
able to use that page. I have an access logger package that works just by
adding it to the classpath.
> What I would love to be better documented is how to adopt the markup
> to your needs. Changing CSS is easy - but I did not find out how to
> change the markup yet.
The markup is responsibility of each component. You can write a mixin to
change the generated markup or write your own components.
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, software architect and developer, Ars Machina Tecnologia da
Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Discussion
Posted by Piero Sartini <li...@pierosartini.de>.
>> 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.
>
> What exactly is difficult to master? I think Tapestry-IoC is easier to learn
> than Spring.
> Maybe there's a sensation of Tapestry being hard to master because it's
> built on IoC and has many hooks to do many things. Other frameworks has many
> hooks, but less ways to customize them without changing the sources or doing
> difficult configurations.
I never liked Spring because of its XML configuration. I like guice
and tapestry-ioc better. What I meant is that it is hard to find your
way around the IoC concepts neccessary to master tapestry.. I am
learning something new every day, and do develop with tapestry 5 for
about one year now.
Some people say it is over engineered - I don't think so. But maybe
its exposing too much of its excellence to the user, forcing us to be
as excellent as the developers. Which brings me to another point: It
is hard to contribute to tapestry, because you need a very high
skillset to join the effort. It's _way_ easier to contribute to wicket
or struts2. Result is, of course, that their codebase is not nearly as
good as tapestry's.
>> 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.
>
> I guess is that because these frameworks are older and people had more time
> to write these integration modules. Tapestry 5 is way younger, specially
> when you think that the first stable version was released in December 18th,
> 2009, one year and 5 days ago. Wicket 1.0 was released in June 2005, 4.5
> years ago. That's a 3.5 years head start.
That may be one point. But our module landscape outside the core is
really thin. And it is also hard to build some modules, because it
would not be the tapestry way. Think about jQuery or other JS
libraries (ExtJS, Dojo, etc) for example (IMHO the Prototype
dependency frightened a lot of people).
If you remember some weeks back, I was trying to integrate YAML (Yet
another Multicolumn Layout: http://www.yaml.de) with tapestry... I
gave up. Maybe because of lacking tapestry documentation.. but it is
really not as easy as it should be! Tapestry claims to be flexible..
but adopting it to your needs is difficult (and not documented).
> There isn't an integration with JFreeChart or JasperReports, for example,
> maybe because it's so easy to write it (a page returning StreamResponse in
> its onActivate() method).
I agree :)
>> But I would be perfectly fine trading the IoC container...
>
> The day you understand distributed configuration I guess you'll change your
> mind. :)
Guice does have all of this as well (and comes with warp-persist,
offering JPA and db4o integrations - transactions as well).
By the way, look out for google sitebricks... it reminds me a lot of tapestry.
> I also use Spring, and I think Tapestry-IoC is bothe easier and more
> powerful.
See below, I don't even tried to use Spring.... starting with EJB3
there was no need to do so.
> But what exactly do you find difficult in Tapestry-IoC? What could be
> easier? What could be better documented? What have you tried to do with
> T-IoC and failed?
> Feedback is very important and we can use it to improve Tapestry and
> Tapestry-IoC. ;)
See above for two modules I tried to build with tapestry-ioc. My
conclusion is that integrating third-party modules is too difficult.
What I would love to be better documented is how to adopt the markup
to your needs. Changing CSS is easy - but I did not find out how to
change the markup yet.
Piero
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Discussion
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Wed, 23 Dec 2009 08:28:35 -0200, Piero Sartini <li...@pierosartini.de>
escreveu:
> 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.
Agreed. :)
> 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.
What exactly is difficult to master? I think Tapestry-IoC is easier to
learn than Spring.
Maybe there's a sensation of Tapestry being hard to master because it's
built on IoC and has many hooks to do many things. Other frameworks has
many hooks, but less ways to customize them without changing the sources
or doing difficult configurations.
> 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.
I guess is that because these frameworks are older and people had more
time to write these integration modules. Tapestry 5 is way younger,
specially when you think that the first stable version was released in
December 18th, 2009, one year and 5 days ago. Wicket 1.0 was released in
June 2005, 4.5 years ago. That's a 3.5 years head start.
There isn't an integration with JFreeChart or JasperReports, for example,
maybe because it's so easy to write it (a page returning StreamResponse in
its onActivate() method).
> But I would be perfectly fine trading the IoC container...
The day you understand distributed configuration I guess you'll change
your mind. :)
I also use Spring, and I think Tapestry-IoC is bothe easier and more
powerful.
But what exactly do you find difficult in Tapestry-IoC? What could be
easier? What could be better documented? What have you tried to do with
T-IoC and failed?
Feedback is very important and we can use it to improve Tapestry and
Tapestry-IoC. ;)
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, software architect and developer, Ars Machina Tecnologia da
Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Discussion
Posted by Piero Sartini <li...@pierosartini.de>.
> 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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Discussion
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Wed, 23 Dec 2009 07:59:47 -0200, Gerald Bauer <gt...@gmail.com>
escreveu:
> Lutz,
Hi!
> 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.
Tapestry-IoC's public API is very, very small, so I don't think an API
break is necessary at all for CDI support.
My classes are Tapestry-IoC services and they have no dependency on it.
AFAIK, all it needs to implement CDI is to keep the current semantics and
change to CDI's when CDI's @Inject annotation is found.
> 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.
That wouldn't work. Wicket and Tapestry share many concepts, but the
approach to implement them is radically different. I don't think another
JSR concerning web frameworks would be accepted. I also think that JSRs
work better for lower level issues (transaction management,
object-relational mapping). Anyway, I love the idea of competition: we
have many different Web frameworks with many different approaches, with
many of them bringing some nice inovations that can be added to the
others. Diversity is a very good thing. :)
By the way, why don't we standardize Tapestry instead of Wicket? ;)
> Again, I know this is a controversial proposition that might result in
> some immature ones labeling and calling me names, as I've seen in the
> archives.
We had some unbelievably annoying trolls in the past, almost all of them
Wicket users, so there was a precedent here. If you're not a troll,
welcome to the list. :)
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, software architect and developer, Ars Machina Tecnologia da
Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Discussion
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Wed, 23 Dec 2009 08:21:23 -0200, Peter Stavrinides
<P....@albourne.com> escreveu:
>> There's a recent discussion about that in the dev mailing list. Everyone
>> is invited. :)
> Thiago could you provide a link perhaps?
Yes! :)
http://old.nabble.com/JSR-229%2C-JSR-330-and-other-integrations-to26857781.html
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, software architect and developer, Ars Machina Tecnologia da
Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Discussion
Posted by Peter Stavrinides <P....@albourne.com>.
> There's a recent discussion about that in the dev mailing list. Everyone
> is invited. :)
Thiago could you provide a link perhaps?
--
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.
----- Original Message -----
From: "Gerald Bauer" <gt...@gmail.com>
To: "Tapestry users" <us...@tapestry.apache.org>
Sent: Wednesday, 23 December, 2009 11:59:47 GMT +02:00 Athens, Beirut, Bucharest, Istanbul
Subject: Re: Discussion
Lutz,
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 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.
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.
Again, I know this is a controversial proposition that might result in some
immature ones labeling and calling me names, as I've seen in the archives.
On the other hand I know there are wise and intelligent ones in this
community who would offer constructive arguments. It is these group of
people that I'll consider serious.
Gerald
2009/12/23 Lutz Hühnken <lh...@googlemail.com>
> Hi everybody,
>
> I think the discussion on TheServerSide actually is somewhat
> interesting, but not because of the unfortunate Tapestry vs. Wicket
> flame war. Let's have a look at the topic leading to that...
>
> - One part of Java EE 6 is "CDI" (JSR 299) -
> http://jcp.org/en/jsr/detail?id=299 - originally called "Web beans". I
> think it was inspired by Gavin Kings Seam Framework.
>
> - The reference implementation for that seems to be something called
> "Weld" - http://docs.jboss.org/weld/reference/1.0.0/en-US/html/
>
> - Weld has Wicket support build in, and the examples are given in
> Wicket (although the Java EE "standard" would be JSF 2) because Wicket
> is easier to learn than JSF (at least Gavin King says so in
> http://in.relation.to/Bloggers/HowToStartLearningJavaEE6, but I think
> many would agree with that).
>
> So the interesting (to me, at least) questions are:
>
> - How does CDI relate to Tapesty and Tapestry IOC?
>
> - Should / could Tapestry incorporate / conform to CDI somehow?
>
> - Should we try to add Tapestry support to Weld?
>
> - Or is Java EE 6 / CDI just not relevant to Tapestry?
>
> I haven't really looked at Web Beans resp. CDI yet, but from first
> site, it defines some context scopes (request, session, application,
> conversation) and some annotation based dependency injection.
> Both areas are already covered by Tapestry (although afaik there is no
> conversation scope (yet) in Tapestry).
>
> So are CDI and Tapestry mutually exclusive? Or should Tapestry be
> refactored to use standard CDI annotations, so it can claim to be a
> CDI / JSR 299 implementation?
>
> I would love to hear your opinions about that.
>
> Regards,
> Lutz
>
>
>
>
> --
> altocon GmbH
> http://www.altocon.de/
> Software Development, Consulting
> Hamburg, Germany
>
> ---------------------------------------------------------------------
> 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: Discussion
Posted by Gerald Bauer <gt...@gmail.com>.
Lutz,
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 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.
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.
Again, I know this is a controversial proposition that might result in some
immature ones labeling and calling me names, as I've seen in the archives.
On the other hand I know there are wise and intelligent ones in this
community who would offer constructive arguments. It is these group of
people that I'll consider serious.
Gerald
2009/12/23 Lutz Hühnken <lh...@googlemail.com>
> Hi everybody,
>
> I think the discussion on TheServerSide actually is somewhat
> interesting, but not because of the unfortunate Tapestry vs. Wicket
> flame war. Let's have a look at the topic leading to that...
>
> - One part of Java EE 6 is "CDI" (JSR 299) -
> http://jcp.org/en/jsr/detail?id=299 - originally called "Web beans". I
> think it was inspired by Gavin Kings Seam Framework.
>
> - The reference implementation for that seems to be something called
> "Weld" - http://docs.jboss.org/weld/reference/1.0.0/en-US/html/
>
> - Weld has Wicket support build in, and the examples are given in
> Wicket (although the Java EE "standard" would be JSF 2) because Wicket
> is easier to learn than JSF (at least Gavin King says so in
> http://in.relation.to/Bloggers/HowToStartLearningJavaEE6, but I think
> many would agree with that).
>
> So the interesting (to me, at least) questions are:
>
> - How does CDI relate to Tapesty and Tapestry IOC?
>
> - Should / could Tapestry incorporate / conform to CDI somehow?
>
> - Should we try to add Tapestry support to Weld?
>
> - Or is Java EE 6 / CDI just not relevant to Tapestry?
>
> I haven't really looked at Web Beans resp. CDI yet, but from first
> site, it defines some context scopes (request, session, application,
> conversation) and some annotation based dependency injection.
> Both areas are already covered by Tapestry (although afaik there is no
> conversation scope (yet) in Tapestry).
>
> So are CDI and Tapestry mutually exclusive? Or should Tapestry be
> refactored to use standard CDI annotations, so it can claim to be a
> CDI / JSR 299 implementation?
>
> I would love to hear your opinions about that.
>
> Regards,
> Lutz
>
>
>
>
> --
> altocon GmbH
> http://www.altocon.de/
> Software Development, Consulting
> Hamburg, Germany
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
Re: Discussion
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Wed, 23 Dec 2009 06:25:14 -0200, Lutz Hühnken
<lh...@googlemail.com> escreveu:
> Hi everybody,
Hi!
> So the interesting (to me, at least) questions are:
> - How does CDI relate to Tapesty and Tapestry IOC?
> - Should / could Tapestry incorporate / conform to CDI somehow?
> - Should we try to add Tapestry support to Weld?
> - Or is Java EE 6 / CDI just not relevant to Tapestry?
There's a recent discussion about that in the dev mailing list. Everyone
is invited. :)
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, software architect and developer, Ars Machina Tecnologia da
Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Discussion
Posted by Lutz Hühnken <lh...@googlemail.com>.
Hi everybody,
I think the discussion on TheServerSide actually is somewhat
interesting, but not because of the unfortunate Tapestry vs. Wicket
flame war. Let's have a look at the topic leading to that...
- One part of Java EE 6 is "CDI" (JSR 299) -
http://jcp.org/en/jsr/detail?id=299 - originally called "Web beans". I
think it was inspired by Gavin Kings Seam Framework.
- The reference implementation for that seems to be something called
"Weld" - http://docs.jboss.org/weld/reference/1.0.0/en-US/html/
- Weld has Wicket support build in, and the examples are given in
Wicket (although the Java EE "standard" would be JSF 2) because Wicket
is easier to learn than JSF (at least Gavin King says so in
http://in.relation.to/Bloggers/HowToStartLearningJavaEE6, but I think
many would agree with that).
So the interesting (to me, at least) questions are:
- How does CDI relate to Tapesty and Tapestry IOC?
- Should / could Tapestry incorporate / conform to CDI somehow?
- Should we try to add Tapestry support to Weld?
- Or is Java EE 6 / CDI just not relevant to Tapestry?
I haven't really looked at Web Beans resp. CDI yet, but from first
site, it defines some context scopes (request, session, application,
conversation) and some annotation based dependency injection.
Both areas are already covered by Tapestry (although afaik there is no
conversation scope (yet) in Tapestry).
So are CDI and Tapestry mutually exclusive? Or should Tapestry be
refactored to use standard CDI annotations, so it can claim to be a
CDI / JSR 299 implementation?
I would love to hear your opinions about that.
Regards,
Lutz
--
altocon GmbH
http://www.altocon.de/
Software Development, Consulting
Hamburg, Germany
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org