[jira] [Updated] (ISIS-2676) Better approach to ordering columns in tables (properties + actions)

["Andi Huber (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/ISIS-2676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andi Huber updated ISIS-2676:
-----------------------------
    Issue Type: Wish  (was: New Feature)

> Better approach to ordering columns in tables (properties + actions)
> --------------------------------------------------------------------
>
>                 Key: ISIS-2676
>                 URL: https://issues.apache.org/jira/browse/ISIS-2676
>             Project: Isis
>          Issue Type: Wish
>          Components: Isis Core, Isis Viewer Wicket
>    Affects Versions: 2.0.0-M5
>            Reporter: Daniel Keir Haywood
>            Priority: Major
>
> re: [https://the-asf.slack.com/archives/CFC42LWBV/p1620925090232000?thread_ts=1620883840.222800&cid=CFC42LWBV]
> what we have already, of course, is TableColumnOrderService, which is a terrible but rather handy kludge.... it works surprisingly well.
> In olden days, before we had layout.xml, the (recently deceased) {{@MemberOrder}} sufficed both for the order of fields on an object form, and for the order of columns in a table.  But we are well beyond that now.  So I think that the table column order should be specified through a completely different mechanism.
> Suggestions:
> 1. One is to extend {{@PropertyLayout}} with a new element just for column order, eg {{@PropertyLayout(columnOrder="1.0"). }}We would use dewey decimal to allow subtypes to "slot" any columns in as nec.
> 2. Another annotation-based idea is something like:
> @DomainObjectLayout(columnOrderBy=CustomerColumnComparator.class)
> public interface Customer {
> }
> 3. A different idea is to specify this in a separate file, eg "ApplicationUser.columnOrder.txt".  That could then be changed at runtime, same as layout files, and could support commenting out as well in order to hide columns.
> A separate ongoing spike is to allow actions also being in the table.  So whatever option, it would be nice to anticipate this.  
> ~~~
> Riffing on (3), each row could represent either a property or an actionId.  We would provide a service to download it (same as Object_downloadLayout currently).
> eg:
> {code:java}
> # properties (this row starts with a '#' so is a comment and is ignored)
> firstName
> lastName
> emailAddress
> # actions.  These would be shown in a separate column as a drop-down.
> resetPassword    # allow comments here also.  
> updateEmail      
> updateFamilyName
> updateGivenName
> updateKnownAs
> {code}
>  
>  
>  



--
This message was sent by Atlassian Jira
(v8.20.7#820007)