Is this "discussion" serving any purpose? On Tue, Mar 15, 2011 at 9:23 PM, AlexSerov <[email protected]> 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: [email protected] For additional commands, e-mail: [email protected]
