We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
  • Hmmm... now if snippet authors put all their possible options in a certain format, surrounded by certain delimiters, then it would be possible to have a multiple select, or even better, check boxes with an input field next to it for the value, to automatically insert a snippet with the desired options, just as you can now insert links or images with options using the Resource Browser. Interesting thought.
      Studying MODX in the desert - http://sottwell.com
      Tips and Tricks from the MODX Forums and Slack Channels - http://modxcookbook.com
      Join the Slack Community - http://modx.org
      • 30223
      • 1,010 Posts
      Yes, I’ve been thinking along similar lines, but I think for that to work smoothly you’d have to have pretty strict formatting rules, and considering the shear number of options some snippets have I’m not sure I’d want to look into that too much until there’s re-thought about how snippets are stored and handled.

      There’s quite a bit of javascript processing involved because TinyMCE places the whole content in a DOM like XML structure. Nearly all the other plugins act on element in the DOM. MODx ’tags’ don’t fit in with that currently. I’d love to see <modx type="snippet" name="dropMenu" menuname="topNav" /> style tags or even <snippet ... /> or <dropMenu ... /> (the latter especially if the difference between snippets, TV vars and the like are being blurred in future versions) This is a little like the way XStandard works I believe. It would certainly give more scope for manipulating things from within editors.

      Anyway, just contempating the universe here... If you have any more concrete ideas let me know.
        • 4195
        • 398 Posts
        I was pointed to this topic bij doze, because I was thinking about a standard of defining what a snippet can do. One of the implementations would be the TineMCE plugin YOU just posted (funny how when you think of something someone beats you to it smiley ) So I really love your snippet/plugin.

        To complement your suggestion of the xml style tags for snippets.. maybe it’s an idea to pre-parse the content fed into the editor by replacing the [[ ]] style with the XML style to fit it in.. and before committing to the DB parse the content output of the editor back to [[ ]] style again.. that should solve your problem.

        about that universe tongue
        IF... modx tags would become xml compatible I suggest they look like this:

        <modx:snippet name="MySnippet" value1="This" value2="That" caching="True" />
        


        The tags would be recoqnizable as being modx by using it as a namespace and complementing it with the tag type. You can then use:
        <modx:chunk name="MyChunk" />
        for chunks etc..

        if a snippet gets values from another snippet you would get:

        <modx:snippet name="MySnippet" value1="This" caching="True">
            <modx:value name="value2">
               <modx:snippet name="MyOtherSnippet" value="This" caching="True" />
            </modx:value >
        </modx:snippet>
        


        ofcourse you have some more typing to do when using xml instead of modx tags but that will be solved by your handy plugin wink
          Armand Pondman
          MODx Coding Team
          :: Jot :: PHx
          • 30223
          • 1,010 Posts
          To complement your suggestion of the xml style tags for snippets.. maybe it’s an idea to pre-parse the content fed into the editor by replacing the [[ ]] style with the XML style to fit it in.. and before committing to the DB parse the content output of the editor back to [[ ]] style again.. that should solve your problem.

          That would possibly work. I’d have to test it to see how TinyMCE would deal with it. AS I said I’m not up to scratch with Tiny. For the time being I’ll concentrate on the path I’ve taken so far but I’ll keep this in the back of my mind for a next version.

          The tags would be recoqnizable as being modx by using it as a namespace and complementing it with the tag type.

          Yes, I like what you say... creating a modx namespace makes perfect sense. I’m not sure about your second example yet though. The aim of any CMS and a RTE is to remove the complexity of markup for the average user. You wouldn’t want to bring that complexity back in by reintroducing more similar markup. It would require good integration with the RTE but that could mean that you’d have to supply plugins/extensions to multiple RTE’s or loose some flexibility. Currently moving values between snippets happens on the snippet (or Chunck/TV) level and is less visible to the content editor. Don’t know what the answer is here really....
            • 4195
            • 398 Posts
            Quote from: TobyL at Aug 22, 2006, 01:52 AM

            Yes, I like what you say... creating a modx namespace makes perfect sense. I’m not sure about your second example yet though. The aim of any CMS and a RTE is to remove the complexity of markup for the average user. You wouldn’t want to bring that complexity back in by reintroducing more similar markup. It would require good integration with the RTE but that could mean that you’d have to supply plugins/extensions to multiple RTE’s or loose some flexibility. Currently moving values between snippets happens on the snippet (or Chunck/TV) level and is less visible to the content editor. Don’t know what the answer is here really....

            if you stick to the replace input/output editor solution there are no changes for the average user (complexity of markup will not be visible) and the second example is in fact one way of solving a nested tag situation as you can’t place xml inside an attribute value unless you would escape it.
              Armand Pondman
              MODx Coding Team
              :: Jot :: PHx
              • 30223
              • 1,010 Posts
              Quote from: bS at Aug 22, 2006, 09:03 AM

              if you stick to the replace input/output editor solution there are no changes for the average user (complexity of markup will not be visible) and the second example is in fact one way of solving a nested tag situation as you can’t place xml inside an attribute value unless you would escape it.

              I’ll take your word for it. It’ll be interesting to see what will happen in that respect in the upcoming MODx versions. You’ve got my vote for a more XML like approach but don’t forget the K.I.S.S. rule smiley

              In the mean time I’ve done some tweaking and cleaning up and I think it’s ready for some Q&A... I’ve updated the origional post so go and download it there. Enjoy and let me know how it goes.

                • 4018
                • 1,131 Posts
                Looking good, TobyL! I tried it out and it looks like it’s working pretty darn good so far! I think with a few tweaks I think you’ll be damn close to having something we can post as an official add-on to the TinyMCE plugin in the Repository. Only thing I spotted so far is a possible tweak to the javascript code. Whenever you insert in a snippet call without any parameters, a question mark is added regardless. I think you could tweak the code to where if there aren’t any parameters then a question mark won’t be added. Looking at the code, it looks like you could just check to see if paramText is empty or not. If it isn’t then simply change the value to add a question mark to the beginning:

                if(paramText != ""){
                	paramText = "?" + paramText;
                }
                


                Just an idea. Also, another nice little add-on would be to have a way to delete parameters from the snippet call. Granted, you could just manually remove a parameter from the text but might as well have a way to do it within the form as well. After all, there will be times when you accidentally misspell a parameter name and will need to delete it and add it back in. Why force the user to have to cancel and call the Insert MODx Snippet plugin again. smiley

                I think once all the little quirks and details are worked out, I’ll be glad to guide you on adding this to the Repository. smiley

                Jeff
                  Jeff Whitfield

                  "I like my coffee hot and strong, like I like my women, hot and strong... with a spoon in them."
                  • 30223
                  • 1,010 Posts
                  Thanks Jeff.

                  Good suggestions.

                  I’m actually in the process of redesigning the plugin form to use several tabs for parameters instead of the scrolling list it now has. This is more consistent with other tinyMce plugins and would allow for grouping of parameters, have the basic (required) parameters in the first tabe and group others in subsequent tabs.

                  However development has stalled for the moment as I don’t have a lot of time available. I will get back to it though.. I’m trying to come up with a system where the plugin can ’read’ not only what parameters are available but also what datatype and or values are acceptable (ie checkboxes, select boxes) so that it truly becomes easier for day to day editors to insert/edit snippets.

                  I’ll take your suggestions on board when I start working on this again.

                    • 6726
                    • 7,075 Posts
                    How did I miss this one (uh, yeah, was away on vacation...) ? (thanks Jeff for bringing this to my attention smiley )

                    Great plugin !
                      .: COO - Commerce Guys - Community Driven Innovation :.


                      MODx est l&#39;outil id
                      • 26074
                      • 121 Posts
                      Is this plugin good for modx 0.96 also?
                        ___________________________________________________________________
                        ..:: Samuele ::..