[I'm picking up where I left off on another thread here, namely the
thread with subject "New website using T5: www.ingamenow.com". My
rationale for wanting this is given there.]
Does anyone know if there are plans to restore the previewability of
T5 templates to something akin to what existed in T3 and T4? Some of
the gaps can be tackled by writing your own components, but that
doesn't get you all the way there and I'd prefer not to litter my
stuff with custom components if there are going to be core components
and other mechanisms added subsequently to cater for this.
Specifically, I'm thinking of things like the following.
(i) Expansions. As the User's Guide section on templates points out:
"Tapestry 4 users will note that expansions are a concise, easy
replacement for the Insert component, and for the <span key="...">
directive." They are indeed. They are also not previewable. And I'm
not just talking about the fact that you'll have an expression-like
string instead of a sample-text string. If, for example, you had a
column in a table for the grade achieved by a student, the values in
this column will be single letters (A, B, etc.). Almost any
expression used in the expansion is likely to be much longer than
this and will probably throw the alignment of the (carefully
designed) table way off. Also, is there a previewable way to
internationalize a template in core T5 at the moment? (I haven't
spotted one myself, but that doesn't mean it doesn't exist.)
(ii) An equivalent of jwcid="$remove$". Yes, you can use t5components/
Remove or write your own Remove that short-circuits at beginRender(),
but conceptually a component shouldn't be instantiated at all in this
case. The parser should just be discarding such template sections. A
designer cannot design a repeating construct without seeing several
of them stacked on top of each other. If that's to survive in the
template, some such mechanism is needed. Also, it's worth pointing
out that the move to initiate a T5 FAQ led to discussions that were
in large part about things like $content$ and $remove$, discussions
which subsequently trailed off inconclusively. So there does seem to
be some confusion about where T5 is ultimately headed on this.
(iii) A key aspect of previewability is the ability to provide a
static attribute value in the template and have it overwritten at
runtime. T5, in my experience, has taken a step back in this regard.
For example, I wanted to make a CSS class attribute dynamic, so I put
in a static value (to make the template look right) and an informal
parameter to overwrite it:
<td t:type="any" class="static_value" t:class="prop:cssClass">
This didn't work. The static value remained, regardless of the value
of the cssClass property. Once I deleted the static value from the
template, it worked. However, doing so clearly diminishes
previewability.
(iv) [This one isn't a showstopper, but I'll mention it anyway.] The
Tapestry 5 documentation introduces the term "invisible
instrumentation", but this is clearly a misnomer. The real dichotomy
in instrumenting a Tapestry template is between
(a) Using Tapestry elements
(b) Attributing standard HTML elements
Tapestry elements are typically invisible in a rendered browser view
of the template (just as much as namespaced attributes are) so it's
not a good way of attempting to characterize the distinction between
the two approaches to label one of them as "invisible
instrumentation". It would seem to me that this will only cause
confusion to newcomers.
In relation to the T4-style attributing of HTML elements, some things
have fallen back a little, specifically on the conciseness front. For
example, in T4, I would typically avoid introducing extraneous levels
of nesting in a template by attributing an existing tag whenever
possible. So if the content of a table cell was conditional, I could
attribute the <td> element to be an If component:
<td jwcid="foo">Should only appear sometimes</td>
I could then control whether or not the <td> tag itself rendered by
using the renderTags parameter to the If component. With the T5 If
component, this is not possible, so the simplest thing is to just
wrap the contents of the cell either in a <t:if></t:if> or a <span
t:type="if"></span>. Not a big deal but it is an extra level of
nesting than was previously required. And conciseness is one of the
reasons that some people (myself included) find the attributing of
HTML elements approach to be so appealing.
Lastly, anyone that replies to say "I don't miss previewability" is
missing the point. If your work practices dictate that it's not
something you miss, good for you. For others, it's a big deal. It
would seem to me that with a small amount of work, previewability
could be restored to roughly where it was in T3/T4, which would be of
great benefit to people whose work practices were greatly facilitated
by said previewability. This is ground that Tapestry helped pioneer.
It seems unnecessary to me to cede it to other frameworks.
Regards,
Don.
This message has been scanned for content and viruses by the DIT Information
Services E-Mail Scanning Service, and is believed to be clean. http://www.dit.ie
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
