[xwiki-devs] Choosing the default component implementation [take 2]
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/
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/
On 06/05/2012 01:31 PM, Jerome Velociter wrote:
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
Thanks Jerome. If nobody else complains, I'll assume that everyone agrees with me and I'll start investigating some ways of implementing this.
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/
+1 from my PoV I think Guice does something like this with binding an interface to an implementation in configuration. It makes perfect sense to me that the code is the building blocks and the configuration puts them together. (this might demand an internal default config file so that the user doesn't feel that he's editing an init script) Thanks, Caleb On 06/05/2012 07:08 PM, Sergiu Dumitriu wrote:
On 06/05/2012 01:31 PM, Jerome Velociter wrote:
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
Thanks Jerome.
If nobody else complains, I'll assume that everyone agrees with me and I'll start investigating some ways of implementing this.
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.
My opinion on this is that we don't really need it and it's just a new feature on top of what we have (i.e. more complexity and higher risk of not being able to use a standard component framework when one emerges - for example CDI). Also I'm not fond of the ability to create aliases at execution time (ie in the ComponentManager implementation). It's better to have it at the level of the binding but not as a feature of the ComponentManager. Doing this would ruin any ability to use another component framework in the future. All in all I'm -1 till you prove that this can work at least in the following component models (i.e. that those models have this notion or that it can be added): * Guice (will work if you don't put in the ComponentManager impl since Guice has static manual binding) * CDI (I don't know how it could work with it) - CDI is our best bet ATM as our future component framework * OSGi Thanks -Vincent On Jun 5, 2012, at 7:31 PM, Jerome Velociter wrote:
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/
On Jun 6, 2012, at 8:17 AM, Vincent Massol wrote:
My opinion on this is that we don't really need it and it's just a new feature on top of what we have (i.e. more complexity and higher risk of not being able to use a standard component framework when one emerges - for example CDI).
Also I'm not fond of the ability to create aliases at execution time (ie in the ComponentManager implementation). It's better to have it at the level of the binding but not as a feature of the ComponentManager. Doing this would ruin any ability to use another component framework in the future.
All in all I'm -1 till you prove that this can work at least in the following component models (i.e. that those models have this notion or that it can be added): * Guice (will work if you don't put in the ComponentManager impl since Guice has static manual binding) * CDI (I don't know how it could work with it) - CDI is our best bet ATM as our future component framework * OSGi
Maybe I didn't express myself correctly. Here's my current thinking: * The idea is good and it's a nice to have * However I don't think it's a top priority for us ATM (we have already enough components so that it won't make a difference if we wait some more) * I even think that right now we have an existing solution that works well enough (with overrides) even if possibly less nice that this proposal (not even sure yet about this, needs to be discussed - see point below) * Thus we need to be careful and evaluate the risks and how much it costs to move to it * We need to evaluate existing component frameworks to see how they handle this (I think this feature is by default in CDI for example but it's been a while since I last read the spec) * We need to think about how we would migrate to this without breaking too much our users * We need to think how this features position itself vs the current override feature (does it replace it? I would personally not like to have 2 ways of doing the same thing) Thanks -Vincent
Thanks -Vincent
On Jun 5, 2012, at 7:31 PM, Jerome Velociter wrote:
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/
On 06/06/2012 02:17 AM, Vincent Massol wrote:
My opinion on this is that we don't really need it and it's just a new feature on top of what we have (i.e. more complexity and higher risk of not being able to use a standard component framework when one emerges - for example CDI).
Need what? In this mail I only said that using "default" as a component hint is wrong. So, we don't need to make things right? Reading the JSR-299 specification, I noticed that using @Named is somewhat deprecated, anyway, and proper typed qualifiers should be used instead. And every implementation automatically gets the @Default qualifier, so every component implementation is actually a valid default instance. We're currently violating the JSR, since an @Inject-ed field without an @Named will be an "Ambiguous dependency", which is a deployment error (section 5.2.1). So, seeing that we're not using the JSR properly, I'd say that currently it's impossible to use a standard component framework, unless we fix the default component problem...
Also I'm not fond of the ability to create aliases at execution time (ie in the ComponentManager implementation). It's better to have it at the level of the binding but not as a feature of the ComponentManager. Doing this would ruin any ability to use another component framework in the future.
All in all I'm -1 till you prove that this can work at least in the following component models (i.e. that those models have this notion or that it can be added): * Guice (will work if you don't put in the ComponentManager impl since Guice has static manual binding)
Yes, bindings are explicit anyway in Guice, so we can map implementations any way we want in a custom module. To change the implementation for an unnamed dependency, we just provide a different AbstractModule implementation.
* CDI (I don't know how it could work with it) - CDI is our best bet ATM as our future component framework
Simple, whenever a component role has more than one implementation, they should be marked as @Alternative, and the default one is listed in beans.xml. Then changing the default implementation means editing beans.xml.
* OSGi
ResolverHook.
Thanks -Vincent
On Jun 5, 2012, at 7:31 PM, Jerome Velociter wrote:
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/
participants (4)
-
Caleb James DeLisle -
Jerome Velociter -
Sergiu Dumitriu -
Vincent Massol