Hi devs.

I gave this subject some thoughts and I agree with Sergiu on the general
issue of using "default" hint as a marker for default implementations.

Jerome

On Mon, May 21, 2012 at 10:32 PM, Sergiu Dumitriu <[email protected]> wrote:

> Hi devs,
>
> Hmm, time flies, I realized that it's been a month and a half since I
> started this thread, but didn't get to counter-argument so far. Because I
> wanted to give more compelling reasons after I wrote the initial draft of
> the original proposal, I got slammed with counter arguments centering
> mostly on why our current implementation already allows to work around the
> technical difficulties that I presented, although those technical
> difficulties were just extra arguments that weren't actually that important.
>
> Let's start from scratch.
>
> I believe that using "default" as a component hint is in most cases wrong,
> since it doesn't actually say anything about the particular implementation.
> Let's take some examples:
>
>
> EntityReferenceSerializer, with its many implementations:
> - "compact", which creates compact representations that don't repeat the
> parts that are the same as the current document
> - "compactwiki" that only skips the wiki part when not needed
> - "path" which creates references usable as a path on the filesystem or in
> URLs
> - "uid" which creates non-ambiguous representations
> - and "default", which does a... default representation... whatever that
> means...
> So, while the meaning of the other hints can be guessed from their name,
> that's not true for "default".
>
>
> WikiModel, with its only implementation, XWikiWikiModel, labeled as
> "default". First, this "default" is defined in xwiki-platform instead of
> xwiki-rendering, like the components that actually use that component,
> which means that we're defining a component interface without any
> implementation in our "standalone rendering engine", and thus we're using
> "exceptions as normal decision code" which is wrong. Second, this "default"
> actually means "xwiki default". Why can't the hint be "xwiki" instead of
> "default", since that what that implementation is actually doing: "this is
> the model used in XWiki", and not "this is the default model that most wiki
> engines use". When looking up an instance of the WikiModel component, we
> don't request "the default wiki model", but "the wiki model currently in
> use, whichever that is".
>
>
> ConfigurationSource and its implementations:
> - "space" which looks into space preferences
> - "wiki" which looks into wiki preferences
> - "user" which looks at user preferences
> - "xwikiproperties" which looks in xwiki.properties
> - "all" which looks into all the above
> - "void" which is always empty
> - "memory" which stores settings explicitly set by code
> - and "default" which does... stuff... let me get back at you after I look
> into its code to check what it actually does.
>
>
> XHTMLLinkTypeRenderer is an example where "default" does make sense, since
> we have special treatment for "doc"ument, "attach"ment, "mailto", "unc",
> "interwiki", and then there's a "default" that handles all the others, like
> "url" and "path".
>
>
> I was writing a component called UploadedFileManager, which is supposed to
> parse uploaded files from a request, and the implementation for it was
> called CommonsFileUploadManager, since it used the Apache
> commons-fileupload library for the actual request parsing. I don't think
> that calling it "default" is appropriate, since in the 3.0 servlet
> specification the upload behavior is embedded in the specification, in the
> ServletRequest interface, and that seems more "default" than using a
> particular library to do the job. A more appropriate hint is "commons",
> since that's what it actually does: "this implementation handles file
> uploads by using the apache commons library that does that", and not "this
> implementation handles file upload in the default way, which everyone
> should know what it actually is".
>
>
> So, I strongly feel that what the component manager returns when looking
> up a component without a hint shouldn't be the implementation labeled
> "default", but one of the existing implementations, as configured somehow.
>
>
> I'm not yet sure how that configuration takes place, that would be the
> subject of another discussion, but I'd like to get a consensus on whether
> we need this change or not.
> --
> Sergiu Dumitriu
> http://purl.org/net/sergiu/
> ______________________________**_________________
> devs mailing list
> [email protected]
> http://lists.xwiki.org/**mailman/listinfo/devs<http://lists.xwiki.org/mailman/listinfo/devs>
>



-- 
Jérôme Velociter
Winesquare
http://www.winesquare.net/
_______________________________________________
devs mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs

Reply via email to