This is very similar to Paul Graham's discourse on programming languages from "Hackers and Painters". Roughly para-phrased, he points out that a Java programmer will look down on "lesser" (simpler, less sophisticated) programming languages, such as Basic because they are missing features and constructs that are in their language of choice. On the other hand, when they look up spectrum at most powerful/more sophisticated such as Lisp, they think that the features of that language (macros, closures, first-class functions) are just confusing, or arbitrary, or not useful, or get in the way.
Likewise, if you look at a lower-power web framework; one that uses JSPs or a JSP-like system with an action-oriented framework, Tapestry's components and events seem very complicated and expensive. In practice, of course, Tapestry features are mostly invisible ... write a Java class and a template and you have a fully functioning page. Further, because the lower powered framework has limited what it can express to just rendering HTML character by character, it can wholesale convert a page into a single class; this makes it seem like using lots of small classes to accomplish "the same thing" is wasteful and even slow .. though, of course, using lots of small well defined objects is, in my never-humble opinion, a better utilization of the nature of a garbage-collected OO language like Java. 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] >> >> > -- 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]
