[
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: ManifoldCF 2.0
> 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 2.0
> Reporter: Karl Wright
> Assignee: Karl Wright
>
> 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
