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
On 26 Jun 2008, at 23:31, Geoff Callender wrote:
Are you sure? What about...
span t:type=output value=student.gradeA/span
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. t:pagelink page=IndexHome/
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;
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
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:
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
}
}
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
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:
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
}
}
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
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:
snip
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=IndexHome/
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;
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]
[T5] Template previewability
[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=fooShould 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
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 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=fooShould only appear
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 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.gradeA/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=IndexHome/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=fooShould 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
