Hi Thiago! Thank you for fair technical information regarding those details of how Tapestry works touched in my research. I did my best to understand those from the Tapestry site but apparently the site is far from perfect in explaining technical details. Your explanations are much more helpful.
>> Tapestry rendering uses a queue, not recursion. Well, a queue is not automatically better than a tree. What I indeed would like to know is how many Java class instances are created while Tapestry renders a typical page and then handles user actions on that page. The word "queue" already implies that there are several instances. >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? 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? 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. >> that implementing them with Tapestry may be a waist of time, >Why would it be a waste of time? If you want to prove that your framework >is fast, write the performance tests. If we think there's something that >could be implemented in a better way, we'll tell how. Sorry, in fact I meant that it will be a waste of time if I try to do it. Suppose we want to compare framework X with 22 other frameworks from A to Y. Suppose we have chosen few test that all agree will make sense to use. I think you may also want to compare Tapestry to many other frameworks, right? Now if for instance we ask the Tapestry team to implement the tests by 21 other technologies THAT will be the waste of time. At least I do not feel myself able to master 21 frameworks to the point of testing performance. And that is exactly what you suggest me - that I should Implement the tests using Tapestry, right? And if we invite four other teams - they should repeat the same? That will not work. What we CAN do in reality is: each team implements tests using their own technology to the best of their knowledge of that technology and then all teams present the result of measurements. Suggesting doing otherwise is an apparently over-protective attempt to ensure that comparison never happens. 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. >There is at least once person which compared Tapestry's performance with >other framework (in this case, Struts 1) and it turned out that T5 was >faster, specially in more complex situations. I would ask about numbers and details about complexity, but just one comparison is way not enough. >If you said Struts instead of heroin your words would be taken way more seriously. You got me right anyway. That could be Struts, JSF, Wicket of Spring. Any professional knowledge is addictive . However previously you have mentioned comparing to Struts as apparently useful. >> By the way - one of the features mentioned above is if fact "not >> recommended" by Tapestry site ... >Which one? Template inheritance? It's as recommended as class inheritance >in Java: it's not recommended to abuse it, but there are scenarios in >which their use is recommended. What matters is that it is a kind of redundant mechanism. I understand that at some point it was borrowed from PHP. I suspect that it is the only mechanism for coupling components in PHP, but Tapestry simply already has a better one (I mean t:body). HybridJava has generalized the latter up to "named slots" and that made the mechanism good for all needs. My best regard to your cenzor. -- View this message in context: http://tapestry.1045711.n5.nabble.com/Re-HybridJava-vs-Tapestry-tp3555989p3738934.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]
