Ah ... so follow me here:
A) For an Entity with simple String properties, etc, both the t:BeanEditForm
and the t:BeanDisplay render:
* LABEL: {component-specific-value}
LABEL: {component-specific-value}
*
B) If I add a t:Parameter called *whazoo* to either BeanDisplay or
BeanEditForm I have explicitly given the LABEL and VALUE. Right?
C) Example: adding an "edit" t:Parameter
<t:Parameter name="edit"><t:PageLink page="topic/EditTopic"
context="topic.id">edit</t:PageLink></t:Parameter>
Can easily produce
*<label>Edit:</label> <a href="topic/EditTopic">edit</a>*
And it does just this with the BeanDisplay (although it uses the dd family
of tags).
> no way for them to bind a Label component to a component you will provide
I'm not sure why you think it would be hard to generate the label.
Are you referring here to a different label than the one we explicitly
provide in the t:Parameter name? Also, maybe I misunderstand but in my
example, the component is at a higher level than the extra t:Parameter.
Maybe I could get more extensive but in my case, I am just throwing in
another 'pseudo' label/value combo here when I use t:Parameter - and I'm
providing both values explicitly.
Given the t:Parameter above, BeanEditDisplay displays:
*<a href="topic/EditTopic">edit</a>*
What I'm suggesting is that it *could* display a label as well as it is
explicitly provided.
To that point - both in or both out. I guess BeanEditForm and BeanDisplay
could consistently display one way or the other. I think you can say that
"technically" they don't do this. Technically, BeanDisplay uses the <dd>
family of tags whereas BeanEditForm uses <div>s and <label>s so it seems to
me that they were NOT written at the same time or with each other in mind
.... and I guess you *could* say the components are completely unrelated and
have no cause or bearing to look like one another.
But they *do* look like each other ... and they *are* related.
So it seems to me that we could step back and now, today, look at them as a
family of components - related but with a slightly different purposes. Its
perfect for a CRUDdy application. Show, Edit, List.
Maybe this is too simplistic of an example but I'd suggest that usage/render
consistency of this family of controls would actually add some value to the
library.
They seem like two sides of the same coin ...
Maybe my example is too simplistic. Just my $0.02 (or 1c :)
Hope you don't think I'm being argumentative. It is sometimes difficult to
succinctly make a point via emails. In this case, I'm basically asking that
either BeanEditForm generate a label (which it explicitly has in the
t:Parameter) like it does for the other innate properties:
<div class="t-beaneditor-row"><label for="edit" id="edit:label">Edit</label>
or that BeanDisplay not display the <dt>LABEL</dt>.
<dt class="edit">Edit</dt>
Nothing too too complicated I hope - just consistency. Admittedly, I am
surprised that the underlying HTML is so different between these two. At any
rate, I think both can have or disregard that label from a t:Parameter.
Sorry for the length here. I hope my argument makes sense.
Thanks,
-Luther
On Wed, Feb 18, 2009 at 6:13 AM, Thiago H. de Paula Figueiredo <
thiag...@gmail.com> wrote:
> I see no inconsistence here. BeanEditForm (and BeanEditor) have a very
> different meaning than Grid and BeanDisplay. One is for editing data,
> the other for displaying data. BeanEditForm and BeanEditor replace the
> whole line because there's no way for them to bind a Label component
> to a component you will provide. If you want edit and delete links in
> a BeanDisplay, put them after the component, not inside. It is meant
> to only display an object. A workaround is to add the following lines
> to your app.properties.
>
> edit-label=
> delete-label=
>
> --
> Thiago
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
>
