You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by Igor Drobiazko <ig...@gmail.com> on 2011/03/14 09:21:41 UTC
Re: HybridJava vs. Tapestry
It makes you much more credible if you understand what you are talking
about. You should read Tapestry's documentation before posting such a blog.
First of all, if you would spend 5 minutes learning Tapestry you would come
across the "static structure, dynamic behavior" principle. Tapestry is not
"rescanning templates and building DOM of the page before each rendering".
All the page instances are singletons, which are smart enough to care for
multithreading aspects. So, your expectation on efficiency is naive. If you
want to speak about performance, create two similar apps with both
technologies and measure the results. Show me the results, but please don't
come up with something like "All in all it’s hard to expect Tapestry to be
fast in production.".
Also your statements on Tapestry's IoC, mixins, template inheritance and
annotation-based approach are sweet and naive as you don't provide any
arguments. These features are why Tapestry users love the framework.
Nice try, but not professional.
On Mon, Mar 14, 2011 at 1:34 AM, AlexSerov <Hy...@gmail.com>wrote:
> Tapestry framework by its ideas seems to be the most close framework to
> HybridJava.
>
> Comparison of HybridJava and Tapestry:
> http://hybridjava.blogspot.com/2011/03/hybridjava-vs-tapestry.html
>
> It would be nice to know everyone's opinion.
>
> HybridJava team.
>
> --
> View this message in context:
> http://tapestry.1045711.n5.nabble.com/How-about-a-5-2-5-tp3414983p3555809.html
> Sent from the Tapestry - Dev mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
Best regards,
Igor Drobiazko
http://tapestry5.de
Re: HybridJava vs. Tapestry -previous mail screwed up
Posted by AlexSerov <Hy...@gmail.com>.
> Less memory usage due to not use recursion. Less deep stack traces too. :)
Oh no! The depth of the stack trace is defined by the page you want to
build. Weather you use recursion or not does not change that. If the page
implies presenting five levels that will be five leveles regardless.
> Someone said that you shouldn't look at a JSF one if you have vertigo. :P
Most unfortunately I have already looked at JSF, though 2.0.
>> From Tapestry site I have also concluded that things like buttons and
>> text fields are components and thus imply using instances. Are these ones
>> created at page run-time or not?
>Absolutely no. There's a single instance for each page class with all the
component tree pre-instantiated. A page render is just rendering the page
and its components.
That is not that simple. Both to answer and to ask. If a component in
Tapestry is what I think then I suppose it has a state independent from that
of the page. Each component entry in this case must have a separate class
instance to keep that state. Different for different users. I've read that
Tapestry cleans the object corresponding to a page after rendering is over.
Not sure what it does with instances of components. Seems like that means
that before each rendering (absolutely so when a different user hits) the
page with the component tree should be restored. As someone noticed it is
not 2000 now ans pooling objects is consigered by many as beeng spower than
recreating by "new" with garbage collection. I asked not about rendering,
but about run-time of one page. I have a feeling that Tapestry has to
recreate (or re-obtain - does not matter) all the instances of components
anew?
>> Finally - the user actions are passed in the form of "events" (so I
>> read). Does this process also imply creating some objects at Java
>> run-time?
>Just the object containing the event context parameters, and just if the
event handler method has a List or EventContext object.
That may be not a huge advantage, but HybridJava solves this task without
any objects.
>> As a matter of fact HybridJava creates only one class instance that
>> carries the page model values and at the same time has the both the
>> render and handle methods on it. Regardless of the number of buttons and
>> text fields.
>Same as Tapestry in this respect.
This does not match to what you told right above: "object containing" us an
object, List is an object. Are "context parameters" and "EventContext
object" objects as well?
>>These measurements only have significance if they implement exactly the
same application or use cases.
That is what I say. If you do not like my tests do give me yours.
>> SO, what about you choose a test that I implement using HybridJava (you
>> most probably already have that test implemented using Tapestry) and I
>> send you my test that you implement using Tapestry. That is a way that
>> will require minimum effort from anybody and the only practical.
>Ok!
Looking forward. If fact each of us already has tests implemented by his own
framework.
>I didn't say it was enough. I just cited one comparison
It is not enough because such researches are absolutely rare, not because
you said "enough".
>> What matters is that it is a kind of redundant mechanism. I understand
>> that at some point it was borrowed from PHP.
>It wasn't. And what do you mean by redundant?
That means exactly that if you cut it off the documentation and from
implementation as well Tapestry will be same usable as before.
><t:body> doesn't couple components. Tapestry's philosophy is to have the
least coupling possible.
I am not strong in philosophy. There is no framework that does not claim
that it's philosophy isn't about minimization of coupling between components
(on of which is the page).
Here is a concrete example: suppose we have a component like chat. It has
its own buttons and text fields and does not depend on anything at all. On
that page you probably have a component that defines the nice surrounding
common for all pages and a hole in the middle that you want to fill with a
content. Suppose I want to put there 2 chat components.
In HybridJava that will look like:
<html><PageLayout><chat/><chat/></PageLayout></html>. And
that is it. No other configuration or mentioning the chat component in the
some java code. The only coupling of the complnents here is their
positioning on the page and one relative to another which is all solved by
the means of mark-up and which seem being minimal possible. And you may chat
with two friends in parallel.
How would similar example look in Tapestry? I ask because I did not go into
Tapestry that deep yet.
--
View this message in context: http://tapestry.1045711.n5.nabble.com/Re-HybridJava-vs-Tapestry-tp3555989p3752340.html
Sent from the Tapestry - Dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: HybridJava vs. Tapestry
Posted by Josh Canfield <jo...@gmail.com>.
Alex.
I can only assume that your goal here is to drum up some notice of
your framework. I understand that in this competitive environment that
getting noticed can be a challenge. If you truly believe in your
approach to web applications and you want your framework to be taken
seriously you need to get a site into production. You need to be able
to point to live sites that are solving problems that developers have
to solve. To bootstrap this you'll probably have to do some consulting
gigs and do the implementations. Building something real is a great
way to understand the strengths and weaknesses of your tools.
Tapestry is open source so you can peek into the internals and see all
the warts first hand. There is also an open source application running
in the wild that exercises features that solve real world problems.
Site
http://tapestry.zones.apache.org:8180/tapestry5-hotel-booking/signin
Code
https://github.com/ccordenier/tapestry5-hotel-booking/
I try not to be rude often, but to be brutally honest; your website
doesn't inspire confidence in your framework. As unfair as it is,
looking good is important even for something that should be based
purely on technical merit. Simplify your examples and pretend to be
solving real world problems. How do I attach to a database? How do I
work with existing code? How do I optimize for search engines?
Anyway, good luck with your framework.
Josh
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: HybridJava vs. Tapestry
Posted by Howard Lewis Ship <hl...@gmail.com>.
This is very similar to Paul Graham's discourse on programming
languages from "Hackers and Painters". Roughly para-phrased, he
points out that a Java programmer will look down on "lesser" (simpler,
less sophisticated) programming languages, such as Basic because they
are missing features and constructs that are in their language of
choice. On the other hand, when they look up spectrum at most
powerful/more sophisticated such as Lisp, they think that the features
of that language (macros, closures, first-class functions) are just
confusing, or arbitrary, or not useful, or get in the way.
Likewise, if you look at a lower-power web framework; one that uses
JSPs or a JSP-like system with an action-oriented framework,
Tapestry's components and events seem very complicated and expensive.
In practice, of course, Tapestry features are mostly invisible ...
write a Java class and a template and you have a fully functioning
page. Further, because the lower powered framework has limited what it
can express to just rendering HTML character by character, it can
wholesale convert a page into a single class; this makes it seem like
using lots of small classes to accomplish "the same thing" is wasteful
and even slow .. though, of course, using lots of small well defined
objects is, in my never-humble opinion, a better utilization of the
nature of a garbage-collected OO language like Java.
On Wed, Mar 16, 2011 at 1:38 AM, Inge Solvoll <in...@gmail.com> wrote:
> Entertaining in a weird way.
>
> On Wed, Mar 16, 2011 at 6:19 AM, Howard Lewis Ship <hl...@gmail.com> wrote:
>
>> Is this "discussion" serving any purpose?
>>
>> On Tue, Mar 15, 2011 at 9:23 PM, AlexSerov <Hy...@gmail.com>
>> wrote:
>> > Hi!
>> >
>> > Apparently due to my mistake with formatting you could not read most
>> > part of my mail. I have resubmitted later.
>> >
>> >> What you described is not correct to Tapestry page rendering. The DOM is
>> >> recursive, but it's rendering is not.
>> >
>> > That is beyond my understanding, but I assume that is not urgent.
>> >
>> >> The component state is independent from the page.
>> > Anyway that is a separate object.
>> >
>> >>> Each component entry in this case must have a separate class
>> >>> instance to keep that state.
>> >>
>> >> Correct.
>> >>
>> >>> Different for different users.
>> >
>> > I mean that there are different state object for different users,
>> > which is probabaly trivial.
>> >
>> >> Wrong. From a Howard blog post:
>> >>
>> >> "Tapestry 5.2 rewrites the rules here; only a single page tree is now
>> >> needed for each page; the page and component classes have an extra
>> >> transformation step that moves per-request data out of the objects
>> >> themselves and into a per-thread Map object. Now, any number of requests
>> >> can operate at the same time, without requiring additional page
>> instances.
>> >> Even better, the old page pooling mechanism included some locking and
>> >> blocking that also gets jettisoned in the new approach. It's just a big
>> >> win all around."
>> >
>> > Nothing to discuss if page is something independant from page state.
>> > Reparing you own mistakes made at design time is a know way of moving
>> > forward (big win). Compared to HybridJava that is about terminology.
>> > In HybridJava one page instance is created per user. The state (of
>> > course user-specific) is kept in that instance (so once one gets back
>> > to the same page the previous state is by default still there). The
>> > handler and renederer are static methods of same class, so there is no
>> > direct analogy to what page is in instance. No DOM at all in
>> > HybridJava, but of course, as you've explained DOM of the page is
>> > build once that is fine.
>> >
>> >> In Tapestry 5.2, it's just a matter of not using the same per-thread Map
>> >> instance again.
>> >
>> > I bet instances of Map are pretty redundant. By the way - recently got
>> > to know that Play does not use Servlet inside - what about tapestry?
>> >
>> > ... seems you were not able to read starting from here ...
>> >
>> >>> Not sure what it does with instances of components. Seems like that
>> means
>> >>> that before each rendering (absolutely so when a different user hits)
>> the
>> >>> page with the component tree should be restored. As someone noticed it
>> is
>> >>> not 2000 now ans pooling objects is consigered by many as beeng spower
>> >>> than
>> >>> recreating by "new" with garbage collection. I asked not about
>> rendering,
>> >>> but about run-time of one page. I have a feeling that Tapestry has to
>> >>> recreate (or re-obtain - does not matter) all the instances of
>> components
>> >>> anew?
>> >>>
>> >>>>> Finally - the user actions are passed in the form of "events" (so I
>> >>>>> read). Does this process also imply creating some objects at Java
>> >>>>> run-time?
>> >>>
>> >>>> Just the object containing the event context parameters, and just if
>> the
>> >>> event handler method has a List or EventContext object.
>> >>>
>> >>> That may be not a huge advantage, but HybridJava solves this task
>> without
>> >>> any objects.
>> >>>
>> >>>>> As a matter of fact HybridJava creates only one class instance that
>> >>>>> carries the page model values and at the same time has the both the
>> >>>>> render and handle methods on it. Regardless of the number of buttons
>> >>>>> and
>> >>>>> text fields.
>> >>>
>> >>>> Same as Tapestry in this respect.
>> >>> This does not match to what you told right above: "object containing"
>> us
>> >>> an
>> >>> object, List is an object. Are "context parameters" and "EventContext
>> >>> object" objects as well?
>> >>>
>> >>>>> These measurements only have significance if they implement exactly
>> the
>> >>> same application or use cases.
>> >>> That is what I say. If you do not like my tests do give me yours.
>> >>>
>> >>>>> SO, what about you choose a test that I implement using HybridJava
>> (you
>> >>>>> most probably already have that test implemented using Tapestry) and
>> I
>> >>>>> send you my test that you implement using Tapestry. That is a way
>> that
>> >>>>> will require minimum effort from anybody and the only practical.
>> >>>
>> >>>> Ok!
>> >>>
>> >>> Looking forward. If fact each of us already has tests implemented by
>> his
>> >>> own
>> >>> framework.
>> >>>
>> >>>> I didn't say it was enough. I just cited one comparison
>> >>> It is not enough because such researches are absolutely rare, not
>> because
>> >>> you said "enough".
>> >>>
>> >>>>> What matters is that it is a kind of redundant mechanism. I
>> understand
>> >>>>> that at some point it was borrowed from PHP.
>> >>>
>> >>>> It wasn't. And what do you mean by redundant?
>> >>>
>> >>> That means exactly that if you cut it off the documentation and from
>> >>> implementation as well Tapestry will be same usable as before.
>> >>>
>> >>>> doesn't couple components. Tapestry's philosophy is to have the least
>> >>>> coupling possible.
>> >>> I am not strong in philosophy. There is no framework that does not
>> claim
>> >>> that it's philosophy isn't about minimization of coupling between
>> >>> components
>> >>> (on of which is the page).
>> >>>
>> >>> Here is a concrete example: suppose we have a component like chat. It
>> has
>> >>> its own buttons and text fields and does not depend on anything at all.
>> >>> On
>> >>> that page you probably have a component that defines the nice
>> surrounding
>> >>> common for all pages and a hole in the middle that you want to fill
>> with
>> >>> a
>> >>> content. Suppose I want to put there 2 chat components.
>> >>>
>> >>> In HybridJava that will look like: . And that is it. No other
>> >>> configuration
>> >>> or mentioning the chat component in the some java code. The only
>> >>> coupling of
>> >>> the complnents here is their positioning on the page and one relative
>> to
>> >>> another which is all solved by the means of mark-up and which seem
>> being
>> >>> minimal possible. And you may chat with two friends in parallel.
>> >>>
>> >>> How would similar example look in Tapestry? I ask because I did not go
>> >>> into
>> >>> Tapestry that deep yet.
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> View this message in context:
>> >>>
>> >>>
>> http://tapestry.1045711.n5.nabble.com/Re-HybridJava-vs-Tapestry-tp3555989p3751648.html
>> >>> Sent from the Tapestry - Dev mailing list archive at Nabble.com.
>> >>>
>> >>> ---------------------------------------------------------------------
>> >>> To unsubscribe, e-mail: [hidden email]
>> >>> For additional commands, e-mail: [hidden email]
>> >>>
>> >>
>> >> --
>> >> Thiago H. de Paula Figueiredo
>> >> Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
>> >> and instructor
>> >> Owner, Ars Machina Tecnologia da Informação Ltda.
>> >> Consultor, desenvolvedor e instrutor em Java, Tapestry e Hibernate
>> >> Coordenador e professor da Especialização em Engenharia de Software com
>> >> Ênfase em Java da Faculdade Pitágoras
>> >> http://www.arsmachina.com.br
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: [hidden email]
>> >> For additional commands, e-mail: [hidden email]
>> >>
>> >>
>> >>
>> >> ________________________________
>> >> If you reply to this email, your message will be added to the discussion
>> >> below:
>> >>
>> http://tapestry.1045711.n5.nabble.com/Re-HybridJava-vs-Tapestry-tp3555989p3753159.html
>> >> To unsubscribe from Re: HybridJava vs. Tapestry, click here.
>> >
>> >
>> > --
>> > View this message in context:
>> http://tapestry.1045711.n5.nabble.com/Re-HybridJava-vs-Tapestry-tp3555989p3756578.html
>> > Sent from the Tapestry - Dev mailing list archive at Nabble.com.
>>
>>
>>
>> --
>> 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: dev-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: dev-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: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: HybridJava vs. Tapestry
Posted by Massimo Lusetti <ml...@gmail.com>.
On Wed, Mar 16, 2011 at 6:01 PM, Josh Canfield <jo...@gmail.com> wrote:
>> I guess I was in a case of this: http://xkcd.com/386/.
> That's funny every time I read it.
Yeah... old but always relevant and funny
--
Massimo
http://meridio.blogspot.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: HybridJava vs. Tapestry
Posted by Josh Canfield <jo...@gmail.com>.
> I guess I was in a case of this: http://xkcd.com/386/.
That's funny every time I read it.
On Wed, Mar 16, 2011 at 9:51 AM, Thiago H. de Paula Figueiredo
<th...@gmail.com> wrote:
> On Wed, 16 Mar 2011 13:48:08 -0300, Josh Canfield <jo...@gmail.com>
> wrote:
>
>>> Entertaining in a weird way.
>>
>> Yes, very weird. And verbose. And a bit tedious.
>
> I guess I was in a case of this: http://xkcd.com/386/.
>
> --
> Thiago H. de Paula Figueiredo
> Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and
> instructor
> Owner, Ars Machina Tecnologia da Informação Ltda.
> http://www.arsmachina.com.br
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: HybridJava vs. Tapestry
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
On Wed, 16 Mar 2011 13:48:08 -0300, Josh Canfield <jo...@gmail.com>
wrote:
>> Entertaining in a weird way.
> Yes, very weird. And verbose. And a bit tedious.
I guess I was in a case of this: http://xkcd.com/386/.
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, Ars Machina Tecnologia da Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: HybridJava vs. Tapestry
Posted by Josh Canfield <jo...@gmail.com>.
> Entertaining in a weird way.
Yes, very weird. And verbose. And a bit tedious.
On Wed, Mar 16, 2011 at 1:38 AM, Inge Solvoll <in...@gmail.com> wrote:
> Entertaining in a weird way.
>
> On Wed, Mar 16, 2011 at 6:19 AM, Howard Lewis Ship <hl...@gmail.com> wrote:
>
>> Is this "discussion" serving any purpose?
>>
>> On Tue, Mar 15, 2011 at 9:23 PM, AlexSerov <Hy...@gmail.com>
>> wrote:
>> > Hi!
>> >
>> > Apparently due to my mistake with formatting you could not read most
>> > part of my mail. I have resubmitted later.
>> >
>> >> What you described is not correct to Tapestry page rendering. The DOM is
>> >> recursive, but it's rendering is not.
>> >
>> > That is beyond my understanding, but I assume that is not urgent.
>> >
>> >> The component state is independent from the page.
>> > Anyway that is a separate object.
>> >
>> >>> Each component entry in this case must have a separate class
>> >>> instance to keep that state.
>> >>
>> >> Correct.
>> >>
>> >>> Different for different users.
>> >
>> > I mean that there are different state object for different users,
>> > which is probabaly trivial.
>> >
>> >> Wrong. From a Howard blog post:
>> >>
>> >> "Tapestry 5.2 rewrites the rules here; only a single page tree is now
>> >> needed for each page; the page and component classes have an extra
>> >> transformation step that moves per-request data out of the objects
>> >> themselves and into a per-thread Map object. Now, any number of requests
>> >> can operate at the same time, without requiring additional page
>> instances.
>> >> Even better, the old page pooling mechanism included some locking and
>> >> blocking that also gets jettisoned in the new approach. It's just a big
>> >> win all around."
>> >
>> > Nothing to discuss if page is something independant from page state.
>> > Reparing you own mistakes made at design time is a know way of moving
>> > forward (big win). Compared to HybridJava that is about terminology.
>> > In HybridJava one page instance is created per user. The state (of
>> > course user-specific) is kept in that instance (so once one gets back
>> > to the same page the previous state is by default still there). The
>> > handler and renederer are static methods of same class, so there is no
>> > direct analogy to what page is in instance. No DOM at all in
>> > HybridJava, but of course, as you've explained DOM of the page is
>> > build once that is fine.
>> >
>> >> In Tapestry 5.2, it's just a matter of not using the same per-thread Map
>> >> instance again.
>> >
>> > I bet instances of Map are pretty redundant. By the way - recently got
>> > to know that Play does not use Servlet inside - what about tapestry?
>> >
>> > ... seems you were not able to read starting from here ...
>> >
>> >>> Not sure what it does with instances of components. Seems like that
>> means
>> >>> that before each rendering (absolutely so when a different user hits)
>> the
>> >>> page with the component tree should be restored. As someone noticed it
>> is
>> >>> not 2000 now ans pooling objects is consigered by many as beeng spower
>> >>> than
>> >>> recreating by "new" with garbage collection. I asked not about
>> rendering,
>> >>> but about run-time of one page. I have a feeling that Tapestry has to
>> >>> recreate (or re-obtain - does not matter) all the instances of
>> components
>> >>> anew?
>> >>>
>> >>>>> Finally - the user actions are passed in the form of "events" (so I
>> >>>>> read). Does this process also imply creating some objects at Java
>> >>>>> run-time?
>> >>>
>> >>>> Just the object containing the event context parameters, and just if
>> the
>> >>> event handler method has a List or EventContext object.
>> >>>
>> >>> That may be not a huge advantage, but HybridJava solves this task
>> without
>> >>> any objects.
>> >>>
>> >>>>> As a matter of fact HybridJava creates only one class instance that
>> >>>>> carries the page model values and at the same time has the both the
>> >>>>> render and handle methods on it. Regardless of the number of buttons
>> >>>>> and
>> >>>>> text fields.
>> >>>
>> >>>> Same as Tapestry in this respect.
>> >>> This does not match to what you told right above: "object containing"
>> us
>> >>> an
>> >>> object, List is an object. Are "context parameters" and "EventContext
>> >>> object" objects as well?
>> >>>
>> >>>>> These measurements only have significance if they implement exactly
>> the
>> >>> same application or use cases.
>> >>> That is what I say. If you do not like my tests do give me yours.
>> >>>
>> >>>>> SO, what about you choose a test that I implement using HybridJava
>> (you
>> >>>>> most probably already have that test implemented using Tapestry) and
>> I
>> >>>>> send you my test that you implement using Tapestry. That is a way
>> that
>> >>>>> will require minimum effort from anybody and the only practical.
>> >>>
>> >>>> Ok!
>> >>>
>> >>> Looking forward. If fact each of us already has tests implemented by
>> his
>> >>> own
>> >>> framework.
>> >>>
>> >>>> I didn't say it was enough. I just cited one comparison
>> >>> It is not enough because such researches are absolutely rare, not
>> because
>> >>> you said "enough".
>> >>>
>> >>>>> What matters is that it is a kind of redundant mechanism. I
>> understand
>> >>>>> that at some point it was borrowed from PHP.
>> >>>
>> >>>> It wasn't. And what do you mean by redundant?
>> >>>
>> >>> That means exactly that if you cut it off the documentation and from
>> >>> implementation as well Tapestry will be same usable as before.
>> >>>
>> >>>> doesn't couple components. Tapestry's philosophy is to have the least
>> >>>> coupling possible.
>> >>> I am not strong in philosophy. There is no framework that does not
>> claim
>> >>> that it's philosophy isn't about minimization of coupling between
>> >>> components
>> >>> (on of which is the page).
>> >>>
>> >>> Here is a concrete example: suppose we have a component like chat. It
>> has
>> >>> its own buttons and text fields and does not depend on anything at all.
>> >>> On
>> >>> that page you probably have a component that defines the nice
>> surrounding
>> >>> common for all pages and a hole in the middle that you want to fill
>> with
>> >>> a
>> >>> content. Suppose I want to put there 2 chat components.
>> >>>
>> >>> In HybridJava that will look like: . And that is it. No other
>> >>> configuration
>> >>> or mentioning the chat component in the some java code. The only
>> >>> coupling of
>> >>> the complnents here is their positioning on the page and one relative
>> to
>> >>> another which is all solved by the means of mark-up and which seem
>> being
>> >>> minimal possible. And you may chat with two friends in parallel.
>> >>>
>> >>> How would similar example look in Tapestry? I ask because I did not go
>> >>> into
>> >>> Tapestry that deep yet.
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> View this message in context:
>> >>>
>> >>>
>> http://tapestry.1045711.n5.nabble.com/Re-HybridJava-vs-Tapestry-tp3555989p3751648.html
>> >>> Sent from the Tapestry - Dev mailing list archive at Nabble.com.
>> >>>
>> >>> ---------------------------------------------------------------------
>> >>> To unsubscribe, e-mail: [hidden email]
>> >>> For additional commands, e-mail: [hidden email]
>> >>>
>> >>
>> >> --
>> >> Thiago H. de Paula Figueiredo
>> >> Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
>> >> and instructor
>> >> Owner, Ars Machina Tecnologia da Informação Ltda.
>> >> Consultor, desenvolvedor e instrutor em Java, Tapestry e Hibernate
>> >> Coordenador e professor da Especialização em Engenharia de Software com
>> >> Ênfase em Java da Faculdade Pitágoras
>> >> http://www.arsmachina.com.br
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: [hidden email]
>> >> For additional commands, e-mail: [hidden email]
>> >>
>> >>
>> >>
>> >> ________________________________
>> >> If you reply to this email, your message will be added to the discussion
>> >> below:
>> >>
>> http://tapestry.1045711.n5.nabble.com/Re-HybridJava-vs-Tapestry-tp3555989p3753159.html
>> >> To unsubscribe from Re: HybridJava vs. Tapestry, click here.
>> >
>> >
>> > --
>> > View this message in context:
>> http://tapestry.1045711.n5.nabble.com/Re-HybridJava-vs-Tapestry-tp3555989p3756578.html
>> > Sent from the Tapestry - Dev mailing list archive at Nabble.com.
>>
>>
>>
>> --
>> 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: dev-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: HybridJava vs. Tapestry
Posted by Inge Solvoll <in...@gmail.com>.
Entertaining in a weird way.
On Wed, Mar 16, 2011 at 6:19 AM, Howard Lewis Ship <hl...@gmail.com> wrote:
> Is this "discussion" serving any purpose?
>
> On Tue, Mar 15, 2011 at 9:23 PM, AlexSerov <Hy...@gmail.com>
> wrote:
> > Hi!
> >
> > Apparently due to my mistake with formatting you could not read most
> > part of my mail. I have resubmitted later.
> >
> >> What you described is not correct to Tapestry page rendering. The DOM is
> >> recursive, but it's rendering is not.
> >
> > That is beyond my understanding, but I assume that is not urgent.
> >
> >> The component state is independent from the page.
> > Anyway that is a separate object.
> >
> >>> Each component entry in this case must have a separate class
> >>> instance to keep that state.
> >>
> >> Correct.
> >>
> >>> Different for different users.
> >
> > I mean that there are different state object for different users,
> > which is probabaly trivial.
> >
> >> Wrong. From a Howard blog post:
> >>
> >> "Tapestry 5.2 rewrites the rules here; only a single page tree is now
> >> needed for each page; the page and component classes have an extra
> >> transformation step that moves per-request data out of the objects
> >> themselves and into a per-thread Map object. Now, any number of requests
> >> can operate at the same time, without requiring additional page
> instances.
> >> Even better, the old page pooling mechanism included some locking and
> >> blocking that also gets jettisoned in the new approach. It's just a big
> >> win all around."
> >
> > Nothing to discuss if page is something independant from page state.
> > Reparing you own mistakes made at design time is a know way of moving
> > forward (big win). Compared to HybridJava that is about terminology.
> > In HybridJava one page instance is created per user. The state (of
> > course user-specific) is kept in that instance (so once one gets back
> > to the same page the previous state is by default still there). The
> > handler and renederer are static methods of same class, so there is no
> > direct analogy to what page is in instance. No DOM at all in
> > HybridJava, but of course, as you've explained DOM of the page is
> > build once that is fine.
> >
> >> In Tapestry 5.2, it's just a matter of not using the same per-thread Map
> >> instance again.
> >
> > I bet instances of Map are pretty redundant. By the way - recently got
> > to know that Play does not use Servlet inside - what about tapestry?
> >
> > ... seems you were not able to read starting from here ...
> >
> >>> Not sure what it does with instances of components. Seems like that
> means
> >>> that before each rendering (absolutely so when a different user hits)
> the
> >>> page with the component tree should be restored. As someone noticed it
> is
> >>> not 2000 now ans pooling objects is consigered by many as beeng spower
> >>> than
> >>> recreating by "new" with garbage collection. I asked not about
> rendering,
> >>> but about run-time of one page. I have a feeling that Tapestry has to
> >>> recreate (or re-obtain - does not matter) all the instances of
> components
> >>> anew?
> >>>
> >>>>> Finally - the user actions are passed in the form of "events" (so I
> >>>>> read). Does this process also imply creating some objects at Java
> >>>>> run-time?
> >>>
> >>>> Just the object containing the event context parameters, and just if
> the
> >>> event handler method has a List or EventContext object.
> >>>
> >>> That may be not a huge advantage, but HybridJava solves this task
> without
> >>> any objects.
> >>>
> >>>>> As a matter of fact HybridJava creates only one class instance that
> >>>>> carries the page model values and at the same time has the both the
> >>>>> render and handle methods on it. Regardless of the number of buttons
> >>>>> and
> >>>>> text fields.
> >>>
> >>>> Same as Tapestry in this respect.
> >>> This does not match to what you told right above: "object containing"
> us
> >>> an
> >>> object, List is an object. Are "context parameters" and "EventContext
> >>> object" objects as well?
> >>>
> >>>>> These measurements only have significance if they implement exactly
> the
> >>> same application or use cases.
> >>> That is what I say. If you do not like my tests do give me yours.
> >>>
> >>>>> SO, what about you choose a test that I implement using HybridJava
> (you
> >>>>> most probably already have that test implemented using Tapestry) and
> I
> >>>>> send you my test that you implement using Tapestry. That is a way
> that
> >>>>> will require minimum effort from anybody and the only practical.
> >>>
> >>>> Ok!
> >>>
> >>> Looking forward. If fact each of us already has tests implemented by
> his
> >>> own
> >>> framework.
> >>>
> >>>> I didn't say it was enough. I just cited one comparison
> >>> It is not enough because such researches are absolutely rare, not
> because
> >>> you said "enough".
> >>>
> >>>>> What matters is that it is a kind of redundant mechanism. I
> understand
> >>>>> that at some point it was borrowed from PHP.
> >>>
> >>>> It wasn't. And what do you mean by redundant?
> >>>
> >>> That means exactly that if you cut it off the documentation and from
> >>> implementation as well Tapestry will be same usable as before.
> >>>
> >>>> doesn't couple components. Tapestry's philosophy is to have the least
> >>>> coupling possible.
> >>> I am not strong in philosophy. There is no framework that does not
> claim
> >>> that it's philosophy isn't about minimization of coupling between
> >>> components
> >>> (on of which is the page).
> >>>
> >>> Here is a concrete example: suppose we have a component like chat. It
> has
> >>> its own buttons and text fields and does not depend on anything at all.
> >>> On
> >>> that page you probably have a component that defines the nice
> surrounding
> >>> common for all pages and a hole in the middle that you want to fill
> with
> >>> a
> >>> content. Suppose I want to put there 2 chat components.
> >>>
> >>> In HybridJava that will look like: . And that is it. No other
> >>> configuration
> >>> or mentioning the chat component in the some java code. The only
> >>> coupling of
> >>> the complnents here is their positioning on the page and one relative
> to
> >>> another which is all solved by the means of mark-up and which seem
> being
> >>> minimal possible. And you may chat with two friends in parallel.
> >>>
> >>> How would similar example look in Tapestry? I ask because I did not go
> >>> into
> >>> Tapestry that deep yet.
> >>>
> >>>
> >>>
> >>> --
> >>> View this message in context:
> >>>
> >>>
> http://tapestry.1045711.n5.nabble.com/Re-HybridJava-vs-Tapestry-tp3555989p3751648.html
> >>> Sent from the Tapestry - Dev mailing list archive at Nabble.com.
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: [hidden email]
> >>> For additional commands, e-mail: [hidden email]
> >>>
> >>
> >> --
> >> Thiago H. de Paula Figueiredo
> >> Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
> >> and instructor
> >> Owner, Ars Machina Tecnologia da Informação Ltda.
> >> Consultor, desenvolvedor e instrutor em Java, Tapestry e Hibernate
> >> Coordenador e professor da Especialização em Engenharia de Software com
> >> Ênfase em Java da Faculdade Pitágoras
> >> http://www.arsmachina.com.br
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [hidden email]
> >> For additional commands, e-mail: [hidden email]
> >>
> >>
> >>
> >> ________________________________
> >> If you reply to this email, your message will be added to the discussion
> >> below:
> >>
> http://tapestry.1045711.n5.nabble.com/Re-HybridJava-vs-Tapestry-tp3555989p3753159.html
> >> To unsubscribe from Re: HybridJava vs. Tapestry, click here.
> >
> >
> > --
> > View this message in context:
> http://tapestry.1045711.n5.nabble.com/Re-HybridJava-vs-Tapestry-tp3555989p3756578.html
> > Sent from the Tapestry - Dev mailing list archive at Nabble.com.
>
>
>
> --
> 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: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
Re: HybridJava vs. Tapestry
Posted by Howard Lewis Ship <hl...@gmail.com>.
Is this "discussion" serving any purpose?
On Tue, Mar 15, 2011 at 9:23 PM, AlexSerov <Hy...@gmail.com> wrote:
> Hi!
>
> Apparently due to my mistake with formatting you could not read most
> part of my mail. I have resubmitted later.
>
>> What you described is not correct to Tapestry page rendering. The DOM is
>> recursive, but it's rendering is not.
>
> That is beyond my understanding, but I assume that is not urgent.
>
>> The component state is independent from the page.
> Anyway that is a separate object.
>
>>> Each component entry in this case must have a separate class
>>> instance to keep that state.
>>
>> Correct.
>>
>>> Different for different users.
>
> I mean that there are different state object for different users,
> which is probabaly trivial.
>
>> Wrong. From a Howard blog post:
>>
>> "Tapestry 5.2 rewrites the rules here; only a single page tree is now
>> needed for each page; the page and component classes have an extra
>> transformation step that moves per-request data out of the objects
>> themselves and into a per-thread Map object. Now, any number of requests
>> can operate at the same time, without requiring additional page instances.
>> Even better, the old page pooling mechanism included some locking and
>> blocking that also gets jettisoned in the new approach. It's just a big
>> win all around."
>
> Nothing to discuss if page is something independant from page state.
> Reparing you own mistakes made at design time is a know way of moving
> forward (big win). Compared to HybridJava that is about terminology.
> In HybridJava one page instance is created per user. The state (of
> course user-specific) is kept in that instance (so once one gets back
> to the same page the previous state is by default still there). The
> handler and renederer are static methods of same class, so there is no
> direct analogy to what page is in instance. No DOM at all in
> HybridJava, but of course, as you've explained DOM of the page is
> build once that is fine.
>
>> In Tapestry 5.2, it's just a matter of not using the same per-thread Map
>> instance again.
>
> I bet instances of Map are pretty redundant. By the way - recently got
> to know that Play does not use Servlet inside - what about tapestry?
>
> ... seems you were not able to read starting from here ...
>
>>> Not sure what it does with instances of components. Seems like that means
>>> that before each rendering (absolutely so when a different user hits) the
>>> page with the component tree should be restored. As someone noticed it is
>>> not 2000 now ans pooling objects is consigered by many as beeng spower
>>> than
>>> recreating by "new" with garbage collection. I asked not about rendering,
>>> but about run-time of one page. I have a feeling that Tapestry has to
>>> recreate (or re-obtain - does not matter) all the instances of components
>>> anew?
>>>
>>>>> Finally - the user actions are passed in the form of "events" (so I
>>>>> read). Does this process also imply creating some objects at Java
>>>>> run-time?
>>>
>>>> Just the object containing the event context parameters, and just if the
>>> event handler method has a List or EventContext object.
>>>
>>> That may be not a huge advantage, but HybridJava solves this task without
>>> any objects.
>>>
>>>>> As a matter of fact HybridJava creates only one class instance that
>>>>> carries the page model values and at the same time has the both the
>>>>> render and handle methods on it. Regardless of the number of buttons
>>>>> and
>>>>> text fields.
>>>
>>>> Same as Tapestry in this respect.
>>> This does not match to what you told right above: "object containing" us
>>> an
>>> object, List is an object. Are "context parameters" and "EventContext
>>> object" objects as well?
>>>
>>>>> These measurements only have significance if they implement exactly the
>>> same application or use cases.
>>> That is what I say. If you do not like my tests do give me yours.
>>>
>>>>> SO, what about you choose a test that I implement using HybridJava (you
>>>>> most probably already have that test implemented using Tapestry) and I
>>>>> send you my test that you implement using Tapestry. That is a way that
>>>>> will require minimum effort from anybody and the only practical.
>>>
>>>> Ok!
>>>
>>> Looking forward. If fact each of us already has tests implemented by his
>>> own
>>> framework.
>>>
>>>> I didn't say it was enough. I just cited one comparison
>>> It is not enough because such researches are absolutely rare, not because
>>> you said "enough".
>>>
>>>>> What matters is that it is a kind of redundant mechanism. I understand
>>>>> that at some point it was borrowed from PHP.
>>>
>>>> It wasn't. And what do you mean by redundant?
>>>
>>> That means exactly that if you cut it off the documentation and from
>>> implementation as well Tapestry will be same usable as before.
>>>
>>>> doesn't couple components. Tapestry's philosophy is to have the least
>>>> coupling possible.
>>> I am not strong in philosophy. There is no framework that does not claim
>>> that it's philosophy isn't about minimization of coupling between
>>> components
>>> (on of which is the page).
>>>
>>> Here is a concrete example: suppose we have a component like chat. It has
>>> its own buttons and text fields and does not depend on anything at all.
>>> On
>>> that page you probably have a component that defines the nice surrounding
>>> common for all pages and a hole in the middle that you want to fill with
>>> a
>>> content. Suppose I want to put there 2 chat components.
>>>
>>> In HybridJava that will look like: . And that is it. No other
>>> configuration
>>> or mentioning the chat component in the some java code. The only
>>> coupling of
>>> the complnents here is their positioning on the page and one relative to
>>> another which is all solved by the means of mark-up and which seem being
>>> minimal possible. And you may chat with two friends in parallel.
>>>
>>> How would similar example look in Tapestry? I ask because I did not go
>>> into
>>> Tapestry that deep yet.
>>>
>>>
>>>
>>> --
>>> View this message in context:
>>>
>>> http://tapestry.1045711.n5.nabble.com/Re-HybridJava-vs-Tapestry-tp3555989p3751648.html
>>> Sent from the Tapestry - Dev mailing list archive at Nabble.com.
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>
>> --
>> Thiago H. de Paula Figueiredo
>> Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
>> and instructor
>> Owner, Ars Machina Tecnologia da Informação Ltda.
>> Consultor, desenvolvedor e instrutor em Java, Tapestry e Hibernate
>> Coordenador e professor da Especialização em Engenharia de Software com
>> Ênfase em Java da Faculdade Pitágoras
>> http://www.arsmachina.com.br
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>>
>> ________________________________
>> If you reply to this email, your message will be added to the discussion
>> below:
>> http://tapestry.1045711.n5.nabble.com/Re-HybridJava-vs-Tapestry-tp3555989p3753159.html
>> To unsubscribe from Re: HybridJava vs. Tapestry, click here.
>
>
> --
> View this message in context: http://tapestry.1045711.n5.nabble.com/Re-HybridJava-vs-Tapestry-tp3555989p3756578.html
> Sent from the Tapestry - Dev mailing list archive at Nabble.com.
--
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: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: HybridJava vs. Tapestry
Posted by AlexSerov <Hy...@gmail.com>.
Hi!
Apparently due to my mistake with formatting you could not read most
part of my mail. I have resubmitted later.
> What you described is not correct to Tapestry page rendering. The DOM is
> recursive, but it's rendering is not.
That is beyond my understanding, but I assume that is not urgent.
> The component state is independent from the page.
Anyway that is a separate object.
>> Each component entry in this case must have a separate class
>> instance to keep that state.
>
> Correct.
>
>> Different for different users.
I mean that there are different state object for different users,
which is probabaly trivial.
> Wrong. From a Howard blog post:
>
> "Tapestry 5.2 rewrites the rules here; only a single page tree is now
> needed for each page; the page and component classes have an extra
> transformation step that moves per-request data out of the objects
> themselves and into a per-thread Map object. Now, any number of requests
> can operate at the same time, without requiring additional page instances.
> Even better, the old page pooling mechanism included some locking and
> blocking that also gets jettisoned in the new approach. It's just a big
> win all around."
Nothing to discuss if page is something independant from page state.
Reparing you own mistakes made at design time is a know way of moving
forward (big win). Compared to HybridJava that is about terminology.
In HybridJava one page instance is created per user. The state (of
course user-specific) is kept in that instance (so once one gets back
to the same page the previous state is by default still there). The
handler and renederer are static methods of same class, so there is no
direct analogy to what page is in instance. No DOM at all in
HybridJava, but of course, as you've explained DOM of the page is
build once that is fine.
> In Tapestry 5.2, it's just a matter of not using the same per-thread Map
> instance again.
I bet instances of Map are pretty redundant. By the way - recently got
to know that Play does not use Servlet inside - what about tapestry?
... seems you were not able to read starting from here ...
>> Not sure what it does with instances of components. Seems like that means
>> that before each rendering (absolutely so when a different user hits) the
>> page with the component tree should be restored. As someone noticed it is
>> not 2000 now ans pooling objects is consigered by many as beeng spower
>> than
>> recreating by "new" with garbage collection. I asked not about rendering,
>> but about run-time of one page. I have a feeling that Tapestry has to
>> recreate (or re-obtain - does not matter) all the instances of components
>> anew?
>>
>>>> Finally - the user actions are passed in the form of "events" (so I
>>>> read). Does this process also imply creating some objects at Java
>>>> run-time?
>>
>>> Just the object containing the event context parameters, and just if the
>> event handler method has a List or EventContext object.
>>
>> That may be not a huge advantage, but HybridJava solves this task without
>> any objects.
>>
>>>> As a matter of fact HybridJava creates only one class instance that
>>>> carries the page model values and at the same time has the both the
>>>> render and handle methods on it. Regardless of the number of buttons
>>>> and
>>>> text fields.
>>
>>> Same as Tapestry in this respect.
>> This does not match to what you told right above: "object containing" us
>> an
>> object, List is an object. Are "context parameters" and "EventContext
>> object" objects as well?
>>
>>>> These measurements only have significance if they implement exactly the
>> same application or use cases.
>> That is what I say. If you do not like my tests do give me yours.
>>
>>>> SO, what about you choose a test that I implement using HybridJava (you
>>>> most probably already have that test implemented using Tapestry) and I
>>>> send you my test that you implement using Tapestry. That is a way that
>>>> will require minimum effort from anybody and the only practical.
>>
>>> Ok!
>>
>> Looking forward. If fact each of us already has tests implemented by his
>> own
>> framework.
>>
>>> I didn't say it was enough. I just cited one comparison
>> It is not enough because such researches are absolutely rare, not because
>> you said "enough".
>>
>>>> What matters is that it is a kind of redundant mechanism. I understand
>>>> that at some point it was borrowed from PHP.
>>
>>> It wasn't. And what do you mean by redundant?
>>
>> That means exactly that if you cut it off the documentation and from
>> implementation as well Tapestry will be same usable as before.
>>
>>> doesn't couple components. Tapestry's philosophy is to have the least
>>> coupling possible.
>> I am not strong in philosophy. There is no framework that does not claim
>> that it's philosophy isn't about minimization of coupling between
>> components
>> (on of which is the page).
>>
>> Here is a concrete example: suppose we have a component like chat. It has
>> its own buttons and text fields and does not depend on anything at all.
>> On
>> that page you probably have a component that defines the nice surrounding
>> common for all pages and a hole in the middle that you want to fill with
>> a
>> content. Suppose I want to put there 2 chat components.
>>
>> In HybridJava that will look like: . And that is it. No other
>> configuration
>> or mentioning the chat component in the some java code. The only
>> coupling of
>> the complnents here is their positioning on the page and one relative to
>> another which is all solved by the means of mark-up and which seem being
>> minimal possible. And you may chat with two friends in parallel.
>>
>> How would similar example look in Tapestry? I ask because I did not go
>> into
>> Tapestry that deep yet.
>>
>>
>>
>> --
>> View this message in context:
>>
>> http://tapestry.1045711.n5.nabble.com/Re-HybridJava-vs-Tapestry-tp3555989p3751648.html
>> Sent from the Tapestry - Dev mailing list archive at Nabble.com.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
> --
> Thiago H. de Paula Figueiredo
> Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
> and instructor
> Owner, Ars Machina Tecnologia da Informação Ltda.
> Consultor, desenvolvedor e instrutor em Java, Tapestry e Hibernate
> Coordenador e professor da Especialização em Engenharia de Software com
> Ênfase em Java da Faculdade Pitágoras
> http://www.arsmachina.com.br
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
>
> ________________________________
> If you reply to this email, your message will be added to the discussion
> below:
> http://tapestry.1045711.n5.nabble.com/Re-HybridJava-vs-Tapestry-tp3555989p3753159.html
> To unsubscribe from Re: HybridJava vs. Tapestry, click here.
--
View this message in context: http://tapestry.1045711.n5.nabble.com/Re-HybridJava-vs-Tapestry-tp3555989p3756578.html
Sent from the Tapestry - Dev mailing list archive at Nabble.com.
Re: HybridJava vs. Tapestry
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
On Tue, 15 Mar 2011 23:57:25 -0300, AlexSerov
<Hy...@gmail.com> wrote:
>> Less memory usage due to not use recursion. Less deep stack traces too.
>> :)
>
> Oh no! The depth of the stack trace is defined by the page you want to
> build. Weather you use recursion or not does not change that. If the page
> implies presenting five levels that will be five leveles regardless.
What you described is not correct to Tapestry page rendering. The DOM is
recursive, but it's rendering is not.
> That is not that simple. Both to answer and to ask. If a component in
> Tapestry is what I think then I suppose it has a state independent from
> that of the page.
The component state is independent from the page.
> Each component entry in this case must have a separate class
> instance to keep that state.
Correct.
> Different for different users.
Wrong. From a Howard blog post:
"Tapestry 5.2 rewrites the rules here; only a single page tree is now
needed for each page; the page and component classes have an extra
transformation step that moves per-request data out of the objects
themselves and into a per-thread Map object. Now, any number of requests
can operate at the same time, without requiring additional page instances.
Even better, the old page pooling mechanism included some locking and
blocking that also gets jettisoned in the new approach. It's just a big
win all around."
> I've read that Tapestry cleans the object corresponding to a page after
> rendering is over.
In Tapestry 5.2, it's just a matter of not using the same per-thread Map
instance again.
> Not sure what it does with instances of components. Seems like that means
> that before each rendering (absolutely so when a different user hits) the
> page with the component tree should be restored. As someone noticed it is
> not 2000 now ans pooling objects is consigered by many as beeng spower
> than
> recreating by "new" with garbage collection. I asked not about rendering,
> but about run-time of one page. I have a feeling that Tapestry has to
> recreate (or re-obtain - does not matter) all the instances of components
> anew?
>
>>> Finally - the user actions are passed in the form of "events" (so I
>>> read). Does this process also imply creating some objects at Java
>>> run-time?
>
>> Just the object containing the event context parameters, and just if the
> event handler method has a List or EventContext object.
>
> That may be not a huge advantage, but HybridJava solves this task without
> any objects.
>
>>> As a matter of fact HybridJava creates only one class instance that
>>> carries the page model values and at the same time has the both the
>>> render and handle methods on it. Regardless of the number of buttons
>>> and
>>> text fields.
>
>> Same as Tapestry in this respect.
> This does not match to what you told right above: "object containing" us
> an
> object, List is an object. Are "context parameters" and "EventContext
> object" objects as well?
>
>>> These measurements only have significance if they implement exactly the
> same application or use cases.
> That is what I say. If you do not like my tests do give me yours.
>
>>> SO, what about you choose a test that I implement using HybridJava (you
>>> most probably already have that test implemented using Tapestry) and I
>>> send you my test that you implement using Tapestry. That is a way that
>>> will require minimum effort from anybody and the only practical.
>
>> Ok!
>
> Looking forward. If fact each of us already has tests implemented by his
> own
> framework.
>
>> I didn't say it was enough. I just cited one comparison
> It is not enough because such researches are absolutely rare, not because
> you said "enough".
>
>>> What matters is that it is a kind of redundant mechanism. I understand
>>> that at some point it was borrowed from PHP.
>
>> It wasn't. And what do you mean by redundant?
>
> That means exactly that if you cut it off the documentation and from
> implementation as well Tapestry will be same usable as before.
>
>> doesn't couple components. Tapestry's philosophy is to have the least
>> coupling possible.
> I am not strong in philosophy. There is no framework that does not claim
> that it's philosophy isn't about minimization of coupling between
> components
> (on of which is the page).
>
> Here is a concrete example: suppose we have a component like chat. It has
> its own buttons and text fields and does not depend on anything at all.
> On
> that page you probably have a component that defines the nice surrounding
> common for all pages and a hole in the middle that you want to fill with
> a
> content. Suppose I want to put there 2 chat components.
>
> In HybridJava that will look like: . And that is it. No other
> configuration
> or mentioning the chat component in the some java code. The only
> coupling of
> the complnents here is their positioning on the page and one relative to
> another which is all solved by the means of mark-up and which seem being
> minimal possible. And you may chat with two friends in parallel.
>
> How would similar example look in Tapestry? I ask because I did not go
> into
> Tapestry that deep yet.
>
>
>
> --
> View this message in context:
> http://tapestry.1045711.n5.nabble.com/Re-HybridJava-vs-Tapestry-tp3555989p3751648.html
> Sent from the Tapestry - Dev mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, Ars Machina Tecnologia da Informação Ltda.
Consultor, desenvolvedor e instrutor em Java, Tapestry e Hibernate
Coordenador e professor da Especialização em Engenharia de Software com
Ênfase em Java da Faculdade Pitágoras
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: HybridJava vs. Tapestry
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Oops, I hit the send button too soon.
On Tue, 15 Mar 2011 23:57:25 -0300, AlexSerov
<Hy...@gmail.com> wrote:
>> Less memory usage due to not use recursion. Less deep stack traces too.
>> :)
>
> Oh no! The depth of the stack trace is defined by the page you want to
> build. Weather you use recursion or not does not change that. If the page
> implies presenting five levels that will be five leveles regardless.
What you described is not correct to Tapestry page rendering. The DOM is
recursive, but it's rendering is not.
> That is not that simple. Both to answer and to ask. If a component in
> Tapestry is what I think then I suppose it has a state independent from
> that of the page.
The component state is independent from the page.
> Each component entry in this case must have a separate class
> instance to keep that state.
Correct.
> Different for different users.
Wrong. From a Howard blog post:
"Tapestry 5.2 rewrites the rules here; only a single page tree is now
needed for each page; the page and component classes have an extra
transformation step that moves per-request data out of the objects
themselves and into a per-thread Map object. Now, any number of requests
can operate at the same time, without requiring additional page instances.
Even better, the old page pooling mechanism included some locking and
blocking that also gets jettisoned in the new approach. It's just a big
win all around."
> I've read that Tapestry cleans the object corresponding to a page after
> rendering is over.
In Tapestry 5.2, it's just a matter of not using the same per-thread Map
instance again.
> Not sure what it does with instances of components. Seems like that means
> that before each rendering (absolutely so when a different user hits) the
> page with the component tree should be restored.
Tapestry doesn't store the component tree state anywhere. See my comment
above.
> As someone noticed it is
> not 2000 now ans pooling objects is consigered by many as beeng spower
> than recreating by "new" with garbage collection. I asked not about
> rendering,
> but about run-time of one page.
Eache page class has exactly one instance for the whole application and
all users. The state of this object is independent between threads.
Period. Don't forget that Tapestry transforms page classes during
classloading.
> I have a feeling that Tapestry has to
> recreate (or re-obtain - does not matter) all the instances of components
> anew?
It doesn't.
>>> Finally - the user actions are passed in the form of "events" (so I
>>> read). Does this process also imply creating some objects at Java
>>> run-time?
>
>> Just the object containing the event context parameters, and just if the
> event handler method has a List or EventContext object.
>
> That may be not a huge advantage, but HybridJava solves this task without
> any objects.
It's just one very simple object, so it's a very small difference.
>>> As a matter of fact HybridJava creates only one class instance that
>>> carries the page model values and at the same time has the both the
>>> render and handle methods on it. Regardless of the number of buttons
>>> and text fields.
>
>> Same as Tapestry in this respect.
> This does not match to what you told right above: "object containing" us
> an object, List is an object. Are "context parameters" and "EventContext
> object" objects as well?
Yes, and that doesn't contradict what I was saying. Context parameters are
normal parameters.
> Here is a concrete example: suppose we have a component like chat. It has
> its own buttons and text fields and does not depend on anything at all.
> On that page you probably have a component that defines the nice
> surrounding
> common for all pages and a hole in the middle that you want to fill with
> a content. Suppose I want to put there 2 chat components.
>
> In HybridJava that will look like: . And that is it. No other
> configuration or mentioning the chat component in the some java code.
Same as Tapestry.
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, Ars Machina Tecnologia da Informação Ltda.
Consultor, desenvolvedor e instrutor em Java, Tapestry e Hibernate
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: HybridJava vs. Tapestry
Posted by AlexSerov <Hy...@gmail.com>.
> Less memory usage due to not use recursion. Less deep stack traces too. :)
Oh no! The depth of the stack trace is defined by the page you want to
build. Weather you use recursion or not does not change that. If the page
implies presenting five levels that will be five leveles regardless.
> Someone said that you shouldn't look at a JSF one if you have vertigo. :P
Most unfortunately I have already looked at JSF, though 2.0.
>> From Tapestry site I have also concluded that things like buttons and
>> text fields are components and thus imply using instances. Are these ones
>> created at page run-time or not?
>Absolutely no. There's a single instance for each page class with all the
component tree pre-instantiated. A page render is just rendering the page
and its components.
That is not that simple. Both to answer and to ask. If a component in
Tapestry is what I think then I suppose it has a state independent from that
of the page. Each component entry in this case must have a separate class
instance to keep that state. Different for different users. I've read that
Tapestry cleans the object corresponding to a page after rendering is over.
Not sure what it does with instances of components. Seems like that means
that before each rendering (absolutely so when a different user hits) the
page with the component tree should be restored. As someone noticed it is
not 2000 now ans pooling objects is consigered by many as beeng spower than
recreating by "new" with garbage collection. I asked not about rendering,
but about run-time of one page. I have a feeling that Tapestry has to
recreate (or re-obtain - does not matter) all the instances of components
anew?
>> Finally - the user actions are passed in the form of "events" (so I
>> read). Does this process also imply creating some objects at Java
>> run-time?
>Just the object containing the event context parameters, and just if the
event handler method has a List or EventContext object.
That may be not a huge advantage, but HybridJava solves this task without
any objects.
>> As a matter of fact HybridJava creates only one class instance that
>> carries the page model values and at the same time has the both the
>> render and handle methods on it. Regardless of the number of buttons and
>> text fields.
>Same as Tapestry in this respect.
This does not match to what you told right above: "object containing" us an
object, List is an object. Are "context parameters" and "EventContext
object" objects as well?
>>These measurements only have significance if they implement exactly the
same application or use cases.
That is what I say. If you do not like my tests do give me yours.
>> SO, what about you choose a test that I implement using HybridJava (you
>> most probably already have that test implemented using Tapestry) and I
>> send you my test that you implement using Tapestry. That is a way that
>> will require minimum effort from anybody and the only practical.
>Ok!
Looking forward. If fact each of us already has tests implemented by his own
framework.
>I didn't say it was enough. I just cited one comparison
It is not enough because such researches are absolutely rare, not because
you said "enough".
>> What matters is that it is a kind of redundant mechanism. I understand
>> that at some point it was borrowed from PHP.
>It wasn't. And what do you mean by redundant?
That means exactly that if you cut it off the documentation and from
implementation as well Tapestry will be same usable as before.
> doesn't couple components. Tapestry's philosophy is to have the least
> coupling possible.
I am not strong in philosophy. There is no framework that does not claim
that it's philosophy isn't about minimization of coupling between components
(on of which is the page).
Here is a concrete example: suppose we have a component like chat. It has
its own buttons and text fields and does not depend on anything at all. On
that page you probably have a component that defines the nice surrounding
common for all pages and a hole in the middle that you want to fill with a
content. Suppose I want to put there 2 chat components.
In HybridJava that will look like: . And that is it. No other configuration
or mentioning the chat component in the some java code. The only coupling of
the complnents here is their positioning on the page and one relative to
another which is all solved by the means of mark-up and which seem being
minimal possible. And you may chat with two friends in parallel.
How would similar example look in Tapestry? I ask because I did not go into
Tapestry that deep yet.
--
View this message in context: http://tapestry.1045711.n5.nabble.com/Re-HybridJava-vs-Tapestry-tp3555989p3751648.html
Sent from the Tapestry - Dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: HybridJava vs. Tapestry
Posted by based2 <ba...@free.fr>.
You will :-)
http://blog.tapestry5.de/index.php/2010/11/21/response-to-matt-raibles-presentation-at-devoxx-2010/
http://olex.openlogic.com/wazi/2010/choosing-the-right-java-web-development-framework/
http://code.google.com/p/perfbench/
http://code.google.com/p/appfuse-demos/
http://en.wikipedia.org/wiki/Comparison_of_web_application_frameworks
http://www.slideshare.net/jmarranz/how-to-choose-a-web-framework-and-be-surprised
--
View this message in context: http://tapestry.1045711.n5.nabble.com/Re-HybridJava-vs-Tapestry-tp3555989p3797807.html
Sent from the Tapestry - Dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: HybridJava vs. Tapestry
Posted by AlexSerov <Hy...@gmail.com>.
> Less memory usage due to not use recursion. Less deep stack traces too. :)
Oh no! The depth of the stack trace is defined by the page you want to
build. Weather you use recursion or not does not change that. If the page
implies presenting five levels that will be five leveles regardless.
> Someone said that you shouldn't look at a JSF one if you have vertigo. :P
Most unfortunately I have already looked at JSF, though 2.0.
>> From Tapestry site I have also concluded that things like buttons and
>> text fields are components and thus imply using instances. Are these ones
>> created at page run-time or not?
>Absolutely no. There's a single instance for each page class with all the
component tree pre-instantiated. A page render is just rendering the page
and its components.
That is not that simple. Both to answer and to ask. If a component in
Tapestry is what I think then I suppose it has a state independent from that
of the page. Each component entry in this case must have a separate class
instance to keep that state. Different for different users. I've read that
Tapestry cleans the object corresponding to a page after rendering is over.
Not sure what it does with instances of components. Seems like that means
that before each rendering (absolutely so when a different user hits) the
page with the component tree should be restored. As someone noticed it is
not 2000 now ans pooling objects is consigered by many as beeng spower than
recreating by "new" with garbage collection. I asked not about rendering,
but about run-time of one page. I have a feeling that Tapestry has to
recreate (or re-obtain - does not matter) all the instances of components
anew?
>> Finally - the user actions are passed in the form of "events" (so I
>> read). Does this process also imply creating some objects at Java
>> run-time?
>Just the object containing the event context parameters, and just if the
event handler method has a List or EventContext object.
That may be not a huge advantage, but HybridJava solves this task without
any objects.
>> As a matter of fact HybridJava creates only one class instance that
>> carries the page model values and at the same time has the both the
>> render and handle methods on it. Regardless of the number of buttons and
>> text fields.
>Same as Tapestry in this respect.
This does not match to what you told right above: "object containing" us an
object, List is an object. Are "context parameters" and "EventContext
object" objects as well?
>>These measurements only have significance if they implement exactly the
same application or use cases.
That is what I say. If you do not like my tests do give me yours.
>> SO, what about you choose a test that I implement using HybridJava (you
>> most probably already have that test implemented using Tapestry) and I
>> send you my test that you implement using Tapestry. That is a way that
>> will require minimum effort from anybody and the only practical.
>Ok!
Looking forward. If fact each of us already has tests implemented by his own
framework.
>I didn't say it was enough. I just cited one comparison
It is not enough because such researches are absolutely rare, not because
you said "enough".
>> What matters is that it is a kind of redundant mechanism. I understand
>> that at some point it was borrowed from PHP.
>It wasn't. And what do you mean by redundant?
That means exactly that if you cut it off the documentation and from
implementation as well Tapestry will be same usable as before.
> doesn't couple components. Tapestry's philosophy is to have the least
> coupling possible.
I am not strong in philosophy. There is no framework that does not claim
that it's philosophy isn't about minimization of coupling between components
(on of which is the page).
Here is a concrete example: suppose we have a component like chat. It has
its own buttons and text fields and does not depend on anything at all. On
that page you probably have a component that defines the nice surrounding
common for all pages and a hole in the middle that you want to fill with a
content. Suppose I want to put there 2 chat components.
In HybridJava that will look like:
<html><PageLayout><chat/><chat/></PageLayout></html>. And
that is it. No other configuration or mentioning the chat component in the
some java code. The only coupling of the complnents here is their
positioning on the page and one relative to another which is all solved by
the means of mark-up and which seem being minimal possible. And you may chat
with two friends in parallel.
How would similar example look in Tapestry? I ask because I did not go into
Tapestry that deep yet.
--
View this message in context: http://tapestry.1045711.n5.nabble.com/Re-HybridJava-vs-Tapestry-tp3555989p3751748.html
Sent from the Tapestry - Dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: HybridJava vs. Tapestry
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
On Tue, 15 Mar 2011 21:09:01 -0300, AlexSerov
<Hy...@gmail.com> wrote:
> Hi Thiago!
HI!
>>> Tapestry rendering uses a queue, not recursion.
>
> Well, a queue is not automatically better than a tree.
Less memory usage due to not use recursion. Less deep stack traces too. :)
Someone said that you shouldn't look at a JSF one if you have vertigo. :P
> What I indeed would like to know is how many Java class instances are
> created while Tapestry
> renders a typical page and then handles user actions on that page. The
> word "queue" already implies that there are several instances.
No component, mixin or page instances are created during a rendering, just
Tapestry DOM elements.
> From Tapestry site I have also concluded that things like buttons and
> text fields are components and thus imply using instances. Are these
> ones created at page run-time or not?
Absolutely no. There's a single instance for each page class with all the
component tree pre-instantiated. A page render is just rendering the page
and its components.
> Finally - the user actions are passed in the form of "events" (so I
> read). Does this process also imply creating some objects at Java
> run-time?
Just the object containing the event context parameters, and just if the
event handler method has a List or EventContext object.
> As a matter of fact HybridJava creates only one class instance that
> carries the page model values and at the same time has the both the
> render and
> handle methods on it. Regardless of the number of buttons and text
> fields.
Same as Tapestry in this respect.
> Sorry, in fact I meant that it will be a waste of time if I try to do it.
> Suppose we want to compare framework X with 22 other frameworks from A
> to Y. Suppose we have chosen few test that all agree will make sense to
> use. I
> think you may also want to compare Tapestry to many other frameworks,
> right?
You're the one comparing HybridJava to Tapestry here. :)
We're focused on improving the framework, not comparing it to others.
> What we CAN do in reality is: each team implements tests using their own
> technology to the best of their knowledge of that technology and then all
> teams present the result of measurements. Suggesting doing otherwise is
> an apparently over-protective attempt to ensure that comparison never
> happens.
These measurements only have significance if they implement exactly the
same application or use cases.
> SO, what about you choose a test that I implement using HybridJava (you
> most probably already have that test implemented using Tapestry) and I
> send you my test that you implement using Tapestry. That is a way that
> will require minimum effort from anybody and the only practical.
Ok!
>> There is at least once person which compared Tapestry's performance with
>> other framework (in this case, Struts 1) and it turned out that T5 was
>> faster, specially in more complex situations.
>
> I would ask about numbers and details about complexity, but just one
> comparison is way not enough.
I didn't say it was enough. I just cited one comparison
>
>> If you said Struts instead of heroin your words would be taken way more
> seriously.
>
> You got me right anyway. That could be Struts, JSF, Wicket of Spring. Any
> professional knowledge is addictive . However previously you have
> mentioned comparing to Struts as apparently useful.
One comparison is better than none . ..
> What matters is that it is a kind of redundant mechanism. I understand
> that at some point it was borrowed from PHP.
It wasn't. And what do you mean by redundant?
> I suspect that it is the only
> mechanism for coupling components in PHP, but Tapestry simply already
> has a better one (I mean t:body).
<t:body> doesn't couple components. Tapestry's philosophy is to have the
least coupling possible.
> HybridJava has generalized the latter up to
> "named slots" and that made the mechanism good for all needs.
Tapestry's template engine has something that sounds similar to that
(<t:extension-point>).
> My best regard to your cenzor.
Cenzor? :)
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, Ars Machina Tecnologia da Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: HybridJava vs. Tapestry
Posted by AlexSerov <Hy...@gmail.com>.
Hi Thiago!
Thank you for fair technical information regarding those details of how
Tapestry works touched in my research. I did my best to understand those
from the Tapestry site but apparently the site is far from perfect in
explaining technical details. Your explanations are much more helpful.
>> Tapestry rendering uses a queue, not recursion.
Well, a queue is not automatically better than a tree. What I indeed would
like to know is how many Java class instances are created while Tapestry
renders a typical page and then handles user actions on that page. The word
"queue" already implies that there are several instances.
>From Tapestry site I have also concluded that things like buttons and text
fields are components and thus imply using instances. Are these ones created
at page run-time or not?
Finally - the user actions are passed in the form of "events" (so I read).
Does this process also imply creating some objects at Java run-time?
As a matter of fact HybridJava creates only one class instance that carries
the page model values and at the same time has the both the render and
handle methods on it. Regardless of the number of buttons and text fields.
>> that implementing them with Tapestry may be a waist of time,
>Why would it be a waste of time? If you want to prove that your framework
>is fast, write the performance tests. If we think there's something that
>could be implemented in a better way, we'll tell how.
Sorry, in fact I meant that it will be a waste of time if I try to do it.
Suppose we want to compare framework X with 22 other frameworks from A to Y.
Suppose we have chosen few test that all agree will make sense to use. I
think you may also want to compare Tapestry to many other frameworks, right?
Now if for instance we ask the Tapestry team to implement the tests by 21
other technologies THAT will be the waste of time. At least I do not feel
myself able to master 21 frameworks to the point of testing performance. And
that is exactly what you suggest me - that I should Implement the tests
using Tapestry, right? And if we invite four other teams - they should
repeat the same? That will not work.
What we CAN do in reality is: each team implements tests using their own
technology to the best of their knowledge of that technology and then all
teams present the result of measurements. Suggesting doing otherwise is an
apparently over-protective attempt to ensure that comparison never happens.
SO, what about you choose a test that I implement using HybridJava (you most
probably already have that test implemented using Tapestry) and I send you
my test that you implement using Tapestry. That is a way that will require
minimum effort from anybody and the only practical.
>There is at least once person which compared Tapestry's performance with
>other framework (in this case, Struts 1) and it turned out that T5 was
>faster, specially in more complex situations.
I would ask about numbers and details about complexity, but just one
comparison is way not enough.
>If you said Struts instead of heroin your words would be taken way more
seriously.
You got me right anyway. That could be Struts, JSF, Wicket of Spring. Any
professional knowledge is addictive . However previously you have mentioned
comparing to Struts as apparently useful.
>> By the way - one of the features mentioned above is if fact "not
>> recommended" by Tapestry site ...
>Which one? Template inheritance? It's as recommended as class inheritance
>in Java: it's not recommended to abuse it, but there are scenarios in
>which their use is recommended.
What matters is that it is a kind of redundant mechanism. I understand that
at some point it was borrowed from PHP. I suspect that it is the only
mechanism for coupling components in PHP, but Tapestry simply already has a
better one (I mean t:body). HybridJava has generalized the latter up to
"named slots" and that made the mechanism good for all needs.
My best regard to your cenzor.
--
View this message in context: http://tapestry.1045711.n5.nabble.com/Re-HybridJava-vs-Tapestry-tp3555989p3738934.html
Sent from the Tapestry - Dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: HybridJava vs. Tapestry
Posted by Howard Lewis Ship <hl...@gmail.com>.
Hey, if it's on the mailing list, it is public domain.
On Tue, Mar 15, 2011 at 8:57 AM, Massimo Lusetti <ml...@gmail.com> wrote:
> On Tue, Mar 15, 2011 at 4:44 PM, Howard Lewis Ship <hl...@gmail.com> wrote:
>
>
>> "Everything is simple to the man who doesn't have to do it." When
>> other frameworks do half as much as Tapestry, then we can start
>> performance and productivity comparisons.
>
> May I use you last sentence for my quote of the day?
>
> Cheers
> --
> Massimo
> http://meridio.blogspot.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-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: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: HybridJava vs. Tapestry
Posted by Massimo Lusetti <ml...@gmail.com>.
On Tue, Mar 15, 2011 at 4:44 PM, Howard Lewis Ship <hl...@gmail.com> wrote:
> "Everything is simple to the man who doesn't have to do it." When
> other frameworks do half as much as Tapestry, then we can start
> performance and productivity comparisons.
May I use you last sentence for my quote of the day?
Cheers
--
Massimo
http://meridio.blogspot.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: HybridJava vs. Tapestry
Posted by Howard Lewis Ship <hl...@gmail.com>.
Thiago,
No need to follow this up. You're not going to get anywhere.
"Everything is simple to the man who doesn't have to do it." When
other frameworks do half as much as Tapestry, then we can start
performance and productivity comparisons.
On Tue, Mar 15, 2011 at 4:04 AM, Thiago H. de Paula Figueiredo
<th...@gmail.com> wrote:
> On Tue, 15 Mar 2011 00:46:18 -0300, AlexSerov <Hy...@gmail.com>
> wrote:
>
>> "At runtime, Tapestry parses the documents and only checks for
>> wellformedness".
>> So either Tapestry parses the documents at run-time or the Tapestry
>> site is awfully wrong.
>
> Tapestry parses the templates once, at run time, but just parses again when
> the template is changed, not for every render.
>
>> Usually rendering means rendering at run-time. What this text describes
>> literary is that at run-time:
>> 1) components render out DOM (tree of nodes)
>
> Correct.
>
>> 2) DOM is visited recursively with streaming HTML to the client
>> (client is waiting for HTML, not for DOM).
>
> Incorrect. Tapestry rendering uses a queue, not recursion: "Rendering of
> components in Tapestry 5 is based on a state machine and a queue (instead of
> the tail recursion used in Tapestry 4)."
> http://tapestry.apache.org/component-rendering.html
>
>> I often insist on measuring of results in such a situation.
>> Unfortunately I have same much reasons to ask you to do the same. But
>> in general I agree. I even have a small set of very small tests on
>> HybridJava site that I suggest everybody to implement. I am afraid
>> that implementing them with Tapestry may be a waist of time,
>
> Why would it be a waste of time? If you want to prove that your framework is
> fast, write the performance tests. If we think there's something that could
> be implemented in a better way, we'll tell how.
>
>> but if you agree to try to implement some of my tests (for instance
>> "Components") using Tapestry than I may promise to implement a test of
>> your choice in HybridJava provided it will be not much more complex than
>> my test.
>
> There is at least once person which compared Tapestry's performance with
> other framework (in this case, Struts 1) and it turned out that T5 was
> faster, specially in more complex situations.
>
>> User's love may be an argument for commercial success, but not for
>> scientific discussion.
>> There are many users for instance that admire heroin.
>
> If you said Struts instead of heroin your words would be taken way more
> seriously.
>
>> By the way - one of the features mentioned above is if fact "not
>> recommended" by Tapestry site ...
>
> Which one? Template inheritance? It's as recommended as class inheritance in
> Java: it's not recommended to abuse it, but there are scenarios in which
> their use is recommended.
>
> --
> Thiago H. de Paula Figueiredo
> Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and
> instructor
> Owner, Ars Machina Tecnologia da Informação Ltda.
> http://www.arsmachina.com.br
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-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: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: HybridJava vs. Tapestry
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
On Tue, 15 Mar 2011 00:46:18 -0300, AlexSerov
<Hy...@gmail.com> wrote:
> "At runtime, Tapestry parses the documents and only checks for
> wellformedness".
> So either Tapestry parses the documents at run-time or the Tapestry
> site is awfully wrong.
Tapestry parses the templates once, at run time, but just parses again
when the template is changed, not for every render.
> Usually rendering means rendering at run-time. What this text describes
> literary is that at run-time:
> 1) components render out DOM (tree of nodes)
Correct.
> 2) DOM is visited recursively with streaming HTML to the client
> (client is waiting for HTML, not for DOM).
Incorrect. Tapestry rendering uses a queue, not recursion: "Rendering of
components in Tapestry 5 is based on a state machine and a queue (instead
of the tail recursion used in Tapestry 4)."
http://tapestry.apache.org/component-rendering.html
> I often insist on measuring of results in such a situation.
> Unfortunately I have same much reasons to ask you to do the same. But
> in general I agree. I even have a small set of very small tests on
> HybridJava site that I suggest everybody to implement. I am afraid
> that implementing them with Tapestry may be a waist of time,
Why would it be a waste of time? If you want to prove that your framework
is fast, write the performance tests. If we think there's something that
could be implemented in a better way, we'll tell how.
> but if you agree to try to implement some of my tests (for instance
> "Components") using Tapestry than I may promise to implement a test of
> your choice in HybridJava provided it will be not much more complex than
> my test.
There is at least once person which compared Tapestry's performance with
other framework (in this case, Struts 1) and it turned out that T5 was
faster, specially in more complex situations.
> User's love may be an argument for commercial success, but not for
> scientific discussion.
> There are many users for instance that admire heroin.
If you said Struts instead of heroin your words would be taken way more
seriously.
> By the way - one of the features mentioned above is if fact "not
> recommended" by Tapestry site ...
Which one? Template inheritance? It's as recommended as class inheritance
in Java: it's not recommended to abuse it, but there are scenarios in
which their use is recommended.
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, Ars Machina Tecnologia da Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: HybridJava vs. Tapestry
Posted by AlexSerov <Hy...@gmail.com>.
Hi Ville !
9902468 wrote:
>
> Science favors measurable differences - if you make arguments please back
> those up with hard numbers.
You are absolutely right about numbers. Should I apologize for Tapestry site
that misled me a lot - I think I should not. After I received clarifications
from Igor and others I immediately concluded that there is no much reasons
for Tapestry to bee too slow. Nevertheless I did some measurements once I
got some time.
I have installed Tapestry, Jetty, OpenEJB and Jumpstart following the
instructions. Then I have installed jmeter. I set it for 30 threads 100
seconds for a warm-up and 500 requests from each thread. The request did hit
only the first page of Jumpstart - localhost:8080/jumpsatrt/ itself. The
numbers are: average response time 130 milliseconds, throughoutput -
65/second. Not bad at all. I ran jetty from eclipse as described in the
instruction.
To test HybridJava I ported same page into HybridJAva format and generated
war file which I installed under jetty and ran jetty from a command line.
For this test HybridJava is only about twice faster.
--
View this message in context: http://tapestry.1045711.n5.nabble.com/Re-HybridJava-vs-Tapestry-tp3555989p4287685.html
Sent from the Tapestry - Dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: HybridJava vs. Tapestry
Posted by AlexSerov <Hy...@gmail.com>.
>Science favors measurable differences - if you make arguments please back
those up with hard numbers. Otherwise you are just another troll shouting
that T5 is shit compared to product x.
I absolutely agree that we al need measurements. I have explained my point
of view in my answer to Thiago a minute ago. However if team A tells team B:
take some tests, implement them using our ("A") technology and tell the
numbers that will not work. Example: Tapestry team claims that Tapestry is
better than 10 other technologies. Will Tapestry team implement some tests
using all those technologies in the row? Apparently not. And proposal like
that raises a suspicion that in fact nothing happens. The only honest and
doable approach is if each team implements a common set of tests using its
own technology.
I never said that T5 is shit. Maybe you think so - I do not know. To be
explicit - when I compare Tapestry with Spring MVC, JSF, Wicket or Struts 2
(not to mention less spread) I say the Tapestry is the best by it’s
concepts. And the most important one is the MVC component model. It does not
mean that T is perfect.
>And you must sell your solution to us. You're not doing a very convincing
job right now..
I am making just first steps in that. The first step is gathering
information. I appreciate clarifications that I got from Thiago and I asked
more questions. Before I have enough information I will not claim anything
as final. As to performance - here only measurements may be reliable.
>Why would I need to learn yet new language?
When you right a simple program on Java then Java is your language. When you
create a web application you often have to use several languages. Mark-up
language for View, XML for configuration, some JSTL pre-existing toys for
logic in the presentation layer, some stuff for EL and so on. HybridJava
eliminates a lot of those. In fact HybridJava is not a new language at all,
rather a synthesis of Java and HTML with very small overhead,
>And why do you compare your product to jsp or struts
(http://www.hybridjava.com:8080/, http://www.hybridserverpages.com/), those
are very outdated, that does not leave good impression either. World has
moved since 2000 you know.
However Tapestry site also compares to JSP. And Thiago in his mail refers to
comparison of Tapestry to Struts 1 research. Double standard? Right now I am
(as I hope) to comparing to Tapestry so that will change on HybridJava site.
Thank you for advice.
>If you provide something truly innovative and something that enables people
to make more money people will instantly buy it. The only problem is that
you have not convinced me that your product is worth buying or using. Prove
me wrong, and I'll use it.
Honestly - a confusing question for me. I do want to know more about
Tapestry - I try to understand it (even though some info taken from Tapestry
site proved to be misleading). I ask specific questions. Either you have
read our site and understood everything (so you do not ask any questions at
all) or you in reality did not read it. The most simple thing is that
Tapestry does not support recursion. I would understand if you wrote that
recursion is not that important, but I am not sure you've noticed that
HybridJava does support. More importand properties are featured there too.
--
View this message in context: http://tapestry.1045711.n5.nabble.com/Re-HybridJava-vs-Tapestry-tp3555989p3743696.html
Sent from the Tapestry - Dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: HybridJava vs. Tapestry
Posted by AlexSerov <Hy...@gmail.com>.
Thank you for reading the first page of our site.
I must admit your jokes sound quite professional.
--
View this message in context: http://tapestry.1045711.n5.nabble.com/Re-HybridJava-vs-Tapestry-tp3555989p3744209.html
Sent from the Tapestry - Dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: HybridJava vs. Tapestry
Posted by Howard Lewis Ship <hl...@gmail.com>.
Ooh boy ... I can get a temporary, free, commercial license for
HybridJava if I Act Quickly. Offer Will Not Be Repeated. But Wait,
There's More. If You Register Today, You Can Get a Free Set of
Quality Steak Knives.
On Tue, Mar 15, 2011 at 10:41 AM, 9902468 <vi...@greenstreet.fi> wrote:
> Hi,
>
> You said "User's love may be an argument for commercial success, but not for
> scientific discussion. "
>
> Science favors measurable differences - if you make arguments please back
> those up with hard numbers. Otherwise you are just another troll shouting
> that T5 is shit compared to product x.
>
> If you market your solution please explain what it is useful for. If I need
> ultimate performance I write servlets. If I make ajax enabled complex UI:s I
> use T5, PrimeFaces or similar. Why your solution is better? We, as
> developers and software architects, must sell these decisions to our bosses.
> And you must sell your solution to us. You're not doing a very convincing
> job right now..
>
> Why would I need to learn yet new language? And why do you compare your
> product to jsp or struts (http://www.hybridjava.com:8080/,
> http://www.hybridserverpages.com/), those are very outdated, that does not
> leave good impression either. World has moved since 2000 you know.
>
> If you provide something truly innovative and something that enables people
> to make more money people will instantly buy it. The only problem is that
> you have not convinced me that your product is worth buying or using. Prove
> me wrong, and I'll use it.
>
> - Ville
>
> --
> View this message in context: http://tapestry.1045711.n5.nabble.com/Re-HybridJava-vs-Tapestry-tp3555989p3711838.html
> Sent from the Tapestry - Dev mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-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: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: HybridJava vs. Tapestry
Posted by AlexSerov <Hy...@gmail.com>.
This is about hitting the first page of jumpstart only, which may be
OK. I will be happy to use whatever some other .war you send me.
Alex
On Fri, Apr 8, 2011 at 4:33 AM, Thiago H. de Paula Figueiredo [via
Tapestry] <ml...@n5.nabble.com> wrote:
> On Thu, 07 Apr 2011 23:38:31 -0300, AlexSerov
> <[hidden email]> wrote:
>
>> I think that for Tapestry folks (unlike me) it would be very simple to
>> generate jumstart application in the form of a war file that works at
>> once when deployed on jetty that is running from a command line. I
>> will appreciate if someone sends me that war file for my perfomance
>> tests.
>
> JumpStart isn't suitable for that, as it's a cookbook, not an application.
>
> --
> Thiago H. de Paula Figueiredo
> Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
> and instructor
> Owner, Ars Machina Tecnologia da Informação Ltda.
> http://www.arsmachina.com.br
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
>
> ________________________________
> If you reply to this email, your message will be added to the discussion
> below:
> http://tapestry.1045711.n5.nabble.com/Re-HybridJava-vs-Tapestry-tp3555989p4290602.html
> To unsubscribe from Re: HybridJava vs. Tapestry, click here.
--
View this message in context: http://tapestry.1045711.n5.nabble.com/Re-HybridJava-vs-Tapestry-tp3555989p4291176.html
Sent from the Tapestry - Dev mailing list archive at Nabble.com.
Re: HybridJava vs. Tapestry
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
On Thu, 07 Apr 2011 23:38:31 -0300, AlexSerov
<Hy...@gmail.com> wrote:
> I think that for Tapestry folks (unlike me) it would be very simple to
> generate jumstart application in the form of a war file that works at
> once when deployed on jetty that is running from a command line. I
> will appreciate if someone sends me that war file for my perfomance
> tests.
JumpStart isn't suitable for that, as it's a cookbook, not an application.
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, Ars Machina Tecnologia da Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: HybridJava vs. Tapestry
Posted by AlexSerov <Hy...@gmail.com>.
I think that for Tapestry folks (unlike me) it would be very simple to
generate jumstart application in the form of a war file that works at
once when deployed on jetty that is running from a command line. I
will appreciate if someone sends me that war file for my perfomance
tests.
Alex
On Thu, Apr 7, 2011 at 6:10 PM, hj <hy...@gmail.com> wrote:
> I would do that myself, but did not find the way to start jumpstart in
> a normal way - using war file.I see that as a drawback of jumpstart,
> but if someone helps me a little bit with running jumpstart with jetty
> started in a command line I will appreciate that a lot.
>
> Alex
>
> On Thu, Apr 7, 2011 at 12:33 AM, Joachim Van der Auwera (PROGS bvba)
> [via Tapestry] <ml...@n5.nabble.com>
> wrote:
>> On 04/07/2011 05:31 AM, AlexSerov wrote:
>>> Hi Ville !
>>>
>>>
>>> 9902468 wrote:
>>>> Science favors measurable differences - if you make arguments please back
>>>> those up with hard numbers.
>>> You are absolutely right about numbers. Should I apologize for Tapestry
>>> site
>>> that misled me a lot - I think I should not. After I received
>>> clarifications
>>> from Igor and others I immediately concluded that there is no much reasons
>>> for Tapestry to bee too slow. Nevertheless I did some measurements once I
>>> got some time.
>>>
>>> I have installed Tapestry, Jetty, OpenEJB and Jumpstart following the
>>> instructions. Then I have installed jmeter. I set it for 30 threads 100
>>> seconds for a warm-up and 500 requests from each thread. The request did
>>> hit
>>> only the first page of Jumpstart - localhost:8080/jumpsatrt/ itself. The
>>> numbers are: average response time 130 milliseconds, throughoutput -
>>> 130/second. Not bad at all. I ran jetty from eclipse as described in the
>>> instruction.
>>>
>>> To test HybridJava I ported same page into HybridJAva format and generated
>>> war file which I installed under jetty and ran jetty from a command line.
>>> HybridJava is only about twice faster.
>> For a fair comparison, you would need to run both applications under
>> jetty from the command line. Having eclipse running in the background
>> will only increase load on the machine and skew your numbers. IDE's
>> have many background jobs.
>>
>> Joachim
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>>
>> ________________________________
>> If you reply to this email, your message will be added to the discussion
>> below:
>> http://tapestry.1045711.n5.nabble.com/Re-HybridJava-vs-Tapestry-tp3555989p4287897.html
>> To unsubscribe from Re: HybridJava vs. Tapestry, click here.
>
--
View this message in context: http://tapestry.1045711.n5.nabble.com/Re-HybridJava-vs-Tapestry-tp3555989p4289937.html
Sent from the Tapestry - Dev mailing list archive at Nabble.com.
Re: HybridJava vs. Tapestry
Posted by AlexSerov <Hy...@gmail.com>.
A good advice, tank you! The ant build so far not quite successful
though. See the log attached please.
Alex
On Fri, Apr 8, 2011 at 2:58 AM, Joachim Van der Auwera (PROGS bvba)
[via Tapestry] <ml...@n5.nabble.com>
wrote:
> On 04/08/2011 03:10 AM, AlexSerov wrote:
>> I would do that myself, but did not find the way to start jumpstart in
>> a normal way - using war file.I see that as a drawback of jumpstart,
>> but if someone helps me a little bit with running jumpstart with jetty
>> started in a command line I will appreciate that a lot.
> Have you tried
> ant package
> ?
>
>
>> Alex
>>
>> On Thu, Apr 7, 2011 at 12:33 AM, Joachim Van der Auwera (PROGS bvba)
>> [via Tapestry]<[hidden email]>
>> wrote:
>>> On 04/07/2011 05:31 AM, AlexSerov wrote:
>>>> Hi Ville !
>>>>
>>>>
>>>> 9902468 wrote:
>>>>> Science favors measurable differences - if you make arguments please
>>>>> back
>>>>> those up with hard numbers.
>>>> You are absolutely right about numbers. Should I apologize for Tapestry
>>>> site
>>>> that misled me a lot - I think I should not. After I received
>>>> clarifications
>>>> from Igor and others I immediately concluded that there is no much
>>>> reasons
>>>> for Tapestry to bee too slow. Nevertheless I did some measurements once
>>>> I
>>>> got some time.
>>>>
>>>> I have installed Tapestry, Jetty, OpenEJB and Jumpstart following the
>>>> instructions. Then I have installed jmeter. I set it for 30 threads 100
>>>> seconds for a warm-up and 500 requests from each thread. The request did
>>>> hit
>>>> only the first page of Jumpstart - localhost:8080/jumpsatrt/ itself. The
>>>> numbers are: average response time 130 milliseconds, throughoutput -
>>>> 130/second. Not bad at all. I ran jetty from eclipse as described in the
>>>> instruction.
>>>>
>>>> To test HybridJava I ported same page into HybridJAva format and
>>>> generated
>>>> war file which I installed under jetty and ran jetty from a command
>>>> line.
>>>> HybridJava is only about twice faster.
>>> For a fair comparison, you would need to run both applications under
>>> jetty from the command line. Having eclipse running in the background
>>> will only increase load on the machine and skew your numbers. IDE's
>>> have many background jobs.
>>>
>>> Joachim
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>>
>>> ________________________________
>>> If you reply to this email, your message will be added to the discussion
>>> below:
>>>
>>> http://tapestry.1045711.n5.nabble.com/Re-HybridJava-vs-Tapestry-tp3555989p4287897.html
>>> To unsubscribe from Re: HybridJava vs. Tapestry, click here.
>>
>> --
>> View this message in context:
>> http://tapestry.1045711.n5.nabble.com/Re-HybridJava-vs-Tapestry-tp3555989p4289814.html
>> Sent from the Tapestry - Dev mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
>
> ________________________________
> If you reply to this email, your message will be added to the discussion
> below:
> http://tapestry.1045711.n5.nabble.com/Re-HybridJava-vs-Tapestry-tp3555989p4290450.html
> To unsubscribe from Re: HybridJava vs. Tapestry, click here.
--
View this message in context: http://tapestry.1045711.n5.nabble.com/Re-HybridJava-vs-Tapestry-tp3555989p4291170.html
Sent from the Tapestry - Dev mailing list archive at Nabble.com.
Re: HybridJava vs. Tapestry
Posted by Joachim Van der Auwera <jo...@progs.be>.
On 04/08/2011 03:10 AM, AlexSerov wrote:
> I would do that myself, but did not find the way to start jumpstart in
> a normal way - using war file.I see that as a drawback of jumpstart,
> but if someone helps me a little bit with running jumpstart with jetty
> started in a command line I will appreciate that a lot.
Have you tried
ant package
?
> Alex
>
> On Thu, Apr 7, 2011 at 12:33 AM, Joachim Van der Auwera (PROGS bvba)
> [via Tapestry]<ml...@n5.nabble.com>
> wrote:
>> On 04/07/2011 05:31 AM, AlexSerov wrote:
>>> Hi Ville !
>>>
>>>
>>> 9902468 wrote:
>>>> Science favors measurable differences - if you make arguments please back
>>>> those up with hard numbers.
>>> You are absolutely right about numbers. Should I apologize for Tapestry
>>> site
>>> that misled me a lot - I think I should not. After I received
>>> clarifications
>>> from Igor and others I immediately concluded that there is no much reasons
>>> for Tapestry to bee too slow. Nevertheless I did some measurements once I
>>> got some time.
>>>
>>> I have installed Tapestry, Jetty, OpenEJB and Jumpstart following the
>>> instructions. Then I have installed jmeter. I set it for 30 threads 100
>>> seconds for a warm-up and 500 requests from each thread. The request did
>>> hit
>>> only the first page of Jumpstart - localhost:8080/jumpsatrt/ itself. The
>>> numbers are: average response time 130 milliseconds, throughoutput -
>>> 130/second. Not bad at all. I ran jetty from eclipse as described in the
>>> instruction.
>>>
>>> To test HybridJava I ported same page into HybridJAva format and generated
>>> war file which I installed under jetty and ran jetty from a command line.
>>> HybridJava is only about twice faster.
>> For a fair comparison, you would need to run both applications under
>> jetty from the command line. Having eclipse running in the background
>> will only increase load on the machine and skew your numbers. IDE's
>> have many background jobs.
>>
>> Joachim
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>>
>> ________________________________
>> If you reply to this email, your message will be added to the discussion
>> below:
>> http://tapestry.1045711.n5.nabble.com/Re-HybridJava-vs-Tapestry-tp3555989p4287897.html
>> To unsubscribe from Re: HybridJava vs. Tapestry, click here.
>
> --
> View this message in context: http://tapestry.1045711.n5.nabble.com/Re-HybridJava-vs-Tapestry-tp3555989p4289814.html
> Sent from the Tapestry - Dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: HybridJava vs. Tapestry
Posted by AlexSerov <Hy...@gmail.com>.
I would do that myself, but did not find the way to start jumpstart in
a normal way - using war file.I see that as a drawback of jumpstart,
but if someone helps me a little bit with running jumpstart with jetty
started in a command line I will appreciate that a lot.
Alex
On Thu, Apr 7, 2011 at 12:33 AM, Joachim Van der Auwera (PROGS bvba)
[via Tapestry] <ml...@n5.nabble.com>
wrote:
> On 04/07/2011 05:31 AM, AlexSerov wrote:
>> Hi Ville !
>>
>>
>> 9902468 wrote:
>>> Science favors measurable differences - if you make arguments please back
>>> those up with hard numbers.
>> You are absolutely right about numbers. Should I apologize for Tapestry
>> site
>> that misled me a lot - I think I should not. After I received
>> clarifications
>> from Igor and others I immediately concluded that there is no much reasons
>> for Tapestry to bee too slow. Nevertheless I did some measurements once I
>> got some time.
>>
>> I have installed Tapestry, Jetty, OpenEJB and Jumpstart following the
>> instructions. Then I have installed jmeter. I set it for 30 threads 100
>> seconds for a warm-up and 500 requests from each thread. The request did
>> hit
>> only the first page of Jumpstart - localhost:8080/jumpsatrt/ itself. The
>> numbers are: average response time 130 milliseconds, throughoutput -
>> 130/second. Not bad at all. I ran jetty from eclipse as described in the
>> instruction.
>>
>> To test HybridJava I ported same page into HybridJAva format and generated
>> war file which I installed under jetty and ran jetty from a command line.
>> HybridJava is only about twice faster.
> For a fair comparison, you would need to run both applications under
> jetty from the command line. Having eclipse running in the background
> will only increase load on the machine and skew your numbers. IDE's
> have many background jobs.
>
> Joachim
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
>
> ________________________________
> If you reply to this email, your message will be added to the discussion
> below:
> http://tapestry.1045711.n5.nabble.com/Re-HybridJava-vs-Tapestry-tp3555989p4287897.html
> To unsubscribe from Re: HybridJava vs. Tapestry, click here.
--
View this message in context: http://tapestry.1045711.n5.nabble.com/Re-HybridJava-vs-Tapestry-tp3555989p4289814.html
Sent from the Tapestry - Dev mailing list archive at Nabble.com.
Re: HybridJava vs. Tapestry
Posted by Joachim Van der Auwera <jo...@progs.be>.
On 04/07/2011 05:31 AM, AlexSerov wrote:
> Hi Ville !
>
>
> 9902468 wrote:
>> Science favors measurable differences - if you make arguments please back
>> those up with hard numbers.
> You are absolutely right about numbers. Should I apologize for Tapestry site
> that misled me a lot - I think I should not. After I received clarifications
> from Igor and others I immediately concluded that there is no much reasons
> for Tapestry to bee too slow. Nevertheless I did some measurements once I
> got some time.
>
> I have installed Tapestry, Jetty, OpenEJB and Jumpstart following the
> instructions. Then I have installed jmeter. I set it for 30 threads 100
> seconds for a warm-up and 500 requests from each thread. The request did hit
> only the first page of Jumpstart - localhost:8080/jumpsatrt/ itself. The
> numbers are: average response time 130 milliseconds, throughoutput -
> 130/second. Not bad at all. I ran jetty from eclipse as described in the
> instruction.
>
> To test HybridJava I ported same page into HybridJAva format and generated
> war file which I installed under jetty and ran jetty from a command line.
> HybridJava is only about twice faster.
For a fair comparison, you would need to run both applications under
jetty from the command line. Having eclipse running in the background
will only increase load on the machine and skew your numbers. IDE's
have many background jobs.
Joachim
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: HybridJava vs. Tapestry
Posted by AlexSerov <Hy...@gmail.com>.
Hi Ville !
9902468 wrote:
>
> Science favors measurable differences - if you make arguments please back
> those up with hard numbers.
You are absolutely right about numbers. Should I apologize for Tapestry site
that misled me a lot - I think I should not. After I received clarifications
from Igor and others I immediately concluded that there is no much reasons
for Tapestry to bee too slow. Nevertheless I did some measurements once I
got some time.
I have installed Tapestry, Jetty, OpenEJB and Jumpstart following the
instructions. Then I have installed jmeter. I set it for 30 threads 100
seconds for a warm-up and 500 requests from each thread. The request did hit
only the first page of Jumpstart - localhost:8080/jumpsatrt/ itself. The
numbers are: average response time 130 milliseconds, throughoutput -
130/second. Not bad at all. I ran jetty from eclipse as described in the
instruction.
To test HybridJava I ported same page into HybridJAva format and generated
war file which I installed under jetty and ran jetty from a command line.
HybridJava is only about twice faster.
--
View this message in context: http://tapestry.1045711.n5.nabble.com/Re-HybridJava-vs-Tapestry-tp3555989p4287677.html
Sent from the Tapestry - Dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: HybridJava vs. Tapestry
Posted by 9902468 <vi...@greenstreet.fi>.
Hi,
You said "User's love may be an argument for commercial success, but not for
scientific discussion. "
Science favors measurable differences - if you make arguments please back
those up with hard numbers. Otherwise you are just another troll shouting
that T5 is shit compared to product x.
If you market your solution please explain what it is useful for. If I need
ultimate performance I write servlets. If I make ajax enabled complex UI:s I
use T5, PrimeFaces or similar. Why your solution is better? We, as
developers and software architects, must sell these decisions to our bosses.
And you must sell your solution to us. You're not doing a very convincing
job right now..
Why would I need to learn yet new language? And why do you compare your
product to jsp or struts (http://www.hybridjava.com:8080/,
http://www.hybridserverpages.com/), those are very outdated, that does not
leave good impression either. World has moved since 2000 you know.
If you provide something truly innovative and something that enables people
to make more money people will instantly buy it. The only problem is that
you have not convinced me that your product is worth buying or using. Prove
me wrong, and I'll use it.
- Ville
--
View this message in context: http://tapestry.1045711.n5.nabble.com/Re-HybridJava-vs-Tapestry-tp3555989p3711838.html
Sent from the Tapestry - Dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: HybridJava vs. Tapestry
Posted by AlexSerov <Hy...@gmail.com>.
> It makes you much more credible if you understand what you are talking
> about. You should read Tapestry's documentation before posting such a
> blog.
> First of all, if you would spend 5 minutes learning Tapestry you would
> come
> across the "static structure, dynamic behavior" principle. Tapestry is not
> "rescanning templates and building DOM of the page before each rendering".
I have spent at least 5 weeks learning Tapestry, not 5 minutes.
Unfortunately I come to a suspicion that I know Tapestry site better
than even you do,. Here is what I read on the Tapestry site:
"At runtime, Tapestry parses the documents and only checks for
wellformedness".
So either Tapestry parses the documents at run-time or the Tapestry
site is awfully wrong.
> All the page instances are singletons, which are smart enough to care for
> multithreading aspects. So, your expectation on efficiency is naive.
But the Tapestry site tells:
"Components render out a Document Object Model (DOM). This is a
tree of nodes representing elements,
attributes and text within a document. Once all rendering is
complete, the DOM tree is streamed to the client."
Usually rendering means rendering at run-time. What this text describes
literary is that at run-time:
1) components render out DOM (tree of nodes)
2) DOM is visited recursively with streaming HTML to the client
(client is waiting for HTML, not for DOM).
If something different from described was meant by Tapestry site text
that is a problem of that site, not mine.
> If you want to speak about performance, create two similar apps with both
> technologies and measure the results. Show me the results, but please
> don't
> come up with something like "All in all it’s hard to expect Tapestry to be
> fast in production.".
I often insist on measuring of results in such a situation.
Unfortunately I have same much reasons to ask you to do the same. But
in general I agree. I even have a small set of very small tests on
HybridJava site that I suggest everybody to implement. I am afraid
that implementing them with Tapestry may be a waist of time, but if
you agree to try to implement some of my tests (for instance
"Components") using Tapestry than I may promise to implement a test of
your choice in HybridJava provided it will be not much more complex than my
test.
> Also your statements on Tapestry's IoC, mixins, template inheritance and
> annotation-based approach are sweet and naive as you don't provide any
> arguments. These features are why Tapestry users love the framework.
User's love may be an argument for commercial success, but not for
scientific discussion.
There are many users for instance that admire heroin.
By the way - one of the features mentioned above is if fact "not
recommended" by Tapestry site ...
> Nice try, but not professional.
Did not get what is nice. "not professional" does not sound convincing.
Especially if what you do not like is in fact a mess in your own
documentation.
I wrote above about comparing in numbers and that would be way more
professional
than blatantly claiming each other "unprofessional".
I suggest you may also pay attention to similarities in our frameworks
and possible collaboration of
our teams in the future
--
View this message in context: http://tapestry.1045711.n5.nabble.com/Re-HybridJava-vs-Tapestry-tp3555989p3656756.html
Sent from the Tapestry - Dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org