Eric, I like your patch as well. We'll put it into the 2.6 release.
Martin 2009/10/29 Tobias - http://tbGTD.tiddlyspot.com <[email protected]>: > > Hi Eric and Martin, > > I really like your fix, Eric! I think it would make the core code much > more robust and reliable for future development... and thus I hope to > see something like this being integrated into it. In the meantime I > guess it is up to myself and others to use the fix you described. > Therefore, have you already gotten around: > * writing a "CoreTweak" on the issue? > * generating a list of core macros (or even widely used plugins) that > benefit from such a fix... to be included in some startup script/ > array? > > Much appreciated! > > > Tobias. > > On Oct 28, 5:51 pm, Eric Shulman <[email protected]> wrote: >> > The problem is that a large number of macros rely on the current >> > behaviour, and that a fix would break these macros. >> > The correct fix would be to remove the call to readMacroParams() in >> > invokeMacro() and then have any macros parse their parameters >> > themselves. But as I said, this will break a large number of plugins. >> >> I have extensively studied this issue, and have a robust, simple >> solution that works: >> >> 1) In invokeMacro(), change this line of code >> >> m.handler(place,macro, >> params.readMacroParams(), >> wikifier,params,tiddler); >> >> to >> >> m.handler(place,macro, >> !m.noPreParse?params.readMacroParams():[], >> wikifier,params,tiddler); >> >> Then, for any macro that does it's own invocation of parseParams() or >> readMacroParams(), simply set the .noPreParse flag... e.g.: >> >> config.macros.tiddler.noPreParse=true; >> >> If the flag is not defined (or is set to false), the *current* macro >> param processing behavior will be performed. Only when the flag is >> set to TRUE will any change in behavior occur. Thus, this change is >> 100% backward-compatible with all existing macros, and also allows >> remediation of existing core and plugin-defined macros, simply by >> adding one line to each macro definition, and/or by adding a single >> block of code during startup that adds the flag to all the desired >> macros... i.e.,: >> >> var names=['macroname','macroname','macroname',...]; >> for (var i=0;i<names.length;i++) >> config.macros[names[i]].noPreParse=true; >> >> The current behavior for parsing 'eval params' is *extremely* >> problematic: because of the multiple evals, any code within the param >> that is not idempotent will produce incorrect, and potentially >> corrupted, results. >> >> For example, suppose a macro handler that directly invokes parseParams >> () expects a 'next available index' param (perhaps to generate a new, >> auto-numbered tiddler). Let's also assume that the current value is >> stored in some global tracking variable (e.g., >> config.options.txtNextIndex). >> >> When the following macro code is invoked: >> <<myMacro {{config.options.txtNextIndex++}}>> >> the current index is retrieved and the global variable is >> incremented. But, because of the 'multi-parse' problem, the macro >> handler re-parses the param and increments it *again*, producing >> incorrect results from the macro. >> >> Similarly, it is also very problematic to invoke functions in eval >> params that produce user-visible output, such as: >> <<tiddler {{alert('This message is shown TWICE')}}>> >> or >> <<tiddler {{wikify('rendered TWICE',place)}}>> >> >> Please, let's fix this ASAP. >> >> your thoughts? >> >> -e > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TiddlyWikiDev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/tiddlywikidev?hl=en -~----------~----~----~----~------~----~------~--~---
