[jira] [Updated] (CONNECTORS-762) Consider adding ability for connectors to support multiple UI paradigms

["Karl Wright (JIRA)" <ji...@apache.org>]

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

Karl Wright updated CONNECTORS-762:
-----------------------------------
    Affects Version/s:     (was: ManifoldCF 2.0)
                       ManifoldCF next
        Fix Version/s: ManifoldCF next

> Consider adding ability for connectors to support multiple UI paradigms
> -----------------------------------------------------------------------
>
>                 Key: CONNECTORS-762
>                 URL: https://issues.apache.org/jira/browse/CONNECTORS-762
>             Project: ManifoldCF
>          Issue Type: New Feature
>          Components: Framework core
>    Affects Versions: ManifoldCF next
>            Reporter: Karl Wright
>            Assignee: Karl Wright
>             Fix For: ManifoldCF next
>
>
> Thinking over the problem of how to allow customers and integrators to write their own UI for ManifoldCF, I came up with the following design.  The design almost certainly would break backwards compatibility, so it would have to be considered a ManifoldCF 2.0 feature.
> Use a decorator paradigm to allow MCF to be extended in such a way as to allow multiple UI's to be written for the framework.
> The way I propose that this will work is the following:
> (1) IConnector will be revised to no longer include UI methods
> (2) IStandardConfigurationUI will be created which describes the UI methods for configuration, as well as IConfigurationUI which is the base
> (3) IRepositoryConnector will be revised to pull out the specification UI methods
> (4) IStandardSpecificationUI will be created which describes the UI methods for specification editing, as well as ISpecificationUI which is the base
> (5) IOutputConnector will be revised to pull out the output specification UI methods
> (6) IStandardOutputSpecificationUI will be created, as well as IOutputSpecificationUI which is the base
> (7) Four additional configuration UI tables will be created, and two specification UI tables, for UI class registration.  Rows in these tables will
> be "owned" by the associated registered connectors.  connectors.xml will also be revised to include UI class registration.  UI classes are described
> by the connector class they are associated with as well as the specific kind of UI they represent, probably represented by the name of a java interface,
> e.g. IStandardConfigurationUI.
> (8) IConfigurationUI will include no common methods at all.  ISpecificationUI will include a setter method for the connector class instance, e.g.
> "set(IRepositoryConnector connector).  IOutputSpecificationUI will include a similar setter method.  OR: an IRepositoryConnector instance
> is included in all method signatures (which would guarantee that the instance had been grabbed prior to UI use).  Think about this...
> (9) UI classes are instantiated as needed, and are discarded right after they are used.  Therefore there is no attempt to pool them.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)