Tapestry
  1. Tapestry
  2. TAPESTRY-1633

PropertyDisplayContext should expose the id/propertyName of the currently rendering property

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 5.0.5
    • Fix Version/s: 5.0.6
    • Component/s: None
    • Labels:
      None
    • Environment:
      any

      Description

      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.

      1. 1633.patch
        2 kB
        Robert Zeigler

        Activity

        Hide
        Robert Zeigler added a comment -

        patch adds properties for both the id and the property name.
        An alternative approach might be to define a service for creating the contexts which GridCell would use.
        Then the interface for the context can be the same, but applications which need more information in the context have the chance to add it.

        Show
        Robert Zeigler added a comment - patch adds properties for both the id and the property name. An alternative approach might be to define a service for creating the contexts which GridCell would use. Then the interface for the context can be the same, but applications which need more information in the context have the chance to add it.
        Hide
        Howard M. Lewis Ship added a comment -

        I've been trying to be faithful to the concept of YAGNI (You Aint Gonna Need It) and only build into components and services the the functionality that is absolutely necessary. I'm fully open to extending APIs, but I prefer to do so when there's a justification; some reasonable scenario that isn't possible as currently coded. So ... what's the story here? Why do you need this feature?

        Show
        Howard M. Lewis Ship added a comment - I've been trying to be faithful to the concept of YAGNI (You Aint Gonna Need It) and only build into components and services the the functionality that is absolutely necessary. I'm fully open to extending APIs, but I prefer to do so when there's a justification; some reasonable scenario that isn't possible as currently coded. So ... what's the story here? Why do you need this feature?
        Hide
        Robert Zeigler added a comment -

        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.

        Show
        Robert Zeigler added a comment - 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.

          People

          • Assignee:
            Howard M. Lewis Ship
            Reporter:
            Robert Zeigler
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development