Dear Wiki user, You have subscribed to a wiki page or wiki category on "Lenya Wiki" for change notification.
The following page has been changed by GregorRothfuss: http://wiki.apache.org/lenya/ProposalContentModel ------------------------------------------------------------------------------ The premise of this proposal is that extending the core API with several additional explicit types (meaning interfaces, abstract classes) can provide a basis for implementing several key functionalities. Note that - * this proposal is not about the question "how is this knowledge accessed (and created)" - that is more an issue of the Sitemap2JavaApiContractProposal. + * this proposal is not about the question "how is this knowledge accessed (and created)" - that is more an issue of the ProposalSitemap2JavaApiContract. * this proposal tries to take a fresh look at things; whereas some existing interfaces and classes in Lenya already contain parts of what is discussed here. This proposal addresses the following issues: - * the assumption about documents currently is that they are made of a single part (the page). However, real documents may consist of several, independently managed content parts: some parts may be static, others dynamic; some parts may have other access rights then others (example: news part in the homepage of a publication). Currently in Lenya, this is only possible by customized sitemap manipulation, but not supported out-of-the-box; i.e. the core has no 'knowledge' about composed documents, nor can it offers GUIs to create documents by composing them.(See also ["XIncludeAggregationProposal"]) + * the assumption about documents currently is that they are made of a single part (the page). However, real documents may consist of several, independently managed content parts: some parts may be static, others dynamic; some parts may have other access rights then others (example: news part in the homepage of a publication). Currently in Lenya, this is only possible by customized sitemap manipulation, but not supported out-of-the-box; i.e. the core has no 'knowledge' about composed documents, nor can it offers GUIs to create documents by composing them.(See also ["ProposalXIncludeAggregation"]) * the above issue also means that content can not (easily) be reused in different documents. Solving the issue above would solve this issue at the same time. * further, we need a support for centralized asset management. Currently, an area for "central" assets can be created, and individual documents can refer to them by URL. But there is no knowledge within the CMS about such relations, so no support for consistency (publishing together, deleting, ...) * we probably also want a centralized link management, as a typical feature expected from a CMS --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
