1. I like overridable properties better than the one method, but I think this may hurt extensibility later on and introduce version dependencies.
2. Why not store the TableDefinitions in a static class? On 11/17/05, Derek Cicerone <[EMAIL PROTECTED]> wrote: > > > > Yeah, it's basically a factory, especially if we take Nicholas's suggestion > and have a single method that returns classes that implement specific > interfaces. > > > > So, two questions: > > Should we have overridable properties for each extension type OR use one > method to return each extension type (as Nicholas suggested)? > Should we put the common things like TableDefintions as a property in the > main class or instead put it in yet another extension class (I guess > something like MsiExtension or MsiSchemaExtension)? > > > > Thanks, > > Derek > > > > ________________________________ > > > From: Rob Mensching [mailto:[EMAIL PROTECTED] > Sent: Thursday, November 17, 2005 1:05 PM > To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; 'WiX-devs' > > Subject: RE: [WiX-devs] rfc: re-architect wix extensions > > > > > Yeah, I see why your initial proposal is more flexible... not much more > overhead either. Basically the WixExtension class is a factory, right? > > > > ________________________________ > > > From: Derek Cicerone [mailto:[EMAIL PROTECTED] > Sent: Thursday, November 17, 2005 10:23 AM > To: [EMAIL PROTECTED]; 'WiX-devs' > Subject: RE: [WiX-devs] rfc: re-architect wix extensions > > > > That's a good point – I should have also mentioned that alternative. I > believe the non-interface solution is a bit cleaner because it allows us to > keep the code for each extension in its own class while having the advantage > of the appearance of a single class being visible to the user so that they > can run the different commands as you illustrated below. > > > > To summarize, with interfaces: > > - all extension methods go into one central class that implements > the various interfaces > > - user can specify this class as the extension for all wix tools > > - individual tool extensions (or at least their exposed entry > points) are all in one main class like ScaExtension. > > > > Without interface: > > - one extension class implements WixExtension, which then > optionally contains references to the individual tool extension class > > - user can specify this class as the extension for all wix tools > > - individual tool extensions remain isolated in classes like > ScaCompilerExtension, ScaDecompilerExtension, etc… > > > > Derek > > > > ________________________________ > > > From: Rob Mensching [mailto:[EMAIL PROTECTED] > Sent: Thursday, November 17, 2005 9:24 AM > To: [EMAIL PROTECTED]; 'WiX-devs' > Subject: RE: [WiX-devs] rfc: re-architect wix extensions > > > > What about the option where there is an interface for each Extension type > that a single class could implement. So you could do: > > > > candle.exe –ext "extension.dll,ExtensionClass" > > light.exe –ext "extension.dll,ExtensionClass" > > dark.exe –ext "extension.dll,ExtensionClass" > > > > That ExtensionClass could then implement the ICompilerExtension, > IBinderExtension, ITableDefinitionColleciton, IDecompilerExtension. Are the > significant benefits of one method over the other? > > > > ________________________________ > > > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Derek Cicerone > Sent: Wednesday, November 16, 2005 12:22 PM > To: 'WiX-devs' > Subject: [WiX-devs] rfc: re-architect wix extensions > > > > Hi, > > I'm currently working on supporting decompiler extensions (which > would basically allow someone to create an extension for the decompiler that > would allow custom tables to be converted back into wix authoring). This > will complete the round-tripping of wxs -> msi -> wxs again. > > > > Currently we have several wix extensions: > > - PreprocessorExtension > > - CompilerExtension > > - SchemaExtension (its implemented by the CompilerExtension) > > - BinderExtension > > - DecompilerExtension > > > > Right now, in order to use a Preprocessor extension as well as a compiler > extension, two different –ext options must be passed to candle, like this: > > -ext "extention.dll, PreprocessorExtensionClass" –ext "extension.dll, > CompilerExtensionClass" > > > > This is not too bad because most extensions currently only implement the > compiler extension. However, now that we'll have a decompiler extension > things get kinda hairy because the decompiler extension must also implement > SchemaExtension (to get the table definitions) and requires the user to know > the two different classes to use within the extension for the compiler and > decompiler respectively. > > > > I'd like to propose creating a new WixExtension class to be the main entry > class for all extensions. This class would basically be an abstract class > with properties that would return a PreprocessorExtension, > CompilerExtension, etc… if an extension overrides the value to provide the > specific extension class. This class would also contain information common > to multiple extensions like the TableDefinitions. > > > > Here's an idea of what it would look like (this is pseudo code): > > > > class WixExtension > > { > > public virtual CompilerExtension CompilerExtension > > { > > get { return null; } > > } > > > > public virtual DecompilerExtension DecompilerExtension > > { > > get { return null; } > > } > > > > public virtual TableDefinitionCollection TableDefinitions > > { > > get { return null; } > > } > > } > > > > If we do the proposed changes, since this will break backwards > compatibility, I'll also be modifying the CompilerExtension to add the > suggested extra optional attributes in the ParseElement method (please see > earlier email). If anyone has any suggestions for other breaking changes > needed for the extension model, this would be a good time to bring them up J > > > > Thanks, > > Derek N¬HS^µéšŠX¬²š'²ŠÞu¼…âA¢Ë�Áž´'«¶'âyÔèu¬‘z¬µêߢ¶‰‹,N¶¢ž)à ‹«±ákyàž®ØŸ‰ÆŠ‰ÄÅ©Ÿ¢°%•:ÚŠx§€ mzw^zÄᮋ „IÝ¡ý´Ó‘h®j+z)ߢø¬ŠØm¶ŸÿiÛ(±ÙÜ¢oÚv'
