22 Replies Latest reply: Oct 15, 2014 4:41 AM by Daryl Barnes RSS

    Syntax for module's named parameters - need your feedback

    Lucian Cozma Adobe Employee

      Hi all.

       

      We would like to make an improvement on the liquid’s syntax for the module’s named parameters and we need some input from you. We talked with a few of you “live” at Adobe MAX about this, and we would appreciate some input from more of you.

       

      How to specify if the module’s output is suppressed or not?

       

      Current syntax is, for the module_webapps for example:

       

      {module_webapps id="stores" filter="all" template=""}

       

      Basically, specifying an empty template will suppress the output of the module and will capture the module’s data in a variable who’s name it’s auto-generate. For example, creating a page with the following code will suppress the output of the module and generate a variable in the page called “webapps_0” what contains all the data generated by the webapps module (you will see this information in the “this” variable outputted as JSON).

       

      <!DOCTYPE html>

      <html>

      <head>

      <title>Untitled page</title>

      <meta name="description" content="" />

      </head>

      <body>

      {module_webapps id="stores" filter="all" template=""}

      {{this|json}}

      </body>

      </html>

       

      This syntax can be confusing, so we would like to change this into:

       

      {module_webapps id="stores" filter="all" render=”nothing”}

       

      Basically, add a render=”nothing” parameter that, if specified, will suppress the output of the module.

       

      How to specify the variable in which a module data is captured?

       

      For the above example, if we would like that the data is not captured in a automatically-generated variable, currently you have to do it like this, using the “collection” parameter.

      {module_webapps id="stores" filter="all" template="" collection=”myStoresVar”}

      {{myStoresVar |json}}

       

      This can also be somewhat confusing, so we would like to replace with:

       

      {module_webapps id="stores" filter="all" render=”nothing” var=”myStoresVar”}

       

      How to specify how to render a module that renders a list of data?

       

      Currently the template you specify to the webapp module specifies how to render a single-item of data. So if I had a module in a page like this:

       

      {module_webapps id="stores" filter="all" template="/before-after/item.tpl"}

       

      And the item.tpl would be:

       

      <div>

      <h1>{{name}}</h1>

      <div>{{description}}</div>

      </div>

       

      The item.tpl would contain the template of a single item and the module would loop through every record resulting in an output like:

       

      <div>

      <h1>Starbucks #240</h1>

      <div><p>Starbucks - 505 S Flower St Los Angeles, CA 90071</p></div>

      </div>

      <div>

      <h1>Starbucks #308</h1>

      <div><p>Starbucks - 735 S Figueroa St #308 Los Angeles, CA, 90017</p></div>

      </div>

       

      But if you want to be able to control in the template the layout of all of the things the module outputs (and get control of the loop), you currently have to do things like this:

       

      {module_webapps id="stores" filter="all" template="/before-after/list.tpl"}

       

      And in the list.tpl:

       

      <!-- Liquid Enable Collection -->

      {% for item in items %}

      <div>

      <h1>{{item.name}}</h1>

      <div>{{item.description}}</div>

      </div>

      {% endfor %}

       

      Notice that comment at the beginning of the template. That instructs BC that the template is not for a single item, but for the entire list, and so you get access to the ”items” of the collection so that you can control the loop yourself.

       

      The usage of the comment can also be confusing and more difficult to understand so we would propose not to use a comment in a template but use the same render=”” parameter, but with another value:

       

      {module_webapps id="stores" filter="all" render=”collection” template="/before-after/list.tpl"}

       

      And remove the comment from list.tpl:

       

      {% for item in items %}

      <div>

      <h1>{{item.name}}</h1>

      <div>{{item.description}}</div>

      </div>

      {% endfor %}

       

      What do you guys think?

       

      In this way we would have a consistent and simple way to define how a module is being rendered and how:

       

      {module_webapps id="stores" filter="all" render=”collection” template="/before-after/list.tpl”} to get access in the module to the entire collection to loop through the items ourselves or

      {module_webapps id="stores" filter="all" render=”item” template="/before-after/item.tpl”} to define only how every item looks and have the module loop for me (render=”item” would be by default to insure backwards compatibility, and in the template I am able to access the values directly).

       

      Any thoughts on this?

       

      -Lucian

        • 1. Re: Syntax for module's named parameters - need your feedback
          Karim - dashbee.com MeganK

          Hi Lucian,

          I like this suggestion a lot

           

          I think using a parameter like render makes much more sense than a specific comment in a template file.

           

          Karim

          • 2. Re: Syntax for module's named parameters - need your feedback
            Digital Fuel Web Community Member

            These look great. Much simpler.

             

            Could render=”nothing” also be activated with render=”” I Like the change to render much easier to understand. The "" to represent nothing part of the old version did make sense to me at least. but understand why "nothing" needs to be an option also.

             

            Daniel

            • 3. Re: Syntax for module's named parameters - need your feedback
              inthevine Community Member

              Sounds great Lucian,

               

              I agree with Daniel above about render="nothing" also be activated with render="".

              • 4. Re: Syntax for module's named parameters - need your feedback
                Gary Swanepoel | ITB Community Member

                Hi Lucian, I assume because of the ways it's currently setup with the commented out tag that's there's no way to auto-detect whether we're taking control of the loop or not? If I add the instruction to run a loop in the .tpl  with {% for item in items %} that should the tell me to manually run through the loop which means we don't need an extra parameter and keep template="" for supressing the output?

                 

                I don't really understand the difference between flagging collection vs item so I'm going to run some more tests and try and get my head around this.

                 

                Buy my initial input below. I'm always in favour of as little parameters/markup as possible.

                 

                * I can see this happening  {module_webapps id="stores" filter="all" render=”nothing” template="/before-after/list.tpl"}
                * template="" makes sense to me because I'm suppressing the template in favour for a variable which i use on page, otherwise in favour of render=""

                * could an option be template="CollectionName" because there's no *.tpl it knows to create the variable instead?

                • 5. Re: Syntax for module's named parameters - need your feedback
                  Liam Dilley CommunityMVP

                  I have to say I do not agree with this.

                  Gary is 100% on the render="nothing" template="" Issue, This is making it too simple with to many options and create more confusion. This is new stuff and if it is in the documentation very clearly then people will follow it. If you are confused it is because something is one way before and now it is different, this is not the case here. I think people are over thinking it here and I see it causing more problems.

                   

                  So you have the render=""

                  This does not really factor in anything in BC currently, so it is very new and actually does not mean anything. template means to push your content to a new template, people have already been introduced to this.

                  template="" is very similar to other code syntax, you could argue that template="none" is another option, but I think you should need to specify the template.

                   

                  I disagree with Gary though on the template="collection" bit. This again creates mixed messages, more confusion. A collection is not a template of data. A collection is just that, it is a complied set of data you can use - A collection. This is a misunderstanding of what it is again, not confusing syntax - Reading and learning and documentation is important.

                   

                  I also disagree totally disagree with the concept of the var=""  - This suggestion has not been thought through. You already have a different method to set parameters, and in coding in languages var sets a parameter... This will actually create more confusion.

                   

                  This is about good documentation, not spending time on the syntax. I feel quite strongly on this.

                   

                  I know these suggestions are not from you guys Lucian, but I do not like them, sorry folks. I do not think the scope and what they mean has been thought through. This is coming out before more people start to use it, I think this is to small of an opinion to then be spending time messing with this, I am open to some things if they are a bit confusing but this will open up a can of worms.

                   

                  PS:

                   

                  In terms of {module_webresource I think you can just go {module_resource It is shorter and gives you more scope to expand on it if you need to. (Although I still like module_godmode )

                  • 6. Re: Syntax for module's named parameters - need your feedback
                    Liam Dilley CommunityMVP

                    Other note:

                    Since a tag with an array of data can also include a collection the above suggestions would become even more confusing as a note.

                     

                    My Suggestion:

                    Less is more.

                    Right now you have the concept of a module which by default has a list and list backup. If you include template="" it uses a custom template. Without it then it uses the default.

                    With the new rendering engine a module works as normal, can have a custom template. If you include collection it knows to behave differently.

                    IF you have a collection and do not include template="" then it should know not to need it, template="" should also be valid still.

                     

                    The likely scenario I see people doing is including collection but not including a template. Introducing 2/3 methods for one output action is a bit much and the above suggestions for me create to many steps.

                    • 7. Re: Syntax for module's named parameters - need your feedback
                      Robert Bell (Bosweb) Community Member

                      > How to specify if the module’s output is suppressed or not?

                      I would find syntax like template="none" or template="blank" more intuitive than the extraneous render parameter. Why would we pass a value to render when it only has one possible outcome? What is the behaviour when both render and template are specified?

                       

                      I'd have the template parameter accept any of these values to suppress output: [none|blank|empty|null]

                       

                       

                      > How to specify the variable in which a module data is captured?

                      I'd keep using 'collection', to match everyone else's Liquid naming conventions, and to make it explicit that the named item may contain multiple variables.

                       

                       

                      > How to specify how to render a module that renders a list of data?

                      Rather than referring to this as render, it may be more appropriate to refer to it as context - i.e., "this is the context that the template will be operating in".

                      Like so: {module_webapps id="stores" filter="all" context=”collection” template="/before-after/list.tpl”}

                       

                      I'd also suggest reserving collection rather than items, so the name of the object (intuitively) matches the name passed into the context parameter.

                       

                      {% for item in collection %}

                      <div>

                      <h1>{{item.name}}</h1>

                      <div>{{item.description}}</div>

                      </div>

                      {% endfor %}

                       

                       

                       

                       

                      Also, if we to use comments-as-directives, a strict syntax would be recommended. Perhaps something like <!-- @liquid-collection:enable -->.

                      • 8. Re: Syntax for module's named parameters - need your feedback
                        Scott B Reynolds CommunityMVP

                        If there is a var="whatever" do we need a render="nothing"? If a variable is being used the output could automatically be suppressed.

                        • 9. Re: Syntax for module's named parameters - need your feedback
                          Liam Dilley CommunityMVP

                          See ^ Makes it 3 times as confusing, not less

                          • 10. Re: Syntax for module's named parameters - need your feedback
                            Lucian Cozma Adobe Employee

                            I think we will keep:

                            {module_webapp .... template=""} to supress the template output (or maybe add support for a placeholder value like {module_webapp ... template="[none]"}.

                            {module_webapp .... collection="myLiquidVar"} to capture the data in the specified collection.


                            We will go also with {module_webapp ... render="item" template="item.tpl"} and {module_webapp ... render="collection" template="list.tpl} to differentiate if we would render wither a single item of the entire collection.


                            We think this is better than the comment inside the template and will simplify things a lot.


                            One note on why we we would need separate parameters for collection being captured and also for template is that sometimes we do need to both render with a custom template and also capture the rendered data so that you can use it in the page itself (I actually demoed this with module_cartsummary where I would render and also capture so that on the same page to render the related products).


                            Thank you all for the feedback

                            -Lucian

                            • 11. Re: Syntax for module's named parameters - need your feedback
                              Liam Dilley CommunityMVP

                              I think that is more confusing lol then it is now.

                               

                              I did not like that parameter comment, maybe it could have been template="something.tpl?supression-true" as at least that would follow conventions in other areas of the platform.

                               

                              collection="something" template="none" or just do not include template is my preferred, since the new module syntax point is that if you do not need to use it, do not include it. So ignoring it means you want a blank one.

                              And then as you mentioned Lucian having collection="something" template="something.tpl" if you want to send data both ways.

                              • 12. Re: Syntax for module's named parameters - need your feedback
                                Lucian Cozma Adobe Employee

                                I don't understand how that's more confusing than the way it is now.

                                 

                                The only difference would be that instead of using that comment in the template you would have a clear way to specify to the module how to handle the rendering: either as a collection so that you can loop through or as an item.

                                 

                                All of the other things remain unchanged: if template="" then the module output would be suppressed and collection="myVarName" would also create a variable that would contain that data.

                                 

                                Specifying the behavior of the module as a parameter instead of a comment in the module is clearer and more inline on how the system works now.

                                 

                                -Lucian

                                • 13. Re: Syntax for module's named parameters - need your feedback
                                  Liam Dilley CommunityMVP

                                  Oh, ok, I misunderstood based on what you was saying in the first post. I thought it was on top of.

                                  • 14. Re: Syntax for module's named parameters - need your feedback
                                    Scott Shefler Community Member

                                    1. I’m not so sure I like the idea of adding another parameter like render. Ideally I think everything should run through the template=”” or if template doesn't make sense than come up with another universal parameter for how data is outputted. However, I have outlined another option below what I think makes sense to me which would only be to use render to enable a collection in a template.

                                     

                                    // Rendering from Template

                                    {module_webapps id="stores" filter="all" template="/before-after/item.tpl"}

                                     

                                    // Rendering from Collection (why do we need template="" in there at all if were calling from a collection?)

                                    {module_webapps id="stores" filter="all" collection="BeforeAfter"}

                                     

                                    // Rendering from Collection in Template

                                    {module_webapps id="stores" filter="all" render="collection" template="/before-after/item.tpl"}

                                     

                                    // Rendering default list layout or backup. This way you can get rid of the useBackupTemplate and it's more clear to the developer what template is being used rather than remembering no syntax means it's using the list.

                                    {module_webapps id="stores" filter="all" template="default|backup"}

                                     

                                    2. I don't like the word "var" I didn't have a problem with using "param" or I would like something like "custom" to identify that this is a custom parameter being passed.

                                    • 15. Re: Syntax for module's named parameters - need your feedback
                                      Daryl Barnes Community Member

                                      How to specify if the module’s output is suppressed or not?

                                       

                                      Maybe that's the wrong question to ask.  If you think about what the user is really attempting to do and then reword it to ask "How do I output the module data to a variable?", then the answer becomes more clear.   Just use output="variable" or output="var".

                                       

                                      And when using it to specify a custom variable you could just specify it in that parameter using something like output="variable_myStores", output="variable:myStores", output="variable@myStores", or output="myStores.var". 

                                       

                                      And then to simplify things even further, instead of using template="/before-after/list.tpl" for outputting to a custom template, then instead use output="/before-after/list.tpl" to indicate the output is handled by the custom template.


                                      If you go this route, the options for the output parameter would then become:

                                       

                                      variable | yourcustomvariable.var | yourcustomtemplate.tpl

                                       

                                      Basically, you're no longer specifying a template, you are specifying how the output is being handled which can be by use of a variable, custom variable, or template.  And that would leave you using just one parameter to handle all cases so there is no confusion about using both.

                                       



                                      • 16. Re: Syntax for module's named parameters - need your feedback
                                        Liam Dilley CommunityMVP

                                        // Rendering from Collection (why do we need template="" in there at all if were calling from a collection?)

                                        {module_webapps id="stores" filter="all" collection="BeforeAfter"}

                                        ^This

                                         

                                        // Rendering from Template

                                        {module_webapps id="stores" filter="all" template="/before-after/item.tpl"}

                                        This

                                         

                                        And then collection = "" - You got to think about all the documentation already done, how it is behind by quite a lot already and this will throw that out further.

                                         

                                        The only thing to change is the  <!-- --> in the layout to supress the wrapping html.

                                         

                                        You guys just need to come up with a better solution for that and we are good to go.

                                         

                                        @Daryl - Sorry but that does not apply to any structure or concept in BC or liquid or coding, I am not a fan of that idea.

                                        People are making requests for to of a dramatic change when all that needs to change is the suppression aspect.

                                        • 17. Re: Syntax for module's named parameters - need your feedback
                                          Liam Dilley CommunityMVP

                                          The one thing I still see missing is pagination.

                                          There is an example for eCommerce but what about everywhere else?

                                          Is this is in? Is there documentation or examples guys?

                                           

                                          Take a web app module?

                                          Do you define paginate="mypagi" like a collection then able to do....?

                                           

                                          mypagi.size

                                          mypagi.pages

                                           

                                          etc

                                           

                                          ?

                                          • 18. Re: Syntax for module's named parameters - need your feedback
                                            Liam Dilley CommunityMVP

                                            One thing with collections is that, I am fine with it, but I am not sure if this will cause issues for others or if the other data is actually useful...

                                            If you have a web app module and you specify a collection for example collection="mything" what this returns is the whole web app object.

                                             

                                            The Idea of a collection is to get the web app items in this case for example. To do so would be mything.items and then you run a for loop on that.

                                             

                                            People may try ...... {% for webitem in mything -%} and it wont work because it needs to be  {% for webitem in mything.items -%}

                                             

                                            Again some better improvements to the documentation is needed mainly, but wondering if you do not actually need the rest of the object and mything.items is what is returned with the collection request?

                                            • 19. Re: Syntax for module's named parameters - need your feedback
                                              Daryl Barnes Community Member

                                              And then collection = "" - You got to think about all the documentation already done, how it is behind by quite a lot already and this will throw that out further.

                                              This is an absolutely terrible way of thinking when determining syntax for something like this.  It's how poor systems, frameworks, and APIs get implemented.  I would rather something be done right rather than because documentation has to be updated.  Seriously, the need to update documentation has to be one of the worst reasons not to implement a better solution. Just do it right and update the documentation.

                                               

                                              The only thing to change is the  <!-- --> in the layout to supress the wrapping html.

                                               

                                              You guys just need to come up with a better solution for that and we are good to go.

                                              I just reread Lucian's post and no they definitely mentioned several things they wanted feedback on.

                                               

                                               

                                              @Daryl - Sorry but that does not apply to any structure or concept in BC or liquid or coding, I am not a fan of that idea.

                                               

                                              Well that's just your opinion.  And everyone is allowed their opinions, no matter how wrong they may be.

                                               

                                              People are making requests for to of a dramatic change when all that needs to change is the suppression aspect.

                                              Again, you might need to reread Lucian's post.  He made the request for suggestions and thoughts on several items.  Not just the suppression aspect. I'm not sure why you are telling everyone not to do specifically what Lucian asked. 

                                              • 20. Re: Syntax for module's named parameters - need your feedback
                                                Lucian Cozma Adobe Employee

                                                Hey Daryl.

                                                 

                                                The option to mix variable assignment and specifying the template in the same parameter does not work how you propose.

                                                There are cases in which you both want to render a module using a template but also capture its data in a variable.

                                                 

                                                For example you could render the cart summary with a custom template but also capture the data rendered and then use the data to display a list of related products that is in the cart. For example write in a page-template something like:

                                                 

                                                {module_cartsummary template="/carttemplate.tpl" collection="cartInfo"}

                                                and then in the footer loop through the cart items and display the related products of the products in the cart:

                                                {% for item in cartInfo %}

                                                {module_relatedproducts id="item.productId" template="/relatedproducts.tpl"}

                                                {% endif %}

                                                 

                                                This is why we need to separate all these things:

                                                • Specifying the template that renders the module (or suppress the output by just putting in an empty template so that it would render nothing) template="mytemplate.tpl" or template=""
                                                • Specifying in which variable the data would be captured (if needed): collection="myVar"
                                                • Specifying the type of template you are using (one that renders a single item or a collection) render="item" or render="collection"

                                                -Lucian

                                                • 21. Re: Syntax for module's named parameters - need your feedback
                                                  Lucian Cozma Adobe Employee

                                                  I want to thank you all for your feedback. I think we have enough input to make a decision on this.

                                                   

                                                  -Lucian

                                                  • 22. Re: Syntax for module's named parameters - need your feedback
                                                    Daryl Barnes Community Member

                                                    Hi Lucian.  Point taken.  If you want to do both, you can't get rid of the template parameter.  However, I still would prefer to specify the name of the variable within the parameter with render="collection.myCustomVar", output="collection.myCustomVar", or something similar.   I understand why you would want a different parameter to assign the variable.  I just don't like the idea of using the render parameter with the only possible value in practical use being "collection".   Since render="item" is already the default, you would never really use that in practice.

                                                     

                                                    So having a parameter with only one option bothers me a bit but otherwise your revised model as described a couple of posts ago seems fine.  In any case, either solution in my opinion is far better than relying on HTML comments as an indicator so I would be happy either way.