El mié, 08-02-2006 a las 13:12 -0500, [EMAIL PROTECTED] escribió: > On 2/8/06, Thorsten Scherler <[EMAIL PROTECTED]> wrote: ... > > I think I should just leave it like this, but: > > > > page -> why that is only html? > > Websites use HTML. It is the primary format for web browsing. Most > pipelines finish with <map:serialize type="html">. It is so common > the type="html" is not necessary because it is the default. I > sometimes serialize as XML for testing, but I do not want visitors to > see it.
Yeah, for lenya ATM you may are right but see e.g. something like forrest where this is not true. I will start very soon a forrest compatible lenya pub where I will drop this focus. Lenya never stated to be *just* a web CMS focusing on editing webpages (html). That may is your assumption from knowing 1.2 but making lenya forest compatible will give you a collection of new outputs out of the box. Some already are available in lenya like OpenOffice and basic OpenFormat support. The idea is to use lenya to manage any kind of content not only webbased on. > The "rss" Module would serialize as XML, but RSS uses "Feeds" > containing "Channels" containing "Items", as well as referring to the > response as a "Document" using the pure XML definition. Here you see that some formats are referring to the response of a request as document (be it the "pure XML definition" or not). Not only RSS but as well e.g. open office, POD and pdf are referring to the response of a request as a "Document". Even you can say "the html document". > > What is the relationship between document and pages? > > Documents are internal units of XML data. see above, why limiting documents to xml? > They are separated by > purpose, type, and security. > > Purpose: one Document contains the list of Contributors, another how > to install Lenya. Different purpose, different document. Hmm, separation by purpose normally brings a different "type". Like in forrest document-v20.dtd is for "normal" docs and faq-v12.dtd for faq documents. I think the type determines the purpose. > > Type: Most documents are XHTML, basic word processed content. A > "product" document contains different (and more rigid) fields. > Different DTD, different document. > > Security: One document can be edited by any editor. "Product" > Documents can only be edited by the inventory maintainer. Different > security requirements, different document. > I agree on type, but security is provided by the overall application controller (lenya). The documents should be only linked in the security component and not know about security itself. > When creating a Page, Lenya can aggregate introduction text from one > Document, a list of products from other Documents, navigation based on > the Publication, and other presentation information. Coming back to the "printed paper industry" (the main user of a CMS!) a paper is *one* peace of a document and not the other way around. The above said *only* makes sense in html. You do not need navigation e.g. in POD or PDF or .... The above re-written: "When creating a content aggregation, Lenya can use different content nuggets like introduction text, a list of products, navigation based on the Publication, and other presentation information." > A Document is a > possible input for creating a Page. A Page can be created from many > Resources, including Documents, Assets, and Modules. (I have a few > "You cannot do that" Pages that are just HTML files piped to the > visitor. Responding to the request does not use any Documents or > special processing.) Well that is exactly what the forrest dispatcher does but for multiple formats (<forrest:view type="css" hooksXpath="/"/> and <forrest:view type="html" hooksXpath="/html/body">) <forrest:views xmlns:forrest="http://apache.org/forrest/templates/1.0"; xmlns:jx="http://apache.org/cocoon/templates/jx/1.0";> <!-- The following variables are used to contact data models and/or contracts. --> <jx:set var="getRequest" value="#{$cocoon/parameters/getRequest}"/> <jx:set var="getRequestExstension" value="#{$cocoon/parameters/getRequestExstension}"/> <!-- CSS View of the request e.g. index.dispatcher.css --> <forrest:view type="css" hooksXpath="/"> <forrest:contract name="branding-theme-profiler"/> </forrest:view> <!-- HTML View of the request (e.g. index.html)--> <forrest:view type="html" hooksXpath="/html/body"> <!-- @type defines this structurer to html. @hooksXpath defines where all hooks will be injected (as prefix). --> <forrest:contract name="branding-css-links"> <!-- More information around this contract http://marc.theaimsgroup.com/?l=forrest-dev&m=113473237805195&w=2 --> <!--Note: The forrest:properties element does not exit anymore (in comparison to a previous versions) --> <forrest:property name="branding-css-links-input"> <css url="common.css" media="screen" rel="alternate stylesheet" theme="common"/> <css url="pelt.basic.css" media="screen" theme="Pelt"/> <css url="pelt.print.css" media="print"/> <css>/* Extra css */ p.quote { margin-left: 2em; padding: .5em; background-color: #f0f0f0; font-family: monospace; }</css> </forrest:property> </forrest:contract> <forrest:hook name="container"> <forrest:contract name="branding-breadcrumbs"> <forrest:property name="branding-breadcrumbs"> <trail> <link1 name="Apache Forrest" href="http://forrest.apache.org/"/> <link2 name="Plugins" href="http://forrest.apache.org/docs/plugins/"/> <link3 name="org.apache.forrest.plugin.output.themer" href="http://forrest.apache.org/docs/plugins/org.apache.forrest.plugin.output.themer/"/> </trail> </forrest:property> </forrest:contract> <forrest:contract name="content-minitoc" dataURI="cocoon://#{$getRequest}.toc.xml"> <forrest:property name="content-minitoc-conf" max-depth="2" min-sections="1" location="page"/> </forrest:contract> <forrest:contract name="content-main" dataURI="cocoon://#{$getRequest}.body.xml"> <forrest:property name="content-main-conf"> <headings type="underlined"/> </forrest:property> </forrest:contract> </forrest:hook> </forrest:view> </forrest:views> > > > Why "a unit of information formatted as XML" can contain other "units of > > information formatted as XML" (documents can contain other documents, > > or)? > > I am not certain where this line appeared, but > - when a unit of information formatted as XML contains other units of > information formatted as XML, the result is a unit of information > formatted as XML. > > or phrase it: > - when a Document contains other Documents, the result is a Document. > > For example, a NavigationModule would aggregate many Documents, filter > the data, and serialize as XML. The Live Module handles the result > from a NavigationModule just like a Document retrieved from the > datastore. The aggregation of a Document from the datastore with the > results of several NavigationModules creates a new Document. That is > passed to a Transformer to create an XHTML Document, which is passed > to a Serializer to create the HTML Page (which may not be valid XML > and so should not be called a Document) which is returned to the > visitor. wow, all the above said about NavigationModule is for me just a contract of the dispatcher and do not have to be in a module. > For programming purposes, "Document" always refers to an "XML > Document". > Some are stored in Content. Others are created by > Modules, and only exist in memory. But all can be handled with the > same functions. IMO you are limiting the naming to certain formats and resulting processes which IMO is not suitable for a multi-format environment/CMS. Further I do not see the need nor the benefits and would like to see consisting naming for users and devs. "Lenya never stated to be *just* a web CMS focusing on editing webpages (html)." ;-) > > solprovider Thanks for helping to reach a consensus on this. :) salu2 -- thorsten "Together we stand, divided we fall!" Hey you (Pink Floyd) --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
