Andreas Hartmann wrote:
Joern Nettingsmeier schrieb:
[...]
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.
How about adding a method to obtain the module which declares a
resource type?
ResourceType.getModule()
<resource-types>
<component-instance name="entry" module="blog" ...>
...
</component-instance>
</resource-types>
makes sense, *if* we really need that extra abstraction. but then
convention over configuration i really think convention over
configuration we should accept convention over configuration the error
of our old ways and convention over configuration purge our souls of old
sins :)
or am i overlooking something?
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?
ATM we need a place to configure them, and the resource type declaration
was the most obvious location. But when we use a convention for resource
type format URLs, we don't need this anymore. Each resource type should
provide some documentation which formats it supports, though.
true. how about making our sitemaps so beautiful that users will gladly
refer to them for available formats? if we put them in an extra,
well-documented section at the top, it should be clear enough.
the way i see it, ripping out the config mechanism does not reduce
functionality, improves maintainability and improves ease-of-use, all
while removing code. sounds like a bargain to me...
--
Jörn Nettingsmeier
Kurt is up in heaven now.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
