Re: [T5] Template previewability
On 27 Jun 2008, at 21:57, Howard Lewis Ship wrote: Well, Insert is a terrible name :-) There's already OutputText (for formatted output). Perhaps FormatText would have been a better name in retrospect. Haven't seen OutputText. It's not part of 5.0.13, is it? (Or am I blind?) In any case, my real interest here is in the scenario of wanting to restore previewability to templates that are currently functional but not fully previewable. (By virtue, perhaps, of having inherited Tapestry work from someone else or alternatively from having done some quick-and-dirty prototyping to get the initial project go- ahead.) Ideally, there should be a core component that serves as a one-to-one drop-in replacement for expansions. And, as such, it should be kept simple, pretty much in line with what an expansion does. You could even document it as the previewable version of an expansion. I think Text would be a good name for it, but that's just a suggestion. You essentially have it more-or-less written from an earlier post. And it would help maintain a symmetry between the previewable and non-previewable ways of instrumenting templates. 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]
Re: [T5] Template previewability
Don,
You're right about there being only a two-way split. I've looked in
the archives and found as long ago as 2002 Howard described "invisible
instrumentation" as being "a term for how Tapestry HTML templates
maintain WYSIWYG editor compatibility". So, as you say, my 2nd and
3rd styles are both examples of invisible instrumentation.
Regarding "embedded components", I'd offer the suggestion that we can
think of invisible instrumentation as being achieved by embedding
components in regular HTML elements. Tapestry recognises the embedded
component at runtime by the presence of a namespaced type or id
attribute, eg. t:type="foo", and/or t:id="bar". I dunno, maybe
"embedding" is ambiguous.
Geoff
On 28/06/2008, at 2:59 AM, Don Ryan wrote:
On 26 Jun 2008, at 23:31, Geoff Callender wrote:
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. Homet:pagelink>
- Embedded components, eg. href="#">Home
- Invisible instrumentation, eg. Home
with
@Component(id = "index", parameters = {"page=Index"})
@SuppressWarnings("unused")
private PageLink _index;
I don't recall this three-way split being introduced. In fact, the
second and third are, to my understanding, both examples of what has
been termed "invisible instrumentation". You can add just a t:id or
just a t:type or you can add both. In cases where you have added a
t:id without the t:type, you must include the annotated field in the
page class.
But really, my point here was to that I think the terminology needs
to be improved, to help newcomers get to grips with the framework
more quickly. (There's nothing like a slightly inaccurate piece of
terminology to cause newbies to hit roadblocks.) I would contend
that the above three terms are all quite poor:
"Components as elements". Well, all components correspond to some
element in the template, so this isn't being specific at all. The
issue is whether they're Tapestry elements or HTML elements.
"Embedded components". Embedded in what? The template? Then ditto as
to the previous point.
"Invisible instrumentation". As I pointed out in my previous post,
both techniques for instrumenting a Tapestry template are invisible
in a rendered browser view, so this is again a bad piece of
terminology.
I think that the Component Templates page in the User's Guide could
do with a re-write to reflect the two possible ways of instrumenting
a template:
(i) Adding Tapestry elements
(ii) Adding attributes to HTML elements
These two terms are the best I can come up with to express the fact
that there are two ways of doing it. (Maybe someone can be more
succinct and accurate.) Also, I think this should be near the top of
the Component Templates page, rather than explaining templates in
terms of Tapestry elements and then have a quick "oh, by the way,
there's also another way of doing it..." near the bottom. I'd be
happy to contribute a draft.
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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [T5] Template previewability
Well, Insert is a terrible name :-)
There's already OutputText (for formatted output). Perhaps FormatText
would have been a better name in retrospect.
On Fri, Jun 27, 2008 at 10:06 AM, Don Ryan <[EMAIL PROTECTED]> wrote:
>
> On 26 Jun 2008, at 20:28, Howard Lewis Ship wrote:
>
>> There's some gaps waiting to be filled (not abandoned, just prioritized a
>> bit lower than more urgent bug fixes).
>
> That's great to hear. Thanks.
>
>> If you want to use T4 style, how about:
>>
>>
>>
>> public class Output {
>> @Parameter (required=true)
>> private String value;
>>
>> boolean beginRender(MarkupWriter writer) {
>>if (value != null) writer.write(value);
>>
>> return false; // skip body
>> }
>> }
>
> Thanks. I have a similar little component. As a total aside, I feel
> compelled to say that Output is a really terrible name for a component. Just
> about every component outputs something so the name is providing next-to-no
> information. (I called mine Text, by the way.)
>
> 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]
Re: [T5] Template previewability
On 26 Jun 2008, at 20:28, Howard Lewis Ship wrote:
There's some gaps waiting to be filled (not abandoned, just
prioritized a bit lower than more urgent bug fixes).
That's great to hear. Thanks.
If you want to use T4 style, how about:
public class Output {
@Parameter (required=true)
private String value;
boolean beginRender(MarkupWriter writer) {
if (value != null) writer.write(value);
return false; // skip body
}
}
Thanks. I have a similar little component. As a total aside, I feel
compelled to say that Output is a really terrible name for a
component. Just about every component outputs something so the name
is providing next-to-no information. (I called mine Text, by the way.)
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]
Re: [T5] Template previewability
On 26 Jun 2008, at 23:31, Geoff Callender wrote:
Are you sure? What about...
A
The core Output component in T5 has a required format parameter, so
the above will throw an exception. The Output component is useful for
things like dates and interpolating values into messages, but a
slightly bigger beast than I was talking about. I have a simpler Text
component of my own but felt that at some stage I'll probably rip out
all occurrences and replace with whatever the core T5 equivalent is.
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. Homet:pagelink>
- Embedded components, eg. href="#">Home
- Invisible instrumentation, eg. Home
with
@Component(id = "index", parameters = {"page=Index"})
@SuppressWarnings("unused")
private PageLink _index;
I don't recall this three-way split being introduced. In fact, the
second and third are, to my understanding, both examples of what has
been termed "invisible instrumentation". You can add just a t:id or
just a t:type or you can add both. In cases where you have added a
t:id without the t:type, you must include the annotated field in the
page class.
But really, my point here was to that I think the terminology needs
to be improved, to help newcomers get to grips with the framework
more quickly. (There's nothing like a slightly inaccurate piece of
terminology to cause newbies to hit roadblocks.) I would contend that
the above three terms are all quite poor:
"Components as elements". Well, all components correspond to some
element in the template, so this isn't being specific at all. The
issue is whether they're Tapestry elements or HTML elements.
"Embedded components". Embedded in what? The template? Then ditto as
to the previous point.
"Invisible instrumentation". As I pointed out in my previous post,
both techniques for instrumenting a Tapestry template are invisible
in a rendered browser view, so this is again a bad piece of terminology.
I think that the Component Templates page in the User's Guide could
do with a re-write to reflect the two possible ways of instrumenting
a template:
(i) Adding Tapestry elements
(ii) Adding attributes to HTML elements
These two terms are the best I can come up with to express the fact
that there are two ways of doing it. (Maybe someone can be more
succinct and accurate.) Also, I think this should be near the top of
the Component Templates page, rather than explaining templates in
terms of Tapestry elements and then have a quick "oh, by the way,
there's also another way of doing it..." near the bottom. I'd be
happy to contribute a draft.
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]
Re: [T5] Template previewability
(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
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...
A
(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:
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. Home
- Embedded components, eg. href="#">Home
- Invisible instrumentation, eg. Home
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 element to be an If
component:
Should only appear sometimes
I could then control whether or not the 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 or a t:type="if">. 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 Sc
Re: [T5] Template previewability
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 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:
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
>
> (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:
>
> 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 element to be an
> If component:
> Should only appear sometimes
> I could then control whether or not the tag itself render
