RE: [WiX-devs] rfc: extending the CompilerExtension.ParseElement

[Fredrik Grohn]

This makes sense to me. I always felt that what I did in pubca was kind of a hack, but it didn’t feel important enough at that point in time.   I thinik I’d go for the StringDictionary suggestion. Seems like the simples one.   However, the question mark I think is what values to pass. It’s probably not a good idea to pass everything along, but some things are more obvious than others (like the ComponentId). Is it possible to give a good enough guess in advance what would be needed to be passed along from each element? Also there is the question of recursion. Should values for parent elements be included as well? (Hmm, maybe the last one is easier that it seems at first.) Do you have any thoughts on this, or where you intending to include values as they are needed? From: [EMAIL PROTECTED] on behalf of Derek Cicerone Sent: Tue 10/25/2005 10:06 AM To: wix-devs@lists.sourceforge.net Subject: [WiX-devs] rfc: extending the CompilerExtension.ParseElement Hi,             As I’m attempting to write the sca compiler extension I’ve hit a scenario in which it would really be nice if the extension mechanism allowed for passing just a bit more information between parent elements and their extended children.   Here’s a snippet of the code: ParseComponentElement …. Foreach (XmlElement child in node.ChildElements) {             Switch (child.LocalName)             { case "FileShare":                             this.ParseFileShareElement(child, id, directoryId);                             break;             } }   If this code is moved into an extension, its still easy enough to grab the Component/@Id off the parent component element, but it would be really nice if the interface allowed for a way to pass the id and parent directory id more robustly (than having me attempt to re-parse the parent xml).  I believe some other people also expressed interest in passing more information down to extensions.   So, here’s an idea, what if we change the current interface: /// <summary> /// Processes an element for the Compiler. /// </summary> /// <param name="sourceLineNumbers">Source line number for the parent element.</param> /// <param name="parentElement">Parent element of element to process.</param> /// <param name="element">Element to process.</param> public abstract void ParseElement(SourceLineNumberCollection sourceLineNumbers, XmlElement parentElement, XmlElement element);   We could add a new parameter which passes custom information from the parent element.  So, for Component, it could pass {Id=“<component-id>”, DirectoryId=“<directory-id>”}.  But other parent elements could chose to pass other useful info.  For file element extensions, it might be useful to have the id and sourcepath.   I’m not sure if the parameter would be something like a StringDictionary (yes, I know it has case-insensitive keys), or perhaps a string[] would be good enough assuming we only ever added new information to the end of the array should the need arise.  It could also be an object, which might be more flexible.   What do people think about this?  I’m a little worried about modifying this interface, but since I think there are literally 2 compiler extensions in WiX 3.0 (pubca and one that I maintain), this shouldn’t be too bad.  Gábor, I’m hoping to hear from you since you’ve done the most work with the compiler extensions thus far. J   Thanks, Derek