01132: More flexible script & cookbook initialization Summary: More flexible script & cookbook initialization
Created: 2009-08-04 15:40
Status: InProgress
Category: Feature
From: Eemeli Aro
Assigned:
Priority: 554
Version: 2.2.x
Description: There's a better way of doing script and cookbook initialisations than the current dependency on including files in the correct order. Proof of concept: setup.php For example, I'm putting together a new PmWiki blog package, but I'm running into some rather thorny issues manipulating the More specifically, at the moment I'm looking to overload the EditDraft function, without having to duplicate the contents of scripts/draft.php and other script files. The simple thing to do would be something like this: if (IsEnabled($EnableDrafts, 0)) { include_once("my_draft.php"); $EnableDrafts = 0; } But that won't play nice, since drafts should come after simuledit + prefs, and hence those too would have to be included before The reason it's so difficult is because much of the initialisation code for scripts as well as cookbook recipes happens right when they're included, which means that the order in which you put things in your config file(s) is important. I think this isn't the best way of doing things. For a fix, I suggest a new table of initialisation functions that could get called from pmwiki.php at the very end of initialisation, just before HandleDispatch. The format for this table should be something similar to the MarkupTable, which handles the exact same problem, just for a different context (the order in which markup rules get implemented). Regarding my original issue, this table would let me eg. add a function near its end that would safely replace the appropriate A proof of concept implementation of this SetupTable is attached. To see it in action, include it in a config file and use I once talked with Pm about such ordering of functions and PageStore objects, he found it far too complex to do it again. Wouldn't it be simpler but also efficient to do something like: This would allow us to insert/disable/replace/reorder edit functions, and later PmWiki will asort() the aray and process it. This way will be implemented in FPLTemplate(), I'd like to do it for the upload functions as well, which would add more flexibility than now. --Petko August 06, 2009, at 04:03 AM That would indeed help with $Setup = array( 'SetCurrentTime' => 100, 'ResolvePageName' => 200, "$FarmD/scripts/stdconfig.php" => 300, 'ReadInterMapFiles' => 400 ); Which would get parsed roughly as follows: asort($Setup); foreach($Setup as $k => $v) { if (!$k || !$v) continue; if (substr($k,-4) == '.php') include_once($k); else $k(); } Also, regarding your proposed change to I would love to see greater control over when config code gets executed. In addition to being able to specify an order for initialization with normal config.php I think there should be some capability for executing code after stdconfig, at the very end of producing a page, etc. --Peter Bowers August 06, 2009, at 03:15 PM Here are a couple of actual use cases where I'd find it very useful to be able to get a function to run near the end of the setup phase. βEemeli Aro August 17, 2009, at 05:06 AM
This could be solved by having an index numbering for $EditFunctions or by being able to set a function to run using $Setup as above.
This requirement could be removed by having a $Setup array where a function could execute the above line of code.
To fix this, either $EditFunctions would need to be changed along with how functions are added to it (to something like SDV($EditFunctions[300],'EditDraft'); in draft.php ) or a $Setup array could help replace EditDraft with its own function.
I like your ideas a lot. Does it look reasonable to have something like $Setup['PageStore'] = array('wiki.d'=>100, 'wikilib.d' => 200, /*etc*/); $Setup['EditFunctions'] = array( 'EditTemplate' => 100, 'RestorePage' => 200, /*etc*/); $Setup['UploadFunctions'] = array( 'UploadVerify'=>100, /*etc*/); $Setup['FmtTemplateFunctions'] = array( /*etc*/); $Setup['init'] = array( 'SetCurrentTime' => 100, 'ResolvePageName' => 200, "$FarmD/scripts/stdconfig.php" => 300, /*etc*/); The I think you're talking about a far more in-depth re-working of PmWiki internals than what I was looking for. Not that I'm at all against it, I just think we're having two separate conversations here. So, to address both of them: I don't think we should restructure
But A simple $PostConfig array processed after stdconfig.php was added to subversion, for 2.2.17, unless we discover some problems (speak up). --Petko June 05, 2010, at 07:18 PM Any possibility it could be moved down a few more lines? If it occurred immediately after this line: SDV($LinkPageCreateSpaceFmt,$LinkPageCreateFmt); or even just before this line: if (IsEnabled($EnableActions, 1)) HandleDispatch($pagename, $action); then functions can call MarkupToHTML() successfully... Also the later it is the less likely we will run into caching issues... If there's an advantage to having it in its current location then perhaps there could be some mechanism where functions with sort values less than 100 go in the current location but functions with sort values greater than 100 go in the later location? Or maybe ... $PostConfig['A']['myfunc'] = 100; // this will run right after stdconfig is loaded $PostConfig['B']['mylatefunc'] = 200; // this will run after links are defined with certain predefined values for the index. ( --Peter Bowers June 21, 2010, at 04:20 AM I'm not sure that functions should call MarkupToHTML() directly from the config files: at the moment, I can't decide if we should try to support this and to keep fixing it every time someone's code breaks it. :-) If someone requires link variables to be defined, they could define them in the script, however direct calling of MarkupToHTML() might work but is still utterly unsupported. PITS:01214. --Petko September 04, 2010, at 11:50 AM I don't know if I understood the problem completely, but about this: if (IsEnabled( include_once("my_draft.php");
} I believe this could be solved by setting a variable called $DraftsScript, that when changed will run the Draft Script you want instead of PmWiki's Draft Script. Also, to change, remove or substitute an entry in EditFunctions more easily we could create a recipe that does that. I did a really tiny recipe that does just that as it was a MarkupFrame manipulator, it just doesn't replace or remove, it just ads in front or after an already placed EditFunction and also at the beginig or at the end. I will change the recipe to do replaces and removes as well. CarlosAB March 17, 2018, at 01:34 AM |