Maybe I'm misunderstanding what they will be used for (it's been a very long week and day and I definately feel like a pinto missing on about 3 of my 4 cylinders right now), but my understanding is that the MsiTablesExtension class/interface would house nothing more than information about the tables for querying the database and using that information.
If so, just have a class like MsiTables that has nothing but static members, and one for each table. Or were you proposing a class that would have member representing each table and columns such as: MsiTables.Error.Error /* Integer */ MsiTables.Error.Template /*String */ The latter would be very time intensive to develop. On 11/17/05, Derek Cicerone <[EMAIL PROTECTED]> wrote: > 1. The single method protects us from adding new interfaces but not > necessarily from changes in the interface. However, I don't anticipate that > the core wix tools will add any new types of extensions. So the overridable > properties will probably work just fine. > 2. Could you elaborate on this a bit more? > > Thanks, > Derek > > -----Original Message----- > From: Nicholas Muguira [mailto:[EMAIL PROTECTED] > Sent: Thursday, November 17, 2005 1:56 PM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED]; WiX-devs > Subject: Re: [WiX-devs] rfc: re-architect wix extensions > > 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 > > ------------------------------------------------------- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_idv28&alloc_id845&op=click _______________________________________________ WiX-devs mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wix-devs
