We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 22303 MODX Staff
    • 10,725 Posts
    Quote from: TobyL at Jun 03, 2006, 07:47 AM

    To each his/her own but I cannot see the real benefit here. Great coding Marc, but aren’t you just introducing an unecessary layer of complexity? I like the idea of combining different ’template’ chunks into one bigger one but when it comes to parsing all kind of logical structures it doesn’t make much sense to me anymore. This is creating an interpreter for another (level of) programming language by an interpreted programming language. Why not just use php for the logic? Am I missing something?

    @TobyL: I have to agree here. This is an unnecessary layer of templating that IMO goes against the concepts of simplicity that make MODx so wonderful. If I wanted logic in my templates, I would have chosen Smarty or patTemplate, or another mature templating framework. But I chose MODx because it did not have this extra layer which promotes the mixture of logic and presentation; all the while I’m trying to completely separate the two, so the roles of designer and developer can be easily drawn for a project built with MODx.

    All of this can already be achieved through MODx tags and resources, and additional tag parsing capabilities coming soon will help make this capability even clearer (i.e. relationships between chunks, or a chunk and a snippet, etc.).

    For instance, one quick current approach off the top of my head for looping over templates: use $modx->parseChunk($chunkName, $assocArray, $prefix, $suffix) to apply values to a chunk within a simple for/foreach loop within a snippet. And someone could easily write a snippet that was a generic loop snippet that used parameters to define the chunk, the source of the values to replace, etc., and TV’s already afford simple ways of approaching conditionals. I just don’t see the value in reintroducing logic to chunks, templates, or any element that should be returning pure ( X )HTML content.

    Now that’s not to say that there isn’t a place for this template library, or even for using another 3rd-party template library, like smarty, to build a site in MODx with. It ultimately just depends on your specific goals and project requirements, but many others have expressed this same dismay at introducing another layer responsible for templating when PHP itself is specifically designed for this task.

    I think it’s a matter of people being used to developing/designing in one way, a way made very popular by traditional PHP scripting, JSP, ASP, etc., and finding/understanding alternative approaches can be difficult. It’s nothing short of a paradigm shift, and crossing that chasm can take a leap of faith in this industry, where new technology trends come and go very quickly.

    But again, like you said TobyL, to each their own. Cheers...
      • 32241
      • 1,495 Posts
      I can see that this library has gained popularity since I left.
      So before I continue the discussion, I would love to share the case that I’ve encountered before creating this library.

      Case problem:
      When I first created my calendar snippet that is still in beta version, and will always be in beta version, I’m having problem with organizing the template into several chunks, and when I said chunks, it’s not only 2-3 chunks, but it has about 10-20 chunks. Can you guys imagine creating all those chunks just for a single snippet customization?

      Analyzing the case:
      After having those inconvinience, I have a thought, "How about if we can have 1 chunks as a template that serve the customization of this calendar snippet?". But for now there is no visible way to do that in one chunk.

      Case solution:
      After considering everything, there is no possible way to do it without any additional syntax that will serve as the divider inside the chunk template, which is this tag {[=TplPart name_of_chunk_tpl_part=]}.
      So those tag will serve as separation of a single chunk into several template parts that can be assembled later on by the logic of the snippet.
      But that alone won’t be enough, so I implement the logic of placeholder or content variable inside the library to parse a variables into the template. Now we have all those basic idea and logic, but that alone won’t be enough as well, so I implemented a possiblity in adding function to process the variables before being parsed into the template, which in this case you can defined the name of the function and all the parameters needed inside the template variables placeholder, such as this {+var_name;function_name;param_name1:param_value_1;param_name_2:param_value_2+}. After I’m done with this, I stop the whole core library development of the template, and decided that this will be the right simple library that will be needed in all our snippets.

      Analyzing the current core solution and improve it:
      I do notice that there are some limitation in this approach, which make this template is not as powerful as the other tpl library out there like what Jason mentioned above, but I believe this lib does serves its purpose, which is to keep everything simple and easy-to-understand, without adding another layer of templating logic on top of MODx, which usually take more resources power. But later I decided to add several helper function such as outputRepeater, outputCondition, outputTemplate, to help MODx developer use this library easily in formating their chunk template output, in case if they need looping or conditional template, which is I found it really ueful for now. I also added a theme helper function to let developer include default themes support in their snippets, so people can choose the the theme template that they want (has to be included in the snippet package), or they can just create a new customize template in chunk. All of this just an additional to the current core logic of this library.

      But the fact that the resulting template can be quite confusing is true, which where Marc comes in with his idea in integrating a simple conditional and looping syntax inside the library. I believe all those addition is not meant to substitute patTemplate/Smarty, but it’s just an improvement to the core features that I hesitate to include it before. But I believe he’s taken the right step, considering the resulting template looks more readable and easy-to-understand. So before going any further, this improvement to the core library is kinda optional, people still be able to use the improved library to work as what it’s suppose to be, before marc improve it with just a l ittle bit of performance lost compare to the original version (which you guys as a developers won’t notice it). But for some snippet developers, they can use this library to improve the usability of their snippet, allowing common user to create their own template without any hard coding template inside the snippet code. So I believe this library won’t be adding an extra layer of templating into the current MODx architecture, but it will work hand-in-hand with the current concept & architecture of MODx core system.

      My last note:
      Keep em coming marc, but make sure that you’re still keeping the original core concept, which is to serve as a library in separating a single chunk into several template parts. So it’s up to the snippet developers to choose whether they want to use the full functionality of the template library or not.

      PS: Please inform me when you’re done with the looping logic for this library. I’m looking forward to test it out for you. Send me an email, because I’m hardly able to access this forum everyday.
        Wendy Novianto
        [font=Verdana]PT DJAMOER Technology Media
        [font=Verdana]Xituz Media
        • 7923
        • 4,213 Posts
        Quote from: Djamoer at Jun 10, 2006, 12:32 AM

        Keep em coming marc, but make sure that you’re still keeping the original core concept, which is to serve as a library in separating a single chunk into several template parts. So it’s up to the snippet developers to choose whether they want to use the full functionality of the template library or not.

        PS: Please inform me when you’re done with the looping logic for this library. I’m looking forward to test it out for you. Send me an email, because I’m hardly able to access this forum everyday.
        Yes, the library will be kept and used as the way you originally designed it, that is multiple template chunks in one template. Only the extra logic is made possible also, ie. conditionals (if, else, switch) with value checking and looping of arrays. But it’s not needed to use any extra logic ofcourse if users don’t want to do it, it’s just made possible.

        Like for example in the MaxiGallery snippet default template, there will be a section like:
        {~switch (=BigImgLinkStyle=)~}
        	{~case (=slidebox=)~}
        		{~<a href="{+LargeImage+}" title="<b>{+ImageTitle+}</b><br />{+ImageDesc+}" rel="lightbox"><img src="{+Picture+}" class="imageview" title="{+ClickToOpenOriginal+}" alt="{+ImageLabelDate+}: {+ImageDate+}" /></a>~}
        	{~case (=lightboxv2=)~}
        		{~<a href="{+LargeImage+}" rel="lightbox" title="<b>{+ImageTitle+}</b><br />{+ImageDesc+}"><img src="{+Picture+}" class="imageview" title="{+ClickToOpenOriginal+}" alt="{+ImageLabelDate+}: {+ImageDate+}" /></a>~}
        	{~case (=popup=)~}
        		{~<a href="javascript:void(0);" onClick="javascript:openWindow(\'{+LargeImage+}\',\'{+ImageTitle+}\',\'{+window_height+}\',\'{+window_width+}\',\'gallery\')"><img src="{+Picture+}" class="imageview" title="{+ClickToOpenOriginal+}" alt="{+ImageLabelDate+}: {+ImageDate+}" /></a>~}
        	{~default~}
        		{~<a href="{+LargeImage+}" rel="external"><img src="{+Picture+}" class="imageview" title="{+ClickToOpenOriginal+}" alt="{+ImageLabelDate+}: {+ImageDate+}" /></a>~}
        {~endswitch~}
        


        But if snippet user is making his own template and he knows that he will be using just lightBox in the gallery that uses his template, he could replace all this with just:

        <a href="{+LargeImage+}" rel="lightbox" title="<b>{+ImageTitle+}</b><br />{+ImageDesc+}"><img src="{+Picture+}" class="imageview" title="{+ClickToOpenOriginal+}" alt="{+ImageLabelDate+}: {+ImageDate+}" /></a>
        


        So if user is doing a template in his own specific gallery setup, he probably don’t have to use much or any logic code in the template, but it is still made possible to use, so users can build up very customizable outlooks. And we can also make multiple default templates to choose from which all can work in whatever gallery setup when we check certain parameters in the template code.

        If users want to change something in the default outlook of a gallery, its still very easy even if there is little logic code around it, because the logic is very readable. And much easier to edit that than the snippet, won’t brake anyting.

        The other way we could achieve the same thing in the current state of modx would be that we would move all the logic code from the template to the snippet and then ship the snippet with hundred chuncks to all possible occasions what users could modify. Then in the snippet side we would decide what chunck content to replace to what placeholder in "main template" of the gallery etc. But I think that it’s much easier for user to work with a single template with minimal easy-to-read logic code than manage tens of different chuncks and wondering what goes where in the gallery output. Or we could use much more general placeholders and make the templating more basic, but that would be just stupid.

        All in all, great work Wendy and Marc with the templating library, can’t wait to see it fully implemented in MaxiGallery!

        And I’m not in anyway against your principles OpenGeek and TopyL, I’m all for it to separate logic from the templates, but I can’t see an easy way to do it in the current modx. And OpenGeek said it best in the irc to me last time, it’s all up to your target group. My target is website developers who knows how to work around frameworks and simple logic code. smiley So I’ll definitely use this.

        Everyone can use what they want, but I think that atleast the "joining several template chunks in one chunk" -possibility of this library should be straight in the modx core. But then in the other hand, snippet developers can just use this library if they want and ship it with their snippets.

        What I am a bit worried of is, that to the snippet end users it may look a bit confusing when some snippets use different placeholder syntax than others.. ie. {+placeholder+} vs [+placeholder+] etc...



          "He can have a lollipop any time he wants to. That's what it means to be a programmer."
          • 25663 MODX Staff
          • 12,272 Posts
          On the issue of organization of chunks as templates, why not just simply implement a categorization feature, so that you get the benefits of clearly organized groups when you need 10-20 chunk templates?
            Ryan Thrash, MODX Co-Founder
            Follow me on Twitter at @rthrash or catch my occasional unofficial thoughts at thrash.me
            • 32241
            • 1,495 Posts
            Quote from: rthrash at Jun 10, 2006, 12:41 PM

            On the issue of organization of chunks as templates, why not just simply implement a categorization feature, so that you get the benefits of clearly organized groups when you need 10-20 chunk templates?

            I thought of that before, but it requires a modification on the current backend. The benefit will be, soon or later chunks, snippets, plugins, templates, and plugins will need a better categorization to organize them nicely, but I don’t see any clear benefit of it that out weighted the current chunkTpl library. If I did that modification asyou mentioned above, it will improve the current core system, but by using chunkTpl, designer will be able to see all the templating code on one view. I believe in the next release, 1.0, we need to make a backend categories system, to allow every resources to be categorize, and maybe we can add a feature on chunk/template admin to view all the chunks/templates under the same category to be viewed all at once and edited together on one page. For now, I will settle down with chunkTpl to keep the core system as light as possible, and let the rest of the features being added as separate libraries/snippets/plugins/modules. But it’s all depends on the snippets developer.

            Sincerely,
              Wendy Novianto
              [font=Verdana]PT DJAMOER Technology Media
              [font=Verdana]Xituz Media