We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
MODX Community Forums Archive

Event Model and Parser Overhaul

    • 25663 MODX Staff
    • 12,272 Posts
    Ryan Thrash Reply #11, 20 years, 10 months ago
    And copying Raymonds post here too:

    I’m thinking that we could a custom syntax analyser that’s capable of looking through the code and executing each [[ ]] at a time.

    I’m thinking we could use strpos, substr and str_replace

    example pseduocode:
    function name: mergeTag(&$html, $startpos=0)

startTag = position of [[
if startTag>=0 then let endTag = position of ]] from startTag+2
nextStartTag = position of [[ from startTag+2

if nextStartTag < endTag then 
   mergeTag($html,startTag+2)
   endTag = position of ]] from startTag+2
end if
if endTag>startTag then let tag = substr(startTag,endTag-startTag+2)
$html = str_replace(tag,processTag(tag),$html)


    I’m not sure how fast this function would work but I think it will be able to process the tags in a the order they appear in the page.

    for example:
    [[A? 
    &p1=`[[B? &p1=`[[C]]` ]]` 
]]

    The execution order would be C, B then A

    What what you you think? Anyone want to give it a try?
      Ryan Thrash, MODX Co-Founder
      Follow me on Twitter at @rthrash or catch my occasional unofficial thoughts at thrash.me
      • 1764
      • 680 Posts
      aNoble Reply #12, 20 years, 10 months ago
      I love the idea of the [[@Event]] and [[%lang]] tags.

      What would be really cool for the language tags and fairly easy to implement would be to have a translate link show up next to any text that had not been defined in that translation yet so that you could do the translation right there.

      Okay, now that’s cool and not too hard. Now comes the crazy stuff that falls under the "I can dream, can’t I?" category.

      What if we were to have a sort of a translation wiki? Editing a translation would actually submit back to a tranlation "wiki" where everyhing could be stored in a central server and downloaded and cached in some sort of an xml format or something and then rendered into the UI. We could have the choice of using "official" translations, or pure up-to-date wiki style translations that were completely subject to whatever edits anybody would make. The same thing would apply to help links, and we could actually go a bit beyond a strict translation here. I’ve never seen anybody do someting like this and it could be very revolutionary and could easily give us more translations than any other CMS (or maybe I just need more sleep tongue )
        Adam Crownoble: obleDesign.com | [email protected] | [email protected] (Google Talk)
        • 31337
        • 258 Posts
        vbrilon Reply #13, 20 years, 10 months ago
        I am definitely good with the parser the way Raymond describes. It should work from the inside out, expand each statement and then eval the final result.

        2 caveats:
        1) You need to make sure you control how deeply you can recurse, otherwise you might inadvertantly bring the server down with bad code
        2) You need to make sure that you keep an list of already expanded statements so that self-referencing looping code can be caught and stopped.
          I have been touched by His noodly appendage
          • 25663 MODX Staff
          • 12,272 Posts
          Ryan Thrash Reply #14, 20 years, 10 months ago
          now that’s just a crazy enough idea to be cool!
            Ryan Thrash, MODX Co-Founder
            Follow me on Twitter at @rthrash or catch my occasional unofficial thoughts at thrash.me
            • 32963
            • 1,732 Posts
            xwisdom Reply #15, 20 years, 10 months ago
            Hi,

            Here’s the Pseudo Code that can process nested [[]]

            It’s a sample parser. Please stress test and see if yout can find ways to improve.

              xWisdom
              www.xwisdomhtml.com
              The fear of the Lord is the beginning of wisdom:
              MODx Co-Founder - Create and do more with less.
              • 25663 MODX Staff
              • 12,272 Posts
              Ryan Thrash Reply #16, 20 years, 10 months ago
              Well looks like some very respectable enhancements were made based off your work Raymond... great stuff and thanks!

              Remon, likewise thanks for demonstrating just how well it would work and making it better!

              A round of applause to you both. laugh
                Ryan Thrash, MODX Co-Founder
                Follow me on Twitter at @rthrash or catch my occasional unofficial thoughts at thrash.me
                • 25663 MODX Staff
                • 12,272 Posts
                Ryan Thrash Reply #17, 20 years, 10 months ago
                For our next step, I think we sould simultaneously tackle plugins and API cleanups. This is where Victors even model whitepaper might come in handy. Adam and Jason both have some ideas about API additions if I recall correctly. Jeff too... I really like the idea of storing a page’s genealogy in the db, too.

                Simultaneously, we could start the user systems merger/federation/etc. Jason is up for working on the user systems, which makes sense to me since he has experience with the mutli-project "abstracted peristent federation" (I need a better marketing-speak for this so normal humans can understand it...). lol

                  Ryan Thrash, MODX Co-Founder
                  Follow me on Twitter at @rthrash or catch my occasional unofficial thoughts at thrash.me
                  • 32963
                  • 1,732 Posts
                  xwisdom Reply #18, 20 years, 10 months ago
                  Hi All,

                  I’m working on the Parser at the moment. I’m trying to merge Remon’s fixes with the current parser.

                  The new Parser will allow a developer to perform very complex things. Consider the following:

                  [[*[[*Custom]]]]

                  [[*ContentField|color=[[+value]]]]

                  [[*[[+Custom]]]]

                  [[+[[Widget]]]]

                  [[Widget?
                  value=`[[+[[Options]]]]`
                  ]]

                  Remon,

                  Can you say why you’ve used str_replace instead of substr_replace? I’ve notices this from the merge* functions. Also did you manage to get any more speed out of the Parser based on how it’s merged in document.parser.class.inc.php? I notices some nesting issues.


                    xWisdom
                    www.xwisdomhtml.com
                    The fear of the Lord is the beginning of wisdom:
                    MODx Co-Founder - Create and do more with less.
                    • 24253
                    • 125 Posts
                    R.S. Reply #19, 20 years, 10 months ago
                    Hello Raymond,

                    I’m not sure which version you’re using, I posted last week the :
                    http://modxcms.com/forums/index.php/topic,1438.0.html

                    If you like to talk via MSN, IM, please send me a message smiley

                    Ehm, I wonder, did ....(I forgot who, sorry) not allready merge my stuff into svn?

                    From you example above, it looks like you enable recursion for any kind of call, not only a snippet call. I guess, this could be done by checking for nesting in processTags instead of mergSnippetContent....
                    Have a look at the above post, you’ll find the tagparser.php class in the extenders dir. Makes working on the parser a little easier ;-)

                    About using the str_replace vs substr_replace, I’ve no idea smiley
                    My best bet would be, that I used the original code hehe


                    Remon
                      • 32963
                      • 1,732 Posts
                      xwisdom Reply #20, 20 years, 10 months ago
                      Hi Remon,

                      I’ll have a look to make sure that all is working now.

                      I don’t think we should separate the parser from the ContentManager class as the parser is needed 90% of the time. Having it integrated will be much faster than having to include it.

                      I’ll branch to a new Post entitled "The Content Manager Object" a.k.a. "Recursive Parser Part 2"
                        xWisdom
                        www.xwisdomhtml.com
                        The fear of the Lord is the beginning of wisdom:
                        MODx Co-Founder - Create and do more with less.