What I'm trying to achieve is a simple, extensible library that is non-restrictive, non-intrusive and allows simple to use and develop within. Minimal support, minimal effort, minimal training, and quick development using what the developer and designers already know or can quickly learn to use.
It appears that from all of the MVC frameworks and libraries, they succeed in some areas and fail in others. I'm starting to see that CodeIgniter while the architecture likes like retarded developers built it, is not so bad. The frameworks range from simplicity in design and thus do not easily allow modification, except through inheritance and not worth doing so because rewriting the library would take no time at all. To architectures that include convoluted design patterns (stupidly, one even goes so far as to make it the main focal point of the library).
In my comparisons, I can see how some put a lot of care and painstakingly gave bits and pieces every bit of their love in the development, and well others, I can see that they were developing like programmers.
I will explain the flaws of templating engines, if for the only reason to sow the seed of doubt. I didn't wish to bring up the 5 year old debate. I can see it went no where with some developers, since Smarty is still being developed and yet more developers are developing their own.
The reason I wish to disable SS, is below.
1. Your templating engine does not work with other templating engines, this is of course, by design and to support the infinite amount of other templating engines, even Smarty, is infeasible based on time constraints, motivations, and ROI (there is none). The problem is that no one cares about the other templating engines enough to care to support them or even use them as they see them as inferior. Much like I see yours. Not that I say Smarty is better, I can see how through extending the base class I could re-implement your templating engine.
2. It reminds me much of another templating engine in HAMWeather PHP application. The problem is that I wanted to do something as simple as including another header (which was possible through a painful hack), but alas its limitation is much like the limitation of SS. It only allows parsing one line at a time (this is only slightly true, since multi-line support can be enabled allowing statements to be on more than one line, if not already enabled that way).
If I wish to work within my current web site, I would have the choice, either rewrite everything, which is not acceptable, since I'm not going to spend a month rewriting everything to SilverStripe and would instead spend several days or a week rewriting SilverStripe to work with my headers and templates. My templates were built to work with many web applications and to rewrite them and manage them for yet another web application is unacceptable, not just because of time, but because of the forgetful nature of developers without procedures.
If I'm restricted from including my headers, my footers, my sidebars within the web application, then the web application isn't worth it in my opinion. I also have my own API and hooks into the template, and while they are simple and inadequate, they have been used for a long time and done so because they just work within most PHP web applications.
3. SilverStripe templating engine must be maintained, extended, improved, debugged, and supported. This is by people, who might be motivated by varying factors: money, time, pride, or all three or even others not listed (family, friends, entertainment, depression, etc). As a language, SS is lacking and I would rather stand by PHP, which even though it has the same problems as SS, it has many more people working on it than SS can ever hope to achieve.
I would rather trust a language and templating engine built for the single purpose of being combined with HTML, than another language built using that language and supported by people who might have no idea how to enhance it completely to support any library I would want to include in the templating engine or language if I may call it, even if it isn't as complex.
The simple truth is that SS is not finished and it won't ever be finished, because someone like me comes along and has to either hack together a solution or someone comes along that can't code the solution and has to request it.
4. The time constraints isn't in learning what is currently supported, that is easy. I read over the regex and was impressed in its limited support and the cool way it implemented it. The time constraint in learning SS is the same for Smarty and any other templating engine / language.
I write my APIs in PHP, so I have the unfortunate task of working them into the templating engine. This is never a simple task. What makes it difficult is that I'm taking my PHP code and converting it over to a templating engine, which takes it back to PHP (some do not do this and evals the expression). What would make it simple is to never use a templating engine in the first place. In that use case, I would be taking my PHP API and using it within PHP that will be compiled using the same compiler without an intermediary step.
5. MVC in PHP does not mean separating PHP completely from the presentation. I think that is what some of the libraries and frameworks I looked at were confused with. A few looked like they were coming from other languages that can't combine HTML and their language at all or at least not easily. For the languages that require creating a templating engine/language, because they have no choice, if they wish to create a web site using that language and are restricted by the compiler from including HTML, then that is their only choice. They have to do it.
I think that some developers mistakenly think that MVC means that no logic or programming should be in the views, but that is impossible. Having a templating engine will reduce the mistakes novice and intermediate developers make when coding views and answering the question, "how much logic is too much?" It doesn't take from the fact that PHP is a templating engine and the best one for PHP, since all PHP developers with at least a year of experience will be able to code a view based off of the API given.
The point is to provide a simple API for traversing processed data and an API for simplifying the logic. I will refer to WordPress, in only that its API is simple in that many designers can quickly "learn" it without fully learning PHP. They don't require learning a templating engine, but the API is simple enough that most of the time they can just copy and paste and modify a few arguments to do what they need. I do not suggest that the architecture of WordPress be reproduced only the simplicity of the API and its use of PHP views instead of using or creating another language.
In conclusion, while Sapphire does hold a bit of promise, I can foresee it having to be rewritten to allow for some features that I take advantage of having and can't imagine not having them. I doubt this would have any impact, since I used to be like you and used to think Templating Engines were sweet, until I had to extend the capabilities of the template engine and found out that supporting them weren't all they were cut out to be.