I spent most of today working on Ditto 1.1 and have successfully integrated PHx into it. Now, for the big question. How far do I take the integration? I can remove the date and summarization code and utilize PHx or PHx extensions for that. However, this would break backwards comatibility. So, what is your opinion?
Here is an example of the difference:
Instead of having &dateSource &dateFormat in the snippet call you would have the following in your tpl
[+createdon:date=`%a %B %d, %Y at %H:%M`+]
The issue is whether or not to pull a large number of lines that handles date formatting an truncation (mostly the truncation) out of the Ditto core.
If I do, Ditto will run faster and have a cleaner codebase
If I don’t then it will still be backwards compatible
-
MODX Staff
- 12,272 Posts
Faster + a migration guide is my vote.
Ryan Thrash, MODX Co-Founder
Follow me on Twitter at @rthrash or catch my occasional unofficial thoughts at thrash.me
+1 for me.
I don’t see migration being a big problem, a few templates ckunk to edit, that should be a matter of minutes.
Speed is essential, so is having a better control of the output.
This is really great Mark !
.: COO - Commerce Guys - Community Driven Innovation :.
MODx est l'outil id
Increasing compatibility with other MODx bits has to be better than retaining legacy compatibility. This also means that more documentation can apply to multiple snippets.
Actually, it looks like you could just output the correct new code to the debug output if the old variables are set, something like
"&dateSource and &dateFormat deprecated. Please add [+" . $dateSource . ":date=`" . $dateFormat . "`+] to your template."
And if it is just that dates won’t show and content won’t be truncated, then this doesn’t seem to completely "break" existing snippet calls. If it did, then I’d recommend calling it Ditto 2. But this seems a simple enough change.
Sounds great, btw.
