Expression Engine Template Parser

[eluser]Mirage[/eluser]
Hi,

just wondering if anyone has taken a crack at enhancing the CI template parser with the powers of the EE template class.

I'm particularly liking and looking for the feature of having the content of a tag passed to it's bound function. Further I'm liking the approach of EE dynamically loading the plugins and mods when it encounters a tag. That's not so hard.

But what makes my head hurt is figuring out how to parse and properly resolve [nested] tag pairs and I'd rather be productive.

The reason I'm looking for this functionality is that it provide a very nice approach when working with cms and modularized content.

No need to chime on how to embed views within views. Been there done that 10 different ways. It's easy with CI. The major rubbing point with all codebased approaches is that I need to be able to cut the controller out of the equation and remote-control things from the view. EE is doing it perfect IMHO. As long as I can stay with MVC, the CI approach is fine. But when it comes to CMS things change and logic moves to the template. PHP as a template language is fine [for me] also, but it's much more verbose than what EE templates provide.

Can't get myself to move to EE for my projects because I only need this for parts [i.e. non-application: read 'pages'] of a given website and I'd be missing too much of CI. :-)

Hope that someone can help, otherwise I'll probably bind to SMARTY.

Thanks

[eluser]Code Arachn!d[/eluser]
I agree with your desire to advance the template parser - and right now I'm hitting a brick wall about the where the logic should be built to allow for modularization as well as preserve mvc and flexibility. At my last place of employment we used a java/xml cms app. It had a unique method of templating - basically it used a method of hierarchy with the xml files from site config all the way down to the individual page. The beauty of it being XML and how the hierarchy was setup that you had "master" configs that would define in the following order "site wide" > "section" > "group" > "individual page". I still haven't really found a way to translate this over to a rdms concept from the flat file system where consistency wasn't really a set in stone part.

Another idea I've had is to build some sort of search method and then have the complete site indexed so that templating system works similar to how content is retrieved.

Like you've said view-in-view just doesn't cut the need - I think there needs to be some sort of hierarchy aspect at least then it has a chance at being more modular. The closest I've had is to build some of the logic into columns for both the template and page tables - but this fails when it comes to proper development. For my use it's not too limiting - I just wonder if CMS theory should be more expanding to get away from page development and back to modular media/content items and then via the search method mentioned above both the templating and the content are grabbed and displayed... One question I have to this approach would be how to build the templating system separate so that it would be dynamic based on use, and application (i.e. mobile, rss, screen, printer friendly...)

[eluser]Rick Jolly[/eluser]
Nice to see you're still around Mirage. I was wondering you'd come up with a CMS strategy since you posted this: http://ellislab.com/forums/viewthread/51469/

I could be wrong, but it seems to me that EE tags have a fairly tight relationship to their underlying functions. Would a CI twin of EE require every function to need its own tag and attributes? If so, that might be a lot of work to maintain. Also EE tags are elegant, but a lot of logic still ends up in the view.

Something really simplistic that I've been toying with is a loose interpretation of the Hierarchical Model View Controller (HMVC) pattern. It allows me to create isolated modular view fragments that can be loaded directly in the view - no controller modification necessary. So, for example, if I want to plug a menu into a main layout view, I'd load the menu partial complete with its data directly in the main view.

So the main controller just loads a layout template. Within the template I can load controller-like libraries via a single simple helper:

Code:

// Very simple helper for loading a library to return a view complete with its unique data
// The function could be enhanced to call a specific library method with parameters defined in the view:
// function load_view($controller_library_name, $method_name=null, $array_parameters=null)
function load_view($controller_library_name)
{
   $CI =& get_instance();
    
   // strip off the .php file extension if added
   $file_name = str_replace(EXT, '', $controller_library_name);
   $file_name = strtolower($file_name);
        
   // load the library
   $CI->load->library($file_name);
   // call a default index() method which returns a partial view with data using $CI->load->view('view_name',$data,true);
   return $CI->$file_name->index();
}

Each controller-like library is responsible for loading a view fragment complete with all its data and inserting it within the main layout view.

I've just done some basic things where all inputs that any partial view requires are available from the CI instance (uri, post, session). However, it would be easy to add an optional method name and an array of parameters to the helper function. That way the view would remain clean and the underlying controller-like libraries could do almost anything required - I think:-)

Using this generic HMVC approach I can nest partials within partials to any reasonable depth. It is incredibly simple to add/remove dynamic content to a view. The work is in creating the underlying libraries that get the content for their respective partials. These libraries work just like controllers. By getting the CI instance, they have access to everything that a regular controller has. I haven't worked with this enough to know if there are any pitfalls though.

[eluser]Mirage[/eluser]
[quote author="Rick Jolly" date="1188382962"]Nice to see you're still around Mirage.[/quote]

Hey Rick! Thanks for chiming in. Yes I'm still around - Reading the forums regularly, just haven't been posting much. I'm igniting all day every day. CI has made me so productive my clients are just inundating me with web work. [ I'm not complaining :coolsmile: ]

I was wondering you'd come up with a CMS strategy since you posted this:
http://ellislab.com/forums/viewthread/51469/

It's getting better with every site. The good thing that's happening is that I'm getting to work on a lot of different sites and so I'm exposed to all kinds of requirements which help me refine my thoughts and approaches. The main focus is on bread and butter though so it'll be a while before I'm ready to show something. Every site I've been doing uses a slightly different way of solving the CM issues so it's a hodgepodge from a 500ft view.

I could be wrong, but it seems to me that EE tags have a fairly tight relationship to their underlying functions.

Yes it does. I've looked a the template library and there are loads of dependencies on the underlying structure. Which is why I asked if someone else maybe done it. I've been searching around for a post from Rick, where he gave some hints at extending the capabilities of the template parser. But I can't find it for the life of me.

Would a CI twin of EE require every function to need its own tag and attributes? If so, that might be a lot of work to maintain. Also EE tags are elegant, but a lot of logic still ends up in the view.[quote]

I don't have a problem with view logic in the view. Though I'd like it to be a bit less verbose sometimes.

[quote]Something really simplistic that I've been toying with is a loose interpretation of the Hierarchical Model View Controller (HMVC) pattern. It allows me to create isolated modular view fragments that can be loaded directly in the view - no controller modification necessary. So, for example, if I want to plug a menu into a main layout view, I'd load the menu partial complete with its data directly in the main view.

Yes, I started using something like this as well. Within the current view I'd call a 'plugin' to which I pass parameters - on of them a template name - which it then loads and processes and echo the output. So instead of

Code:

{exp:weblog:entries weblog="{my_weblog}" orderby="date" sort="desc" limit="15" disable="member_data|trackbacks"}

<div class="entry">
    {date_heading}
    <h3 class="date">{entry_date format=' %l, %F %d, %Y '}</h3>
    {/date_heading}

    <h2 class="title">{title}</h2>
    {summary}

   {body}
</div>

{/exp:weblog:entries}

I'd write:

Code:

<?= $cms->weblog->entries('my_weblog','my_template',array('order_by'=>'date','sort'=>'desc','limit'=>'15','disable'='member_data|trackbacks') ?>

Where my_template is the id of a record or file holding the template which the function can then load. Nesting is pretty easily resolved, though you're always parsing 'inward'. It pretty much accomplishes the same thing as EE does. I just really like their way of allowing the sub-template to be inside the parent-template and the parser extracting the template data and making it accessible to the function. Same as smarty does.

But maybe your [and mine] alternative isn't so bad either. A bit more verbose. But otherwise definitely an alternative.

Cheers!