Jörn Nettingsmeier schrieb: > 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?
Hmm, I'd prefer to keep modules and resource types orthogonal. For instance I started to work on a usecase analysis module, which would provide "usecase" and "actor" resource types. I wouldn't like to add another module just for the additional resource type. >>> 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. I'm not sure where the best place for the format documentation will be - but fortunately we don't have to decide this now, the future might tell. > 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... +1 -- Andreas -- Andreas Hartmann, CTO BeCompany GmbH http://www.becompany.ch --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
