Ok - one last convincing attempt :) and then I'll let it go.
Like many developers, my current situation is to work with a designer. Two
principles this designer adheres to include - 1) collocate the links or
actions on the screen for the user and 2) try to generate some rhythm, if
possible, by placing actions or links in a consistent place from page to
page (menus, etc).
1) refers to keeping related actions like SUBMIT, CANCEL, RESET, CLEAR,
EDIT, etc together and with the data as opposed to scattering them on the
screen before, after and outside of the data making it difficult for the
user to intuit their relationship to the data. This has to do with spatial
relationship gobbly-gook.
2) refers to from page to page, keep the menu on the top or the left. Keep
the Submit buttons on the lower left of the div, etc. Kind of like a page
rhythm. Soomething like how on a portal, each block or element has menus, Xs
etc in the same spot (a top bar for each block if you will).
In my case, I think I incorrectly started using BeanEditForm for one of the
edit screens in this app and by default, it places the SUBMIT button in the
bottom left of the bright yellow box. To the design's first point, I needed
to put CANCEL, BACK and DELETE buttons on the page and he prefers that they
be near the SUBMIT button - so I used the t:Parameter for each of these and
it worked out as he needed.
Recently, I had to simply Display the contents of an entity and include an
explicit EDIT button. Since the users were already used to the BeanEditForm
and the lower left location of the SUBMIT button, that is where he requested
I put the EDIT button. So, I started with the t:BeanDisplay and used a
t:Parameter for the EDIT button.
Even though both Components display their native properties in 2 columns -
and both components put the textual label on the left and the component
specific value on the right - and both components draw big boxes around the
entire component using different background colors to differentiate them
(ie: they look very similar for the most part) .... out of the box, they do
not render t:Parameter's consistently.
I guess I understand these particular components were not built to use this
way and that technically, you're suggesting it'd be difficlt to pull this
off. Either removing the LABEL that t:beandisplay forces or adding a LABEL
that t:beanedit (or t:beaneditform) leaves off (by LABEL, I don't mean html
- I mean key or title or whatever you call the left hand column of the
rendered display.
>> 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.
Functionally, I think this works - but to use these components in a
commercially designed product ... I can't really tell the designer "put them
after the component, not inside" just because my framework makes that easy.
Ah well ... did that spiel convince you ;) how cool/reusable and applicable
such a change would be? It is probably a big mind shift from the original
point of those components - but I sorta thinks will become necessary. Up and
coming frameworks like Grails auto-generate Show, List and Edit screens for
the developer - and the edit.gsp and show.gsp screens are laid out very
similar. They generate action buttons and collocate them with the data you
are editing. (They generally do not auto-generate buttons in the upper right
corner of the header to edit data that is displayed in the middle of the
show.gsp screen.)
At any rate, I'm not suggesting we change anything - I think I'm making a
case to write my own first component(s)!
Good food for thought!
Thanks,
-Luther
On Wed, Feb 18, 2009 at 12:26 PM, Thiago H. de Paula Figueiredo <
thiag...@gmail.com> wrote:
> Em Wed, 18 Feb 2009 13:58:46 -0300, Luther Baker <lutherba...@gmail.com>
> escreveu:
>
> 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}
>>
>
> Take a look at the generated HTML. BeanEditor and BeanEditForm generate
> label tags through the Label component.
>
> B) If I add a t:Parameter called *whazoo* to either BeanDisplay or
>> BeanEditForm I have explicitly given the LABEL and VALUE. Right?
>>
>
> BeanEditForm and BeanEditor, not BeanDispay.
>
> And it does just this with the BeanDisplay (although it uses the dd family
>> of tags).
>>
>
> That's the difference.
>
> I'm not sure why you think it would be hard to generate the label.
>>
>
> The Label component has a required parameter, for, that receives a
> component.
>
> Are you referring here to a different label than the one we explicitly
>> provide in the t:Parameter name?
>>
>
> When I mean label, I'm talking about the HTML tag.
>
> What I'm suggesting is that it *could* display a label as well as it is
>> explicitly provided.
>>
>
> The label tag must be used paired with a form field. It shouldn't be used
> as the label of a piece of text.
>
> 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.
>>
>
> They can look the same, but their completely different, having different
> parameters and semantics. That's the whole point.
>
> Hope you don't think I'm being argumentative. It is sometimes difficult to
>> succinctly make a point via emails.
>>
>
> It's quite hard, actually.
>
> --
> Thiago H. de Paula Figueiredo
> Independent Java consultant, developer, and instructor
> http://www.arsmachina.com.br/thiago
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
>
