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
