Hello Marc,
we are still considering your suggestion. The problem is that some
classes that inherit from Metadata have no concern with Variants.
best regards,
Thierry Boileau
On Mon, Feb 25, 2008 at 9:31 PM, Thierry Boileau <[EMAIL PROTECTED]> wrote:
> Hi Marc,
>
> Oops, I've made a mistake when I wrote the mail. There is no
> distinction between a file with no extension and a file with unknown
> extensions.
> At the end of the process, the variant must be completed with either
> its "natural metadata" or some default ones. That's what I wanted to
> say.
>
>
> > By the way: the instance-of checking on the subclass of Metadata is a
> > bit messy (not very OO/polimorfism) I would suggest refactoring to adding:
> Thanks for the suggestion!
>
> best regards,
> Thierry Boileau
>
>
>
>
> On Mon, Feb 25, 2008 at 8:55 PM, Marc Portier <[EMAIL PROTECTED]> wrote:
> >
> >
> > Thierry Boileau wrote:
> > > Hello Marc,
> > >
> > > thanks a lot for tracking this bug. The first path has been chosen
> >
> > cool, and thx.
> >
> >
> > > because of symetry, and because there is a distinction between a file
> > > having no extensions and a file having extensions not registered by
> > > the metadataService.
> > >
> >
> > OK, but I'm unsure if I understand the "distinction" now.
> > In the current situation: when a file does not have an extension, then
> > no metadata will get loaded in the updateMetadata in LocalClientHelper
> > (and thus the default will be added anyway.)
> >
> > I'm perfectly happy with this solution, but if you _do_ want that to
> > have a no-extension mapping to be distinct from the 'default', then I
> > would suggest to insert at line 105 something that
> >
> > // checks for the no extension-case
> > if (tokens.length == 1)
> > {
> > // and makes the association from
> > current = getMetadata("");
> >
> > // and then applying the media-type to the variant
> > }
> >
> >
> > By the way: the instance-of checking on the subclass of Metadata is a
> > bit messy (not very OO/polimorfism) I would suggest refactoring to adding:
> >
> > public void applyTo(Variant variant) to the MetaData class
> >
> > you can either make it abstract there, or let it do nothing
> >
> > and then have the specific subclasses make the correct implementation.
> >
> > Inside LocalClientHelper this would replace the complete set of
> > if-else "current instanceof" testing with a mere
> >
> > current.applyTo(variant)
> >
> >
> > HTH,
> >
> > regards,
> > -marc=
> >
> >
> >
> > > best regards,
> > > Thierry Boileau
> > >
> > > On Mon, Feb 25, 2008 at 5:16 PM, Marc Portier <[EMAIL PROTECTED]> wrote:
> > >> Hi,
> > >>
> > >> I'm looking for a way to allow PUT on
> > >> - file:/// URI's
> > >> - to resources that have no extension
> > >> - by pushing entities of type "application/octet-stream"
> > >> (or whatever would be the metadata-service's default-mime)
> > >>
> > >> Currently the file-client-helper checks the metadata-consistency of
> the
> > >> file being put.
> > >>
> > >> This check *always* fails when the file doesn't have an extension at
> all.
> > >>
> > >>
> > >> To resolve, I see two possible paths:
> > >>
> > >> [1] let consistency check pass when:
> > >> extension doesn't yield a mapped type
> > >> AND the type being put matches the default.
> > >>
> > >> Looking at the MetadataService I see it holding a defaultMediaType,
> but
> > >> that one isn't considered when doing the consistency check. (While the
> > >> default-language is, so this would put both in sync more.)
> > >>
> > >>
> > >> [2] allow to assign metadata to the "" extension (empty string)
> > >>
> > >> I'm not entirely sure how the meaning of 'default' relates to the
> > >> meaning of 'no extension', if those have different meaning, then I
> think
> > >> this would be the appropriate way out.
> > >>
> > >>
> > >> I'm tempted to go for [2], but wanted to check here if I'm not
> > >> overlooking possible conflicts or yet more elegant solutions, so
> please
> > >> comment.
> > >>
> > >> As before, I'll be happy to provide the patch for this.
> > >>
> > >> regards,
> > >> -marc=
> > >>
> > >
> >
>
