Andreas Hartmann schrieb: > 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()
BTW, the current ResourceType interface wouldn't even have to be changed - getFormatURI() would just consider the module name. We'd have to remove the getFormats() method, though, if we don't specifiy the formats in the resource type declaration. -- Andreas > > <resource-types> > > <component-instance name="entry" module="blog" ...> > ... > </component-instance> > > </resource-types> > > Then the URL would look like this: > > /modules/blog/format-entry-xhtml > > >> 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. > > -- Andreas > > -- Andreas Hartmann, CTO BeCompany GmbH http://www.becompany.ch --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
