No problem.
I appreciate the feedback.
Time permitting, I'm going to try my hand at it - especially if others would
find value in the effort.
-Luther
On Wed, Feb 18, 2009 at 1:33 PM, Howard Lewis Ship <hls...@gmail.com> wrote:
> 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
>
>
