Google Groups

Re: [silverstripe-dev] SSViewer extensions


Hamish Friedlander Apr 25, 2012 2:39 PM
Posted in group: SilverStripe Core Development
Hi,

I won't cover the issue of 2.4 templating, because it's a known problem - difficult to make any changes to because of the likelihood of introducing regressions. There's a reason replacing SSViewer was basically the first thing that happened during SS3 development :).

As far as 3.0 goes, adding full extensibility to template languages is a little tricky, because we're not necessarily just talking about adding new tags that can be used anywhere - often you need to tweak the grammer itself. The example you give for your 2.4 based extension is such a case.

PHP-PEG parsers can be inherited from to build more complex child classes. My intent for extending SSViewer was that a developer could write a child version of SSTemplateParser.php.inc that changed the language as required. Dependency injection could then be used to replace the default SSTemplateParser instance with an instance of the custom child class.

Unfortunately dependency injection hasn't made it into SS3 yet, and given how late in the beta cycle we are, might end up being a 3.1 feature.

There's also an internal API in SSTemplateParser.php.inc for adding basic open and closed tags that don't need grammer modification by defining a method called OpenBlock_Handle_TAGNAME or ClosedBlock_Handle_TAGNAME. However, as in 2.4, SSTemplateParser doesn't inherit off Object, in this case because it inherits off Parser - which is a third party library that doesn't know about Object, and needs to work in systems that don't define it. As a result these methods can't be injected with decorators.

Both of those could be changed to work without too much effort, adding a pseudo-DI setter on SSViewer to set the template parser class used, and adding some method for adding open & closed tag handler methods, but I'm a little hesitant to do that (especially the second, which exposes an internal API we don't necessarily want to be tied to) without a strong example use case. The 3.0 template language is much more complete and orthogonal than 2.4, so hopefully there isn't too much need to extend it.

Hamish Friedlander

On 24 April 2012 21:01, Ingo Schommer <in...@silverstripe.com> wrote:
Hey Jeremy, without going into details,
I think the "bandwidth" of core devs for larger 2.4/post-2.4
change proposals is very limited at the moment due to the 3.0 release :)
Hamish will be the best person to ask about plugin support for SSViewer in 3.0,
maybe try to email him directly? ham...@ss.com.

Thanks!
Ingo

On 24/04/2012, at 5:21 AM, Jeremy Thomerson wrote:

Devs,

  In the process of building my first very large site with SS I have found that the only weak spot that I really don't like is the template parsing done in SSViewer.  We're on version 2.4.7 and probably will not be able to change to 3.0 for at least six months or more after a final version is released.  In the meantime, I've found several things that we really wanted support for in our templates but that are not supported due to the current very limited use of regex patterns in SSViewer.

  Our other goal in building this site is to customize the actual sapphire and cms modules as little as possible.  We really want the code there to be as close to identical with the publicly released versions as possible.  This will keep our upgrade path much cleaner.

  So, trying to balance our templating needs and our desire to run "stock" SS as much as possible, I needed a way to extend SSViewer without making lots of changes to the template parsing code.  To do this, I wanted to have the ability to add extensions to SSViewer that could contribute to template parsing.  Well, since SSViewer doesn't extend Object that was out of the question.  So I came up with a very similar idea.  You can see a diff of this idea at link [1] below.  Please review this and give me your feedback.  For those who are interested to see what an extension that's added to my solution below looks like, you can check out [2].  That's not the prettiest code in the world, but it's a proof-of-concept.

  Looking forward to 3.0: I've also reviewed the template code in the master branch and see that you're using php-peg to create your own grammar.  I like this approach a lot better than the current regex-based approach.  But, I still would like to ask: how do you plan on making this extensible?  So much of SS focuses on making things extensible where folks can plugin their own functionality.   I was very surprised to see how brittle and not extensible the template parsing code was (in 2.4).  Do you have plans for allowing some sort of plugin template parsing functionality in 3.0?  Or is the plan that someone would need to edit their copy of the SSTemplateParser.php.inc file?

  Thanks in advance for your input.

[1] http://www.sspaste.com/paste/show/4f961b72e9cf5 - my change to SSViewer to call extensions
[2] http://www.sspaste.com/paste/show/4f961c2a0816a - an example of an extension that can be added with Object::add_extension('SSViewerExtensionHost', 'SSViewerExtension');

Best Regards,
Jeremy Thomerson

--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To post to this group, send email to silverst...@googlegroups.com.
To unsubscribe from this group, send email to silverstripe-d...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/silverstripe-dev?hl=en.

--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To post to this group, send email to silverst...@googlegroups.com.
To unsubscribe from this group, send email to silverstripe-d...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/silverstripe-dev?hl=en.