The default location field is useful in some ways and can be called from other objects but is specific to some usecases (Server location, geo-location etc) that said more and more nowadays we find that people want there location to be shown for different sites so including it in the basic metadata is a good idea for a modern system.
As it is already there would it be a better idea to extend it and hook it into a mapping system rather then exclude it, it seems a step backwards. Peace Wyn On Fri, Aug 5, 2011 at 10:22 AM, Wichert Akkerman <[email protected]> wrote: > On 08/05/2011 12:02 AM, David Glick wrote: > >> On 8/4/11 2:56 PM, Héctor Velarde wrote: >> >>> in Archetypes location is declared in ExtensibleMetadata.py as: >>> >>> # Location, also known as Coverage in the DC metadata standard, >>> but we >>> # keep the term Location here for historical reasons. >>> StringField( >>> 'location', >>> # why no accessor? >>> http://dev.plone.org/plone/**ticket/6424<http://dev.plone.org/plone/ticket/6424> >>> searchable=True, >>> widget = StringWidget( >>> label = _(u'label_location', default=u'Location'), >>> description=_(u'help_location_**dc', >>> default=u'The geographical location >>> associated with the item, if applicable.'), >>> ), >>> ), >>> >>> why this was not included in the standard IDublinCore behavior? >>> >>> I honestly can't remember; it was probably an oversight. Do you think >> it's important to add it? >> > > My guess would be because almost nobody uses the field. Personally I'ld > rather have it removed (and especially its catalog index). > > Wichert. > > ______________________________**_________________ > Product-Developers mailing list > Product-Developers@lists.**plone.org <[email protected]> > https://lists.plone.org/**mailman/listinfo/plone-**product-developers<https://lists.plone.org/mailman/listinfo/plone-product-developers> >
_______________________________________________ Product-Developers mailing list [email protected] https://lists.plone.org/mailman/listinfo/plone-product-developers
