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.
