[
https://issues.apache.org/jira/browse/TAPESTRY-1633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12511190
]
Robert Zeigler commented on TAPESTRY-1633:
------------------------------------------
I think that the most compelling argument I can give regarding why this
information is needed in the PropertyDisplayContext is this: Suppose GridCell
took a parameter of PropertyDisplayContext, instead of the current
PropertyModel. Could GridCell do the job that it does? It wouldn't be able to
look up t:parameters, it wouldn't be able to add the css-class to teh table
cell, etc. If GridCell can't do it, why should we expect that any reasonable
complex rendering logic would be able to do it? What if I want to add a
client-id to a link surrounding a cell value, based on the property name, for
css or javascript purposes? I would also love to create an editable table,
rather than just a view table... can't do that with PropertyDisplayContext...
Frankly, my preference would be for PropertyDisplayContext to go away, and for
PropertyEditContext to become PropertyContext. All of that said, what follows
is the specific issue that I was butting up against:
I was building a generic "view" table/page. It handles display of all of the
objects in the application. So it acts like there are n "view" pages, one for
each object type, but there's only one page. I was making links between
related objects. For example:
User:
First Name | Last Name | Email | Role
John Doe ... admin
The "admin" would link back to the view page, for the but display UserRole
objects, filtered for admin, so clicking admin would give you something like:
User Role:
Name | X | Y | Z
admin ... | ... | ...
With the current setup, things work reasonably well for one-to-one
relationships; I can put the object type and object id into the context for the
page link, and things work well enough.
But you run into issues with to-many links, which I handle by creating a single
link displaying some summary information about hte relationship (number of
related objects).
I have data like:
Student:
First Name | Last Name | Attendance
... ... 3000 records
I really don't want to place the pk of huge numbers of records into the context.
What would be ideal is to place id of the parent object, plus information about
which relationship to display.
If I was creating a separate view page for each of the objects, I could easily
accomplish this using the t:parameter stuff.
But I'm not. So instead, I used the BeanBlock contributions to contribute a
renderer for the type "list".
But then it became the question of "list of what"? No problem... my object
model is pretty flat... I can look at the list
provided by the PropertyDisplayContext. If it's empty, there's nothing to
render, anyway, so that's not a concern. So I can grab the first object in the
list,
and look up relationship information between the source object type and target
object type. (I use cayenne as my ORM. It let's you do this sort of thing very
easily).
This normally works fine. But you run into issues when you have multiple
relationships between two object types. For example, the application I'm
working on is supposed to keep a history of application events... edits, adds,
etc. So I have a relationship from users to "UserHistory" like "user performed
transactions", which is all of the stuff that the user /did/. But I'm also
supposed to track the edit events on users, which means I have /another/
relationship between users and UserHistory, the history.
If I look at the list of objects for either relationship, I am going to find a
"UserHistoryEntry" object. How can I distinguish which set of objects to
filter for later? Given the current PropertyDisplayContext, I can't store
relationship information anywhere. Once again, given that there will be
potentially hundreds to thousands of UserHistoryEvent objects in EACH of those
relationships, encoding the target entities (or their pk's) into the url is
ugly and really not scalable. But if I had the relationship name available
during the render, I could use that to encode a link which can discriminate
between which sets of objects to filter.
> PropertyDisplayContext should expose the id/propertyName of the currently
> rendering property
> --------------------------------------------------------------------------------------------
>
> Key: TAPESTRY-1633
> URL: https://issues.apache.org/jira/browse/TAPESTRY-1633
> Project: Tapestry
> Issue Type: Improvement
> Affects Versions: 5.0.5
> Environment: any
> Reporter: Robert Zeigler
> Priority: Minor
> Attachments: 1633.patch
>
>
> PropertyDisplayContext only makes the current property value available. It
> would be nice to also have the property name or property id available, as
> well, like it is in the PropertyEditContext.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
