I see where you are coming from, but to "fix" it would break its usage
by others. I would fix BeanDisplay by making it the Block's
responsibility to render the "label" (not a <label> element) and the
value, just as BeanEditor requires its blocks to do.
Again, I don't see this happening; it will be necessary to devise a
new component for this purpose and change how contributions are made
to it. I'm afraid we're kind of stuck with it.
On Wed, Feb 18, 2009 at 8:58 AM, Luther Baker <lutherba...@gmail.com> wrote:
> 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
>>
>>
>
--
Howard M. Lewis Ship
Creator Apache Tapestry and Apache HiveMind
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
