(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.)
Are you sure? What about...
<span t:type="output" value="student.grade">A</span>
(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.
Agreed. Should be a directive so that it doesn't have to obey the
matching tags rules.
(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.
Really there are 3 styles and I think the doco has slipped up on
them. Weren't these the terms being used a while back...
- Components as elements, eg. <t:pagelink page="Index">Home</t:pagelink>
- Embedded components, eg. <a t:type="pagelink" t:page="Index"
href="#">Home</a>
- Invisible instrumentation, eg. <a t:id="index" href="#">Home</a>
with
@Component(id = "index", parameters = {"page=Index"})
@SuppressWarnings("unused")
private PageLink _index;
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]
