Torben Nehmer wrote: > mgd_snippet? mgd_include? I'm beginning to suspect that I've discovered > only the tip of an iceberg. As long as the eval(mgd_preparse()) > Construct stays the offical replacement for the eval() thing, I'll be > fine... *g*
I will unless there's a pressing reason to change it. But nost users won't see this in action, it'll just be something midgard does so it can do its job. > >> I do not, I depend on a documentation about this. Especially the > >> whole Formatter things. Questions like which formatter does Midgard > >> expansion, which not, when do I have to use mgd_preparse, how do I do > >> eval() constructs with Midgard support. All those things would be > >> really nice if there is some place where they are defined. > > > > Yes. They would. > > The old problem. If you could give me some description about all these > missing things (including a short overview over the deprecated ones and > how they should be replaced) I'd be glad to write some docs about it. > (Not that I have the slightest Idea how to incorporate this in the Main > Documentation...) All formatters are expanded. You use mgd_preparse each time you want to execute PHP code that contains Midgard-specific extensions, and pass that to eval. That's the only way (now) to execute midgard code. the preparser automates this for you, changing mgd_eval to eval(mgd_preparse( on the fly, or once for the static parts of the page, which are cached out. This way, in the end all the PHP engine sees is 'regular' PHP code. You can toy around with the preparser by making a local copy of your rootfile, pass it to midgard-pageresolve as its root page, sticking in stuff you want to see expanded. Documentation is welcome in any form that I can read under Linux. I can convert Word docs elsewhere but prefere not to. XML DocBook preferred -- it's moderately easy to glean from the rest of the docs (http://cvs.midgard-project.org/midgard/xmldoc/) what can go where. > > Not possible without re-implementing the Zend eval (which is what > > mgd_eval previously did). eval works in the scope of the code that > > calls it. A function, _any_ function, works in its local scope unless > > you explicitly name the variables you want to be globals, and even > > then it only works in the global scope, not the calling scope. > > Which is definitly too much work... And trust me to try. Ow. Parsing bits of string to see what could be a variable and then declaring it global. It was a total mess (as you probably guessed), and even if you could get it perfect (and you can't unless you can hook into the Zend parser, trust me) it would still _only_ work in the global scope, so it would still not be a proper replacement for eval. The reason why I'm doing all this is that I want to strongly simplify Midgard to make it more robust and maintainable, and avoid, unless utterly, utterly necesary, to reimplement (or worse, alter) functionality that is present in Zend. Emile --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
