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