tag:blogger.com,1999:blog-4110180.post9113746865223224293..comments2023-06-20T05:31:24.545-07:00Comments on Tapestry Central: Latest T5 Snapshots: Invisible InstrumentationAnonymoushttp://www.blogger.com/profile/04486596490758986709noreply@blogger.comBlogger9125tag:blogger.com,1999:blog-4110180.post-13360871881111074132007-01-06T16:43:00.000-08:002007-01-06T16:43:00.000-08:00For me, the real power of Tapestry is the ease of ...For me, the real power of Tapestry is the ease of creating your own components. The benefits of a component oriented framework is sigificantly reduced when it is not easy for a developer to create their own components. This factor and the template layer are the two primary major strengths that I find Tapestry has over all other frameworks. <br />Keep up the good work. I look forward to Tapestry 5 being release.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-4110180.post-68115329242333976482007-01-05T13:33:00.000-08:002007-01-05T13:33:00.000-08:00I don't think you can appreciate how grating it is...I don't think you can appreciate how grating it is to have Tapestry 5 declared dead on arrival by "anonymous". <br /><br />The defaulting parameter bindings is something documented on a per-component/per-parameter basis. <br /><br />I especially don't like systems that require engineered coincidences bewteen component ids (or the equivalent) and property names. Struts has been down that path with ActionForm and all. The idea that someone could hack a form submission and update properties that were never intended to be changed (not especially a problem from Struts, but Tapestry allows direct editting of component properties). <br /><br />The mapping from t:id to a property is a default behavior used as a convienience, to eliminate ugly repetativeness.<br /><br />In a real application, you'll likely be updating properties of data object, not properties of the page itself, and you'll be back to using value="prop:user.name" or equivalent.<br /><br />I'm not "focusing" on creating a component market. No one has every successed at creating a component market, in any area (except Microsoft and VB controls). Anyway, my focus is <b>entirely</b> on the developer and simplfying their life. I'm looking for ways to ease people into Tapestry, to hook them on it, without overwhelming them with its inner richness.Anonymoushttps://www.blogger.com/profile/04486596490758986709noreply@blogger.comtag:blogger.com,1999:blog-4110180.post-53378746057549716822007-01-05T12:27:00.000-08:002007-01-05T12:27:00.000-08:00The implicit binding of value parameter to a conta...The implicit binding of value parameter to a container property is confusing. What if you had multiple parameters? What would get bound? <br /><br />Also, the use of the t:id parameter and default binding to a component parameter provided a thought-segue to the .NET world where the id parameter actually denotes the property in the container, except the property is the component instance, not a parameter that is bound to the component. I like that model much better. Components have first-class presence in a page, not brittle binding of individual parameters.<br /><br />That way, if I have a text component, in my page, I can do comp.getText(), comp.setText(). I can also setup listener bindings by using constructs such as comp.onValueChanged. IMHO that has always been a shortfall programming with Tapestry.<br /><br />With all the versions of Tapestry - from 3/4/5, Tapestry 5 will not be a success beyond its current niche following for the simple reason that it doesn't focus on components and creating a viable commercial component marketplace. No vendor is going to be interested in maintaining components across such drastic architectural changes. It is unfortunate that JSF has such a terrible legacy JSP technology still built into it. Otherwise, all other frameworks would be rendered as academic experiments.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-4110180.post-92041620975397435492007-01-04T14:44:00.000-08:002007-01-04T14:44:00.000-08:00This is a great enhancement, Howard, probably is b...This is a great enhancement, Howard, probably is better sad that Tapestry5 is a great enhancement for the web development.<br />But i would like to see more... more on the dev list since here seemed too much :)Massimohttps://www.blogger.com/profile/09841812729931064489noreply@blogger.comtag:blogger.com,1999:blog-4110180.post-72470665298540019222007-01-04T12:13:00.000-08:002007-01-04T12:13:00.000-08:00i agree that implicits can be sometimes hard to tr...i agree that implicits can be sometimes hard to trace/debug-- take apache tiles for example, it's a total guessing game as to where properties/values come from in complex layouts because there's no declaration requirements (equiv to always using t:id)Jacob Hookomhttps://www.blogger.com/profile/15287497779663965560noreply@blogger.comtag:blogger.com,1999:blog-4110180.post-34483867705287347682007-01-04T11:16:00.000-08:002007-01-04T11:16:00.000-08:00Using t:id instead of id may be just a bit of dogm...Using t:id instead of id may be just a bit of dogmatism on my part; the t:id has a specific meaning to Tapestry, the XHTML id has a specific meaning to XHTML and the client web browser. If the parser matched on "id", not "t:id", then any static element with an id attribute would become an Any component instance. Not really a problem, but I'm not certain it survives the Principle of Least Surprise.<br /><br />The last couple of years of teaching Tapestry has really educated me on what things people get and what things they don't. As I code up features, I picture a classroom of people's eyes: bad features result in that awful glazed over/desperate look (the one you get when you start explaining about abstract classes in Tapestry 4). Good features result in that eager I-cant-wait-to-start-coding look. Hopefully, the real world students will reflect my imagined ones.Anonymoushttps://www.blogger.com/profile/04486596490758986709noreply@blogger.comtag:blogger.com,1999:blog-4110180.post-56665485058023260912007-01-04T11:00:00.000-08:002007-01-04T11:00:00.000-08:00Seems to make sense, I love the direction T5 is go...Seems to make sense, I love the direction T5 is going. You are addressing all the little things that add up to bigger, more painful experiences...Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-4110180.post-76811535555247558632007-01-04T09:54:00.000-08:002007-01-04T09:54:00.000-08:00I would agree, the "t:" namespace seems unelegant,...I would agree, the "t:" namespace seems unelegant, but I see how it could be troubblesome with the existing namespace of xhtmlarnljothttps://www.blogger.com/profile/11691787647173386212noreply@blogger.comtag:blogger.com,1999:blog-4110180.post-89900578414808945452007-01-04T00:49:00.000-08:002007-01-04T00:49:00.000-08:00i would drop the t:id and just use id, binding eve...i would drop the t:id and just use id, binding everything else transparently-- based on existence of a matching component in the backing page, otherwise require a t:as :-)Jacob Hookomhttps://www.blogger.com/profile/15287497779663965560noreply@blogger.com