Improving datamanager re-use and flexibility in the admin


#1

We have the crudadmin scaffolder in the dev tools, however, having just developed https://presidecms.atlassian.net/browse/PRESIDECMS-52 (admin view record screens), it is clear to me that we could abstract a lot of the data manager components out and allow you to re-use and replace them more readily.

I am thinking along the lines of at least the following possible attributes on any object to allow us a flexible system of viewing, editing, adding, deleting records in the admin. All attributes would be optional and will allow you to either override a small piece of regular datamanager, or allow you to use core datamanager views/actions outside of datamanager and with much less code than currently necessary:

@adminBuildListingLinkHandler            - a handler to build the URL for viewing a listing of the object
@adminBuildListingRecordsLinkHandler     - handler to build URL that can be used to fetch records for grid listing
@adminListingViewlet                     - a custom viewlet for building the listing grid screen for an object
@adminListingActionsViewlet              - a custom viewlet for showing grid actions for an object
@adminBuildViewHistoryLinkHandler        - a handler to build the URL for viewing a history of a record for the object
@adminViewHistoryViewlet                 - a custom viewlet for building the view record history view for an object record
@adminBuildAddRecordLinkHandler          - a handler to build the URL for a user to add a new record (display form page)
@adminBuildAddRecordActionLinkHandler    - a handler to build the URL for a user to add a new record (action)
@adminAddRecordViewlet                   - a custom viewlet for displaying the add record form for an object
@adminAddRecordActionHandler             - a handler to perform the adding of a record
@adminBuildEditRecordLinkHandler         - a handler to build the URL for a user to edit a record (display form page)
@adminBuildEditRecordActionLinkHandler   - a handler to build the URL for a user to edit a record (action)
@adminEditRecordViewlet                  - a custom viewlet for displaying the edit record form for an object
@adminEditRecordActionHandler            - a handler to perform the editing of a record (action)
@adminBuildDeleteRecordActionLinkHandler - a handler to build the URL for a user to delete a record (action)
@adminDeleteRecordActionHandler          - a handler to perform the deleting of a record (action)
@adminRootCrumbtrailHandler              - a handler to build crumbtrail in the admin for an object - this way, can use data manager logic but different nav
@adminPermissionCheckHandler             - a handler to check read,edit,delete,viewhistory, etc. permissions for an object. Use this to avoid regular datamanager permissions. 

Note alternatives such as @adminBuildAddRecordActionLinkHandler and @adminAddRecordViewlet would likely not both be used in one object - you might use just the viewlet definition to change how the core datamanager add record screen appears, but use the link generator handler to provide a completely different main handler/URL for adding a record.

Thoughts appreciated!


#2

Update: Have created https://presidecms.atlassian.net/browse/PRESIDECMS-1080 in which to do this development.


#3

Alternative / additional idea. Create a convention of:

/handlers/preside-objects/(object_name).cfc

This can then be a handler for your preside object that has all sorts of hooks (pre/post edit, delete, etc. as well as all the things above).

Thoughts?


#4

personally Iā€™d prefer the folder convention style since there is the risk to end up with a confusing amount of annotations in the header. One other suggestion would be to extend the annotation DSL to have some kind of grouping. Here is an annotation header from a PHP function (Symfony framework):

/**
     * displays the footer links
     *
     * @param string $follow            Follow-Links oder nicht?
     * @param array  $footerLinksToHide Footer-Links die versteckt werden sollen
     *
     * @return string htmltemplate
     *
     * @Route("/includes/footer_links/{follow}/{footerLinksToHide}",
     *          requirements={
     *              "page"="\d+",
     *              "host"="%idg_www.hosts%",
     *              "tld"="%idg_www.top-level-domain%"},
     *          defaults={
     *              "host"="%idg_www.hosts%",
     *              "tld"="%idg_www.top-level-domain%",
     *              "footerLinksToHide"=false
     *          },
     *          host="www.{host}.{tld}")
     * @Method({"GET"})
     */
    public function footerLinksAction($follow, $footerLinksToHide)

I could imagine something like this:

@adminBuild (
    viewHistoryViewlet = foobar,
    addRecordActionLinkHandler = baaaaar
)

in order to have some kind of visual grouping.