> Less memory usage due to not use recursion. Less deep stack traces too. :)
Oh no! The depth of the stack trace is defined by the page you want to build. Weather you use recursion or not does not change that. If the page implies presenting five levels that will be five leveles regardless. > Someone said that you shouldn't look at a JSF one if you have vertigo. :P Most unfortunately I have already looked at JSF, though 2.0. >> From Tapestry site I have also concluded that things like buttons and >> text fields are components and thus imply using instances. Are these ones >> created at page run-time or not? >Absolutely no. There's a single instance for each page class with all the component tree pre-instantiated. A page render is just rendering the page and its components. That is not that simple. Both to answer and to ask. If a component in Tapestry is what I think then I suppose it has a state independent from that of the page. Each component entry in this case must have a separate class instance to keep that state. Different for different users. I've read that Tapestry cleans the object corresponding to a page after rendering is over. 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. ><t:body> 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: <html><PageLayout><chat/><chat/></PageLayout></html>. 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-tp3555989p3752340.html Sent from the Tapestry - Dev mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
