Vadim Gritsenko wrote: > > Sylvain Wallez wrote: > > [good ol' snip] > > > I don't see a real problem of having InputModule (or whatever their > > names) being not fully used by the sitemap engine, and I'd like to > > avoid the conceptual overlap between InputModules and > PropertyContainers. > > > I share this sentiment. > > > > Someone (Chris I think) made a parallel between Modules and Sources : > > a source acesses (potentially) large data sets, while a module > > accesses smaller and discrete data. > > > > So, since we have Source, WriteableSource, TraversableSource, etc, why > > couldn't we have : > > - PropertyProvider (I like it more than "PropertyContainer") > > - WriteablePropertyProvider (i.e. an input/output provider) > > - ListablePropertyProvider (i.e. the current Module, that can list the > > values it provides) > > - ListableWriteablePropertyProvider (extends ListablePropertyProvider > > and WriteablePropertyProvider) > > > > And require classes used by the sitemap to implement the root > > PropertyProvider interface. > > > > Thoughts ? > > > Good idea. I like the shorter name of _PropertySet_ more though. > Ok, we already have *released* the InputModules/OutputModules. With this proposal from above we have to deprecate this newly introduced concept again.
I see the need for the property provider functionality in the sitemap. Can someone give some examples for the use of a writeable property provider in the sitemap etc? My suggestion was to make the components that are used in the sitemap as simple as possible and keep most parts that we already have intact. So I still think for the use in the sitemap, the PropertyContainer (PropertyProvider) approach is the simplest approach that fulfills all requirements (for the use in the sitemap). Carsten --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
