tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Canfield <joshcanfi...@gmail.com>
Subject Re: HybridJava vs. Tapestry
Date Wed, 16 Mar 2011 16:48:08 GMT
> 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 <inge.tapestry@gmail.com> wrote:
> Entertaining in a weird way.
>
> On Wed, Mar 16, 2011 at 6:19 AM, Howard Lewis Ship <hlship@gmail.com> wrote:
>
>> Is this "discussion" serving any purpose?
>>
>> On Tue, Mar 15, 2011 at 9:23 PM, AlexSerov <HybridServerPages@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


Mime
View raw message