extending contract for resource type sitemaps?

[Jörn Nettingsmeier <po...@uni-duisburg-essen.de>]

hi everyone!


as mentioned in some other mails, i'm currently working on an 
aggregation doctype that will allow merging data from multiple other 
documents and display it.

that means i will have to call resource type sitemaps to spit out 
rendered pages *other that the current*, i.e. all the {page-envelope:*} 
information is not available.

iiuc, the contract of resource types with the rest of the world is 
currently to provide
   format-xhtml
   format-luceneIndex
   format-webdavGET

first, a question:
why do we use {resource-type:format-xhtml}?
couldn't we just as well use cocoon://modules/xhtml/foo.xml?
that is only marginally more verbose, but cuts out an intransparent 
mechanism that is hard-coded at build time.
what is the reason for the extra layer of indirection between the 
format-FOO call and the resource-type.xconf that maps it to a sitemap call?

now my proposals:

1. if there is no compelling reason for the resource-type input module 
and the format-FOO syntax, let's get rid of it.
2. make a direct-addressing match mandatory for resource type modules, 
and add a context-based match that redirects to the absolute, like so:

  <!-- parametrized doctype matcher -->
  <!-- pattern="{rendertype}" -->
  <map:match pattern="*.xml">
-<map:generate 
src="lenyadoc:/{page-envelope:document-language}/{page-envelope:document-id}"/>
+<map:generate 
src="cocoon:/xhtml/{page-envelope:publication-id}/{page-envelope:area}/{page-envelope:document-language}/{page-envelope:document-id}"/>
+<map:serialize type="xml"/>
+</map:match>
+<map:match pattern="xhtml/*/*/*/*">
+<map:generate src="lenyadoc://{1}/{2}/{3}/{4}"/>


another question: why do we traditionally match "*.xml"? iiuc the only 
way this is ever called is by format-FOO, which means we can get rid of 
the wildcard.
since this is not a real URI, only a marker, i'd also prefer calling it 
something like "renderToXHTML" - this makes very clear that it's an 
internal marker match that will never get to see arbitrary *.xml requests.
if my assumptions are true, make that proposal no.3.


i'd welcome your comments and corrections.



regards,

jörn



-- 
"It's sad to behold how lately the wonderful English language has,
in the hands of corporate executives and marketing experts, re-
adjusted its prospective itinerary towards mythical subterranean
realms of discomfort, leveraging traditional woven containment
devices."

--
Jörn Nettingsmeier, EDV-Administrator
Institut für Politikwissenschaft
Universität Duisburg-Essen, Standort Duisburg
Mail: pol-admin@uni-due.de, Telefon: 0203/379-2736

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org

Re: extending contract for resource type sitemaps?

[Andreas Hartmann <an...@apache.org>]

Jörn Nettingsmeier schrieb:
> hi everyone!
> 
> 
> as mentioned in some other mails, i'm currently working on an
> aggregation doctype that will allow merging data from multiple other
> documents and display it.
> 
> that means i will have to call resource type sitemaps to spit out
> rendered pages *other that the current*, i.e. all the {page-envelope:*}
> information is not available.
> 
> iiuc, the contract of resource types with the rest of the world is
> currently to provide
>   format-xhtml
>   format-luceneIndex
>   format-webdavGET
> 
> first, a question:
> why do we use {resource-type:format-xhtml}?
> couldn't we just as well use cocoon://modules/xhtml/foo.xml?

At the moment not, because resource types are orthogonal to modules.
We could establish a contract:

"A resource type has to be provided by a module with the same name."

This might cause problems with the full/short module name syntax.
Maybe we could handle a resource type as a type of module?
The resource type name would be the fully qualified module name.


> that is only marginally more verbose, but cuts out an intransparent
> mechanism that is hard-coded at build time.
> what is the reason for the extra layer of indirection between the
> format-FOO call and the resource-type.xconf that maps it to a sitemap call?
> 
> now my proposals:
> 
> 1. if there is no compelling reason for the resource-type input module
> and the format-FOO syntax, let's get rid of it.

See above, this would require an explicit contract.

> 2. make a direct-addressing match mandatory for resource type modules,
> and add a context-based match that redirects to the absolute, like so:
> 
>  <!-- parametrized doctype matcher -->
>  <!-- pattern="{rendertype}" -->
>  <map:match pattern="*.xml">
> -<map:generate
> src="lenyadoc:/{page-envelope:document-language}/{page-envelope:document-id}"/>
> 
> +<map:generate
> src="cocoon:/xhtml/{page-envelope:publication-id}/{page-envelope:area}/{page-envelope:document-language}/{page-envelope:document-id}"/>
> 
> +<map:serialize type="xml"/>
> +</map:match>
> +<map:match pattern="xhtml/*/*/*/*">
> +<map:generate src="lenyadoc://{1}/{2}/{3}/{4}"/>
> 
> 
> another question: why do we traditionally match "*.xml"? iiuc the only
> way this is ever called is by format-FOO, which means we can get rid of
> the wildcard.

No idea, could make sense.

BTW, it is now possible to request a particular formatted document,
though this is not yet supported by all resource types:

http://lenya.zones.apache.org/docu/docs/1_4/reference/resource-types.html
(section "Formats")

> since this is not a real URI, only a marker, i'd also prefer calling it
> something like "renderToXHTML" - this makes very clear that it's an
> internal marker match that will never get to see arbitrary *.xml requests.
> if my assumptions are true, make that proposal no.3.

Hmm, is this really necessary?

-- Andreas

> 
> 
> i'd welcome your comments and corrections.
> 
> 
> 
> regards,
> 
> jörn
> 
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org