Re: [xwiki-devs] Choosing the default component implementation [take 2]

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<sergiu(a)xwiki.com> 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.