Is it possible to not use the SS template engine? I would much rather use PHP and a language that doesn't need support from you guys than a language that does need support as well as extensions to work with other code.

I haven't really gotten to far into the code, but I don't want to use YATE, even if the codebase is fine.

What is YATE?

No, not really.. the templating engine is fairly closely entwined with a lot of the nice functionality of SilverStripe.

What is the issue, exactly? What support and extensions are you referring to?

YATE = Yet Another Templating Engine.

The reason why I ask is, because I don't want to learn another templating engine. I can't understand why Smarty couldn't have been used, since it has been around forever. The SS templating engine seems to be a mix of language features with replacement. While this seems okay, it is not.

If I could get away with just using the Controller, Model, and my own views, then I might evaluate SilverStripe further. However, the prospect of learning another language that I'm going to have to learn the limitations of is not appealing. I could create my own without a template engine and it would only take a few weeks.

What advantage is it then to learn something I have no use for? I suppose I could dig into the silverstripe code further and find out for myself, however, it depends on how intertwined the SS code is with the rest of the library. I don't want to hack too much of it out and build my own APIs, however, I will if the SS templating engine is self contained and independent of the rest of the SilverStripe library.

I've been evaluating many MVC libraries, and it seems Silverstripe is up there with maturity and documentation (not as much or as high up as CodeIgniter, but I different problems with that framework). Do not take this as an snipe at the library, it is just that after having written a templating engine myself, and used many custom ones myself, I don't wish to repeat those experiences. I have a bias towards MVC libraries or frameworks which include and require the use of the template engine though full integration of the templating component with the rest of the library or framework.

I was merely checking to see if I could get a quick answer before digging further into the code base.

Fair enough.

The simple answer is that out of the box, you need to use the SilverStripe template system.

The long answer is that SilverStripe is very modular, and while I'm not aware of any attempts to use an alternate view engine, it should be possible to abstract it out and extend it with whatever you want to use on the front end. See the SSViewer and ViewableData classes.

I can't understand why Smarty couldn't have been used, since it has been around forever.

Being around forever doesn't make something good by default. :P

The SS templating engine seems to be a mix of language features with replacement. While this seems okay, it is not.

The SS view engine, like Smarty, compiles a cached template script. It actually is not so different, just tailored to work very well within the framework.

I don't see what's so bad about the Template Engine. Looking at the whole Sapphire Framework and SilverStripe CMS, learning the syntax for .ss templates takes by far the least amount of time. It's really easy to understand and does most of the things a template engine should.

And as Hamish pointed out: Replacing the View with a custom one is certainly possible. But: doing so would surely be more time-consuming than learning the syntax for the SilverStripe templates.

In the end it all depends on what you are trying to achieve?

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.

You have some misconceptions about the templating engine, and perhaps about SilverStripe in general. I would encourage you to do the tutorials, build a demo site and try it for yourself. I appreciate that you've read the SSViewer class, but there is a lot more power in the engine than what will be obvious from reading regular expressions.

There are a lot of people making complex websites with SilverStripe without the need for the hacks you describe. See the showcase for plenty of examples. Obviously it is not going to be the right fit for everyone.

Best of luck,
Hamish

Wow. What a long post. Sorry if I only skimmed through it.
Including headers and footers is and should be quite a trivial task. But apparently you're looking for an MVC Framework that is much more modular than SilverStripe (well, actually the framework is sapphire and it is modular, but most of us are using it as SilverStripe the CMS).
Like previously stated, it's up to you to modify the view rendering to your needs. If that doesn't suit you, I can also suggest the use of the Zend Framework, which is very modular and has a flexible approach for all parts (Module, Controller, View). But mind you, it's just a framework and not a CMS.