On Tue, 15 Mar 2011 21:09:01 -0300, AlexSerov
<[email protected]> 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: [email protected]
For additional commands, e-mail: [email protected]
