tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Howard Lewis Ship" <hls...@gmail.com>
Subject Re: T5: default binding is prop even in template
Date Sat, 13 Jan 2007 06:25:56 GMT
I return to my basic example:


<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"

(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 <kent@cpttm.org.mo> 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: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org

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: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org

View raw message