This wiki does not contain official documentation and is currently deprecated and read only. Please try reading the documentation on the Liferay Developer Network, the new site dedicated to Liferay documentation. DISCOVER Build your web site, collaborate with your colleagues, manage your content, and more. DEVELOP Build applications that run inside Liferay, extend the features provided out of the box with Liferay's APIs. DISTRIBUTE Let the world know about your app by publishing it in Liferay's marketplace. PARTICIPATE Become a part of Liferay's community, meet other Liferay users, and get involved in the open source project. The Proposals Wiki has been deprecated in favor of creating Feature Requests in JIRA. If you wish to propose a new idea for a feature, visit the Community Ideas Dashboard and read the Feature Requests Wiki page for more information about submitting your proposal.
« 返回到 FrontPage
Refactoring Strategy - Public Contract
Table of Contents [-]
General Architecture #
The diagram below gives some definition to the organization of the API or API's. In order to allow liferay to evolve over time without breaking contract with extensions and plug-ins as well as it evolves its 6 year old source base for the next 6 years I am proposing a public API that would sit above the existing API which would become the internal API. This is akin to the Win32 API which sits on top of NT's internal API calls. The internal contact is allowed to change at a much greater frequency then the public API's. This is because the public APIs are a contract with the Liferay community. Implementation of the public API is in gerneral only adapers to the underlying internal API calls.
25365 查看
