You are correct, previewability isn't quite the same in T5 as in T4.
There's some gaps waiting to be filled (not abandoned, just
prioritized a bit lower than more urgent bug fixes).
On Thu, Jun 26, 2008 at 10:48 AM, Don Ryan <[EMAIL PROTECTED]> wrote:
> [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.)
There's a tension between having the framework include every possible
thing, and letting people roll thier own custom solutions.
If you want to use T4 style, how about:
<t:output value="property"/>
public class Output {
@Parameter (required=true)
private String value;
boolean beginRender(MarkupWriter writer) {
if (value != null) writer.write(value);
return false; // skip body
}
}
This could be dressed up a bit to emulated an element and informal
parameters pretty easily.
In terms of localization, you can use:
${message:localized-key}
or
<t:output value="message:localized-key"/>
>
> (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.
Interesting idea; we could change it so that attributes in the
Tapestry namespace override other attributes with the same name (case
insensitive).
>
> (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.
I'm not opposed to these changes, just working on many other things.
Issues in JIRA are a first step, patches are also welcome! (If they
have tests).
>
> 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]
>
>
--
Howard M. Lewis Ship
Creator Apache Tapestry and Apache HiveMind
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
