> 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 <[email protected]> wrote: > Entertaining in a weird way. > > On Wed, Mar 16, 2011 at 6:19 AM, Howard Lewis Ship <[email protected]> wrote: > >> 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] >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
