Again, this is a difficult call. I really like being able to omit prefixes when its obvious what Tapestry should do. That DRY.
Kent's position is that there should be no ambiguity. With per-parameter default binding prefixes, you need to know a bit about the internals of the component to know how it will treat an un-prefixed string. That leads to ambiguity and possibly even fragility -- if the component author changes the default binding prefix, then it may break existing pages. So I see Kent's side as well. On 1/13/07, Jesse Kuhnert <[EMAIL PROTECTED]> wrote:
+1 for putting more work on the component developer to choose good binding prefixes and having better defaults. Having to remember "validate:" / "prop:" "literal:" / etc is always a PITA for me personally. On 1/13/07, Howard Lewis Ship <[EMAIL PROTECTED]> wrote: > I return to my basic example: > > Today: > > <input type="text" t:type="TextField" t:id="userName" size="30" > validate="validate:required" class="'wiggins'"/> > > (30 is a valid expression, it's turned into a Long. wiggins has to be quoted). > > Proposal HLS: > > <input type="text" t:id="userName" size="30" validate="required" > class="wiggins"/> > > (TextField is deduced. size and class are informal, therefore > literal. validate assumes "validate:" prefix). > > Proposal KT: > > <input type="text" t:id="userName" size="30" > validate="validate:required" class="wiggins"/> > > (I'm assuming Ken wouldn't object to deducing TextField. Everything > defaults to literals, except with a prefix). > > > On 1/12/07, Kent Tong <[EMAIL PROTECTED]> wrote: > > Howard Lewis Ship <hlship <at> gmail.com> writes: > > > > > What I'd really like to do is bring back the idea of default binding > > > prefix PER PARAMETER from Tapestry 4.0 (you know, the idea that got > > > shot down). This, combined with component type deduction (i.e., > > > <input type="text"> means TextField, even if t:type not specified) > > > leads to templates like: > > > > > > <input type="text" t:id="userName" size="30" class="highlight" > > > onchange="this.form.submit();" validate="required"/> > > > > > > ... just working, which is what I'd like. > > > > I was one of those who shot it down :-) I personally prefer using > > prop as default in Java code and using literal in templates. This > > demonstrates simplicity and separation of concerns (template should > > be static and Java code should be dynamic). > > See the proposals above. It's consistency vs. Dont Repeat Yourself. > I really want Tapestry to "just do the right thing". I really like > validate="required" rather than validate="validate:required". > > > > > We *could* get rid of <t:comp>. I'd like to keep it around. From T4: > > > If and Loop and a few others would render a tag if the element > > > parameter was set. Having <t:comp> AND invisible instrumentation > > > allows the developer to accomplish the same thing without binding a > > > parameter repetatively. > > > > Are you saying by using <t:comp> the programmer can indicate that > > an element is not to be generated? In terms of effort, this is not > > much different from specifying the "element" parameter. > > > > > It also clearly distinguishes between visual > > > components (TextArea) and non-visual components (an If that doesn't > > > render an element). > > > > Aren't <span> and <div> for this purpose? > > That's true. I am beginning to budge on a few of these things. For > example, maybe we're going to extraordinary lengths to avoid a few > spare <span> or <div> tags, as you point out. Though it does become > problematic when you need to put a conditional around several rows of > a table ... your change of generate valid [X]HTML drop to nil without > an explicit component container such as <t:comp>. > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > Howard M. Lewis Ship > TWD Consulting, Inc. > Independent J2EE / Open-Source Java Consultant > Creator and PMC Chair, Apache Tapestry > Creator, Apache HiveMind > > Professional Tapestry training, mentoring, support > and project work. http://howardlewisship.com > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Jesse Kuhnert Tapestry/Dojo team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Howard M. Lewis Ship TWD Consulting, Inc. Independent J2EE / Open-Source Java Consultant Creator and PMC Chair, Apache Tapestry Creator, Apache HiveMind Professional Tapestry training, mentoring, support and project work. http://howardlewisship.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
