+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]
