Andreas Hartmann wrote:
Jörn Nettingsmeier schrieb:
hi everyone!
trying to nail down the asset problem (format=downloadLink breaking
pages)...
how are resource type formats supposed to work? are they all strictly
internal-only, or should i be able to request them via browser as well?
You can use the parameterized version to obtain it from the browser.
http://lenya.zones.apache.org/docu/docs/2_0_x/reference/resource-types.html#Formats:
yeah, thanks, i'm seeing the light now. the reason for the whole
confusion was that i hadn't realized that the root cause of the problem
was insertAsset returning a site: url as opposed to a lenya-document:
one. (even though you had explicitly pointed that out. doh! temporary
mental dysfunction.)
btw, here's a suggestion (after wading through many a convoluted
sitemap): can we please stop this nonsense of using pseudo "file names"
like "xhtml.xml" as matcher patterns? these are totally obscure, give no
clue what they are about and worst of all imply there's an actual file
resource somewhere.
Hmmm, IMO it makes sense to use the suffix to denote that XML is
returned by the pipeline. But I don't mind removing it.
XML is returned by *every* pipeline unless you are using a fancy
serializer, and then it will be obvious.
how about using self-explanatory names? for instance, the resource
module implements several formats, all named "something.xml". why not
just match for "format-downloadLink", "format-webDAV",
"format-whatever", where the part after the dash matches what's declared
as format identifier in config/cocooc-xconf/module.xconf?
Makes sense.
ok. i'll tackle it asap.
i'm also not sure whether we should maintain the configurable format uri
in the xconf files. why not set up the convention that resource type
formats are to be implemented as "format-FOO" and get rid of the
indirection? or are there examples where the current approach is
absolutely necessary?
What would the URL be? A module can provide multiple resource types,
and there is no convention like moduleName = resourceTypeName (yet).
then we should pull one out of thin air. or are there huge advantages in
providing several doctypes in one module? given that you're advocating
"less doctypes, more formats" for good reasons, i think we won't lose
anything by mandating "one module, one doctype". and then the format BAR
of doctype FOO could always be accessible as /modules/FOO/format-BAR.
i don't have a problem with leaving that configuration mechanism in
place for now, as long as all core modules follow the same intuitive
naming scheme.
then again, why should we use components for formats? it means we can't
hot-deploy them. what are the benefits?
regards,
jörn
--
jörn nettingsmeier
home://germany/45128 essen/lortzingstr. 11/
http://spunk.dnsalias.org
phone://+49/201/491621
Kurt is up in Heaven now.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
