Directory Studio
  1. Directory Studio
  2. DIRSTUDIO-167

Show custom icons for various kinds of schema elements while browsing schema data

    Details

    • Type: Wish Wish
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.5.0
    • Component/s: studio-ldapbrowser
    • Labels:
      None

      Description

      It would be pretty cool to map various objectClasses to special icons in Studio so when you browse
      any directory really you can see special icons for those entries of that objectClass like people etc. It
      would be nice to have some configuration capability for this.

      However I would really love it if we had this capability to be able to browse the schema partition and
      recognize metaSchema, metaObjectClass and other meta objectClasses for schema entities. However
      a generalized approach would probably be best.

        Issue Links

          Activity

          Hide
          Pierre-Arnaud Marcelot added a comment -

          Apache Directory Studio version 1.5.0 has been released.

          Show
          Pierre-Arnaud Marcelot added a comment - Apache Directory Studio version 1.5.0 has been released.
          Hide
          Pierre-Arnaud Marcelot added a comment -

          Fixed

          Show
          Pierre-Arnaud Marcelot added a comment - Fixed
          Hide
          Alex Karasulu added a comment -

          I think these issues are somewhat related because if we can create a registry for objectClasses to allow the addition of different kinds of views or icons for STRUCTURAL and AUXILIARY OCs then we can finely control behavoirs in presenting different kinds of entries as well as editing them.

          For example if we had a way to map editors and icons (or icon overlays) to various kinds of objectClasses then we can leverage the synergy of how Java and LDAP handle OC/JC inheritence.

          The key is to figure out how to merge editor fields elegantly through the hierarchy of STRUCTURAL objectClasses while exposing (an expand contract button to reveal) AUXILIARY objectClass fields in the editor. Incidentally later on once we get DITContentRules functional we should look into allowing the user to add AUXILIARY objectClasses to entries.

          With OC editors, and icons (and overlays) registered for various kinds of OCs we would have a pretty rich environment for customizing the behavior of the UI.

          Show
          Alex Karasulu added a comment - I think these issues are somewhat related because if we can create a registry for objectClasses to allow the addition of different kinds of views or icons for STRUCTURAL and AUXILIARY OCs then we can finely control behavoirs in presenting different kinds of entries as well as editing them. For example if we had a way to map editors and icons (or icon overlays) to various kinds of objectClasses then we can leverage the synergy of how Java and LDAP handle OC/JC inheritence. The key is to figure out how to merge editor fields elegantly through the hierarchy of STRUCTURAL objectClasses while exposing (an expand contract button to reveal) AUXILIARY objectClass fields in the editor. Incidentally later on once we get DITContentRules functional we should look into allowing the user to add AUXILIARY objectClasses to entries. With OC editors, and icons (and overlays) registered for various kinds of OCs we would have a pretty rich environment for customizing the behavior of the UI.
          Hide
          Stefan Seelmann added a comment -

          Currently the icons are choosen depending on the RDN attribute type (cn, ou, ...). This was done because when expanding the tree we only fetch the DNs of the child entries, but not its attributes and even not the objectClass attribute. The reason were performance issues and less network traffic.

          But I think in the meantime this has changed. The objectClass attribute is always returned because we need it to see whether an entry is a subentry, alias or referral. So it should be possible to determine the icon by objectClass. And of course a configurable and extendible mapping between objectClasses and icons would be cool.

          Show
          Stefan Seelmann added a comment - Currently the icons are choosen depending on the RDN attribute type (cn, ou, ...). This was done because when expanding the tree we only fetch the DNs of the child entries, but not its attributes and even not the objectClass attribute. The reason were performance issues and less network traffic. But I think in the meantime this has changed. The objectClass attribute is always returned because we need it to see whether an entry is a subentry, alias or referral. So it should be possible to determine the icon by objectClass. And of course a configurable and extendible mapping between objectClasses and icons would be cool.
          Hide
          Alex Karasulu added a comment -

          Use the STRUCTURAL OC to decide and use decorators for AUXILLIARY OC. For example you have files in eclipse but if they are in svn the are decorated with a drive overlay on top of the gif. I think this would be slick
          to do. So basically you would have icons for STRUCTURAL OC and overlays for AUXILLIARY OC.

          Show
          Alex Karasulu added a comment - Use the STRUCTURAL OC to decide and use decorators for AUXILLIARY OC. For example you have files in eclipse but if they are in svn the are decorated with a drive overlay on top of the gif. I think this would be slick to do. So basically you would have icons for STRUCTURAL OC and overlays for AUXILLIARY OC.
          Hide
          Emmanuel Lecharny added a comment -

          We should implement this as an option, for sure. We can even think about specific presentation, with filtering : expose all the users, their groups, etc, with specific icons.

          On the other side, it's important to keep a kind of unicity, and not have a kind of mess with one icon for each OC, as we use 16x16 icons... We should also consider that an entry can have more than one OC.

          Anyways, this is the kind of thing which can be usefull to have.

          Show
          Emmanuel Lecharny added a comment - We should implement this as an option, for sure. We can even think about specific presentation, with filtering : expose all the users, their groups, etc, with specific icons. On the other side, it's important to keep a kind of unicity, and not have a kind of mess with one icon for each OC, as we use 16x16 icons... We should also consider that an entry can have more than one OC. Anyways, this is the kind of thing which can be usefull to have.

            People

            • Assignee:
              Stefan Seelmann
              Reporter:
              Alex Karasulu
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development