'. '

AssemblableTypes

From APIDesign

(Difference between revisions)
Jump to: navigation, search
(New page: By splitting APIs into multiple modules one increases their flexibility. The API become independent and can be used in new contexts, without the rest of the APIs being pres...)
Line 1: Line 1:
-
By splitting [[API]]s into multiple [[module]]s one increases their flexibility. The [[API]] become independent and can be used in new contexts, without the rest of the [[API]]s being present. However one also complicates the usage, as for some, original (in case the [[API]] used to be present as a whole) [[usecase]]s, the users need to try harder to make the [[API]]s work together. That is indeed not [[good]] (as it increases '[[time to market]]). This article describes one of my advantures where I had to deal with similar situation.
+
By splitting [[API]]s into multiple [[module]]s one increases their flexibility. The [[API]] become independent and can be used in new contexts, without the rest of the [[API]]s being present. However one also complicates the usage, as for some, original (in case the [[API]] used to be present as a whole) [[usecase]]s, the users need to try harder to make the [[API]]s work together. That is indeed not [[good]] (as it increases [[Time To Market]]). This article describes one of my advantures where I had to deal with similar situation.
== Setup ==
== Setup ==

Revision as of 06:26, 21 April 2011

By splitting APIs into multiple modules one increases their flexibility. The API become independent and can be used in new contexts, without the rest of the APIs being present. However one also complicates the usage, as for some, original (in case the API used to be present as a whole) usecases, the users need to try harder to make the APIs work together. That is indeed not good (as it increases Time To Market). This article describes one of my advantures where I had to deal with similar situation.

Contents

Setup

There are following modules In the NetBeans APIs:

  • Text API - contains class like CloneableEditorSupport.Pane and some of its implementations and can open editor for any source of characters
  • MultiView API - depends on Text API and provides another implementation of the pane which can be created by MultiViewFactory.
  • Loaders API - which depends on Text API and connects it with real files on disk via functionality provided by DataObject.

Users of the NetBeans API People often create their own DataObject implementations to represent textual data. Good, there is support for that in the Loaders API. There is however common requirement to show not only editor, but also other view, e.g. to use MultiView API.

However Loaders API knows nothing about MultiView API and MultiView API knows nothing about Loaders API. Their only common dependency is the Text API. Can I write a wizard to generate simple, maintainable code that defines DataObject represented by a MultiViewElement?

History

TBD

Improvements

TBD

Result

TBD

Personal tools
buy