I take a vacation in a hospital after a high-speed car crash and this thread takes tangents I could not dream in my worst nightmare.
=== "Asset is a financial term." Yes, accountants use the word to mean anything of positive value, as opposed to "Liabilities" which are anything of negative value. Lenya 1.2's GUI used the term for anything uploadable stored as a file. I suggest using the term for any user-driven content that is not XML. That supersets the Lenya 1.2 usage in a way understandable by the public. === "Assets as part of Pages." "Pages contain one or more Documents." These statements confuse storage and development needs with presentation. A Document is XML. An Asset is not XML. - In Lenya 1.2, Assets were associated with a Document. This causes major headaches for users because they must use the docID in the URL to make a link. - I suggested making Assets children of Publication/Content, just like Documents. Then both Documents and Assets can have a parent class that provides multiple languages (Translations) and versions (Revisions). The major difference is that Documents can be processed by XSL statements (map:translate). It is impossible to do XSL Transformations on non-XML data. A "Page" is the unit a visitor sees on the Website. Pages are created by Modules. A Module can aggregate Documents and the results of other Modules to create a Page. The Page can include links to Assets and other Pages. Pages are dynamically generated by Modules. Although it is possible (and useful for testing) to have a Module that dumps a Document to the visitor, no Website would use that Module in production. All decent Websites provide some navigation, preferably without dead ends (one reason to avoid PDFs), and the minimum production Module should add a "Home" or "Back" link to every Page. The important point is that "Page" is not something storable in Lenya (except in the non-functional cache where the HTML and other content generated by Lenya is stored for performance.) === A PDF is not a Document, because a PDF is not XML. Most PDFs would be uploaded as Assets. A Module may transform a Document (or multiple Documents and possibly Assets) into a PDF. The result could be saved in Lenya as an Asset, but performance could be improved without creating another static resource by saving the results in the non-functional cache. The URL of the PDF would be the URL of the PDF-creating Module and any parameters it requires to create the specific PDF. Implementation: If a PDF is uploaded, then it is an Asset. Publication/Content/Asset[type="PDF"] If the PDF is dynamically generated, then it is accessed though a Module: http://lenyaServer/myPub/PDFModule/someParameters The parameter(s) could be: - a single Document identifier that is transformed to PDF using XSL. - several resources (Document and Assets) sequentially added to PDF. - a key identifying a configuration document. - anything else imaginable. === It seems likely the parent Node of Documents and Assets will be named "Content", and the superclass for Documents and Assets will be named "ContentItem" (although I still prefer "Resource" to reduce the word count and remove the capital 'I'): Publication/Content/ContentItem[subclass="Document|Asset"]/Translation/Revision solprovider --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
