template parsing - conditional blocks

[jl5501]

Ok, I have what is becoming quite a large live site that uses a lot of total custom template areas for generating some content pages and email content etc.

 

This system builds pages from various sub-templates in various orders, and parses using the usual {PLACEHOLDER} syntax with str_replace() handling the conversions.

The definition of the placeholders and their values are configurable in the custom admin and change according to various parameters.

 

All this works well, but now I need to extend it to conditional blocks, and wondered if anyone has any pointers as to how to proceed.

 

I would need this sort of structure

 

{IFGREEN}

    {THIS1}

    {THIS2}

{ELSE}

  {THAT1}

  {THAT2}

{IFGREEN}

 

so basically all other placeholders would be processed normally, except that the conditional blocks would only be parsed according to the conditions.

 

The only code I have, is the code I have written for the existing working live system, which does not have this conditional block capability

 

I know the major templating engines have similar structure to this, so there must (in my view) be a relatively simple answer.

 

Perhaps a use for preg_replace_callback() - I am not sure

 

Any pointers appreciated

[trq]

Why wouldn't you use php?

 

if ($green):
  echo $THIS1;
  echo $THIS2;
else:
  echo $THAT1;
  echo $THAT2;
endif

 

Far more efficient and likely easier (or at least as easy) for any designer to learn to use.

[jl5501]

it is parsed by php, but the template placeholders are in the text in the db.

 

so nornally the placeholder {VAR1} would be handled by str_replace and replaced according to various logic, which is working fine.

 

But I want the block parsing to find the start of a block and parse inside that for the original condition until the else or /  placeholder is found.

 

I know templating engines such as Open Realty and probably joomla have this sort of conditional parsing, but not sure how it is done.

 

Actually looking at what you say may have some merit, as the {IF.. {ELSE} {/} blocks could be parsed first and changed to appropriate php logic, which could then control the parsing of the elements in the relevant branch.

 

So in that case it means I have to collect all the possible conditional blocks that have been set up and parse those first to arrive at the conditional code, which would then govern what to parse inside the condition

 

Does any of that make sense?

[jl5501]

I have just checked how OpenRealty does it.

 

What it does, is use preg_replace to change the unneeded branch to '' before parsing the rest. so cannot handle an else condition.

 

If I were to do it that way I would need a {IFGREEN} {/IFGREEN} block and a {IFNOTGREEN}  {/IFNOTGREEN} block

[jl5501]

It would seem that there is no better way to go about this, then to null the area you do not need to be parsed, in the manner OpenRealty uses.

[trq]

I am aware of what your trying to do, I just don't see the benefit.

 

Seriously, as you are now discovering, templating engines are very inefficient. Its just another layer that really isn't required. Your basically writing a mini-language of your own and having it parsed by a scripting language.

[gizmola]

Not to mention that there are already templating engines out there like Smarty that could be dropped in to replace what you have.  Yes you'd have to do some conversion of the existing templates but since they are already so incredibly simple, some simple search and replace macros would likely take care of the changes for you.  Then you're not reinventing the wheel.

[jl5501]

This is true, they are immensely innefficient, but I do not see a viable alternative for this.

 

What is required, is the ability to have boilerplate layouts for various on screen and email documents, which are then replaced by actual data when processed. This particular enviroment is for people signing up for an electricity provider, where you have various options, and various partners involved, all with different prices and other logic that needs to be applied per partner and per utility.

 

These layouts/templates need to be stored in the database, and retrieved at run-time and processed.

 

Now if there is a more efficient way of achieving that goal, apart from the one employed by the majority of templating engines, then I would be very pleased to hear about it.

 

In general, I would agree that anything that has to read strings and replace characters, in the way str_replace() does, are extremely inefficient, but I have not seen, or been able to devise, a better method of achieving the same goal.

 

As it happens with this site running on a dedicated server, with a separate server for the db, and traffic being low, then efficiency is not a major concern. That being said, things could change, and one should always aim to write code efficiently in any case.

[trq]

First question is why would the templates need to be stored within a database?

[jl5501]

Thank you gizmola, but smarty would not be very high on my list of choices to build a site with.

 

The main part of this site is a couple of large complex signup forms which do not require any templating. I have a series of ordinary definable variables to customise these forms per partner without issue. It is just in the output and email sections that need the templating, and some of the ancilliary pages.

 

I have worked with smarty, and several times have taken a smarty site, and rewritten it as a custom site, with good results. I also rewrite joomla sites as custom when people get frustrated with not being able to get joomla to do 'exactly' what they want.

[jl5501]

Ok the templates, or the areas that are templated now, need to be editable by a non-technical administrator, and laid out to their requirements, with placeholders left for variable information to be included.

 

If there is a way of doing that without storing the template in the database, then I would be glad to hear of it

 

If you like, I can provide you with an admin login to the QA area of this server, so you can see all I have done with it so far

 

[trq]

If there is a way of doing that without storing the template in the database, then I would be glad to hear of it

 

Its should be just as easy to store these templates on the file system and the main benefit will be that you can include them into your processing scripts to be executed as normal php files. You can even store the paths to these templates within the database so it is easy to relate what data needs to be pulled out for each template.

 

It sounds like a similar system to that that I've built before. I would have a page object that gets its data from the database, this data would be article objects and each of these would pull the data it needs to actually make an article as well as a reference to the template partial. All this would get stored within the page object.

 

From there you would simply call the page objects render method which would include each template partial into a buffer, parsing any php along the way.

 

Of course, the only real downside here is that you have opened your templates to include php code. In the wrong hands, this could be an issue. But there's always ways around that too.

[gizmola]

Thank you gizmola, but smarty would not be very high on my list of choices to build a site with.

 

I have worked with smarty, and several times have taken a smarty site, and rewritten it as a custom site, with good results. I also rewrite joomla sites as custom when people get frustrated with not being able to get joomla to do 'exactly' what they want.

 

There is no such thing as a "smarty" site.  Smarty is simply a library that provides the type of templating and markup that you asked about.  It also has nothing to do with joomla.  I don't know why you brought that up, but it makes me question whether or not you actually know what it is. 

 

I'm not irrationally in love with smarty --- some people love it, some don't.  But one of its benefits has always been that it parses the templates into php code and caches these precompiled versions, so you don't have the overhead of reading in templates and doing search and replace on variables.  Smarty is used on plenty of big name sites.

 

With that said, it seems that what you really want is some sort of highly customized wysiwig system that hides all the details from the users, yet is ultimately flexible.  Sounds like a lot of time and effort would need to be invested to create such a system, and the irony is that on one hand these users are apparently suppossed to be sophisticated enough to drop markup into the middle of templates and reference variables, yet, you describe them as "non-technical."

[jl5501]

That sounds very interesting and may well be a route I could follow.

 

The only thing I do not see in there ,is how the administrator can visualise the layout he wants in an editor environment, and specify where he wants the variable content to appear

[gizmola]

That sounds very interesting and may well be a route I could follow.

 

The only thing I do not see in there ,is how the administrator can visualise the layout he wants in an editor environment, and specify where he wants the variable content to appear

 

Ajax.

[jl5501]

Gizmola, the only reason I mentioned joomla, was as another example of a templating engine which although a little more sophisticated then smarty, is to my mind at least, built on similar foundations. Your comment on a 'smarty site' is accepted, just that there are a lot of cases where smarty is used for the entire site, so that makes it a 'smarty site', again in my mind. Just a question of terminology I suppose.

 

With that said, it seems that what you really want is some sort of highly customized wysiwig system that hides all the details from the users, yet is ultimately flexible.  Sounds like a lot of time and effort would need to be invested to create such a system, and the irony is that on one hand these users are apparently suppossed to be sophisticated enough to drop markup into the middle of templates and reference variables, yet, you describe them as "non-technical."

 

There you have hit the nail on the head, but the current system does not expect the 'non-technical user' to enter the placeholders himself. He selects from a dropdown or popup menu, what he wants, and just knows to not touch what the editor places in the file

[trq]

You could quite easily write a method within the page object that could produce a page without any content. I kinda confused my example in my previous post, the system I built actually keeps track of the template partials through a simple config for each page object.

 

Anyway, we can't really go into the nitty griity in a simple forum post but what I'm trying to get at is there is other ways besides writing your own language and parser.

[jl5501]

I am very interested in your page object approach, thorpe, and will look into how I can achieve the desired results. Unfortunately with this being a live site, and constantly having new feature requests, then a architecural change is not likely to be on the cards for a while.

 

I would quite like to share some of the code of this site with you, as I think some of what I have done with it is quite interesting, but there again I would think that. I would be quite happy to bundle up the code for this site, and put it somewhere you could look at it, but then would like to know your general thoughts on it.

 

Basically all that has been done so far, is basedo n a functions library I wrote for it, rather then a OOP approach. I would be interested in your views as to whether moving to a wholly OOP architecture would improve things in any way.

 

Although I have worked on many OOP projects, and am quite happy to do so, I still tend to do projects which are written from the ground up, in a non-OOP way, simply because I have been writing code since way before OOP was widely accepted, unless you count smalltalk.

 

Sorry for the ramble, and I do think you have given me some useful pointers on this

 

[gizmola]

Gizmola, the only reason I mentioned joomla, was as another example of a templating engine which although a little more sophisticated then smarty, is to my mind at least, built on similar foundations. Your comment on a 'smarty site' is accepted, just that there are a lot of cases where smarty is used for the entire site, so that makes it a 'smarty site', again in my mind. Just a question of terminology I suppose.

 

But there's no comparison.  Joomla is a CMS which includes its own database schema, objects, user authentication, controller structure, modules, templates etc. etc. etc.

 

Smarty is just a simple templating library.  About the only thing the 2 have in common is that they are both written in PHP.  One is a developer library that is by its very nature nothing but a library that goes in a developer toolbox, and the other is a working site.  Comparing them is beyond apples and oranges.

 

Now let's just say for a moment that you built a wysiwig ajax page that allowed people to move around blocks and widgets, and put placeholder variables in certain locations.  Ultimately what would you want to do with this?  One completely viable answer, is that the system would write out a template file.  This would still go back to the original question, which had to do with how you would implement conditionals (and possibly looping, partials etc.) .  Eventually you will get back to the same issues that thorpe and I have both brought up.  You could have this write out any sort of template file you wanted.  If you want to go ahead and rewrite something that already exists in various template libraries out there, nobody is going to stop you from doing so.  That doesn't change the fact that the functionality you originally requested already exists in these template solutions. 

 

The wysiwig requirement is a red herring and has nothing to do with the original question you asked.  It seems to just go back to the NIH (not invented here) arguments you made, that involve a simple solution to a simple problem, and which are no longer applicable because the new requirement exceeds the capabilities of the design of the original system. 

 

In the abstract, it's hard to say much more to help you.  You'd definately be better posting specific targetted code examples, along with specific examples of what the new requirement is, and perhaps people could offer you something that's actually usable.