Uploaded image for project: 'Sakai'
  1. Sakai
  2. SAK-42655

Textarea > elfinder > implement SakaiFsServiceFactory.toolVolumes and related bean definitions using EntityProvider registrations



    • Type: Feature Request
    • Status: RESOLVED
    • Priority: Critical
    • Resolution: Duplicate
    • Affects Version/s: 19.3, 20.0
    • Fix Version/s: None
    • Labels:
    • Test Plan:

      Please add a Test Plan here.

      Please add a Test Plan here.


      See SCO-166 for context, and to see what's necessary to implement entity linking with elfinder (https://github.com/sakaiproject/sakai/pull/7442).

      Since the switch to elfinder the UI looks much nicer than before, however in terms of code implementation it's actually much worse compared to what we had before.

      In the old system all you had to do was code your EntityProvider and add a tiny string in a message bundle in core Sakai code. Your EntityProvider was completely isolated in your tool (even a contrib tool!), and if you didn't deploy that tool to your Tomcat nothing bad would happen. The picker would continue to work with the EntityProviders that were registered on startup.

      In the new paradigm, you have your EntityProvider in your tool code, and then you also need to provide both a FsItem and SiteVolumeFactory for your entity in the textarea project. This introduces functionality duplication between your EntityProvider and your SiteVolumeFactory, and also between your Entity and your FsItem.

      Now, if you can ignore the voice in your head yelling at you for duplicating stuff in two places, it's not so bad... right? Well, maybe in the case of core tools. However, in the case of a contrib tool the problems get worse. You need to add dependencies to the contrib tool in core Sakai, and now if you don't actually deploy that contrib tool to your Tomcat, it's going to complain at startup, fail to create the SakaiFsService Spring bean and the result is that the elfinder plugin will fail to work at all. You can't link to anything, and you'll get an error message when you click "Browse Server".

      So this leaves us in a situation where we have several undesirables:

      • duplication of functionality between EntityProviders and SiteVolumeFactorys
      • regression in terms of amount of code required to make something linkable
      • tool code leaking into the textarea project, where before everything was isolated in the respective tool
      • core project textarea now has dependencies to all tools that are linkable, including contrib tool(s)
        • this requires any linkable contrib tools to publish build artifacts to maven repositories, so compilation doesn't blow up
      • manual modifications of Spring bean XML to enable/disable contrib tool linkable entities

      It was much nicer before where you could just whip up your EntityProvider, and the entity picker would use all registered Providers for integration into the picker.

      To get back to this, the core SiteVolumeFactory would need to be refactored for use against the EntityBroker's registered EntityProviders, and dynamically create the necessary objects for each type of entity (both entity specific SiteVolumeFactory and FsItem. The base SiteVolumeFactory would need to provide translation to/from the EntityProviders so that the existing functionality of the providers can be leveraged, rather than duplicated. This dynamic behaviour would also do away with the static XML bean definition. At which point, the various existing SiteVolumeFactorys and FsItems could be removed, and everything would be isolated properly again.

        Gliffy Diagrams



              Issue Links



                  maintenanceteam Core Team
                  bjones86 Brian Jones
                  0 Vote for this issue
                  1 Start watching this issue



                      Git Integration