Nesting of forms – any limits or pitfalls?

masa · 2008-02-21 09:34:03

Hi everyone,

the nesting of forms is something, I haven’t been able to find much information on.
Basically it seems possible, but are there any potential downsides like limits to the number of levels or an impact on performance?

At the moment I’m thinking of nesting only one form inside another, but they both would require conditional tags.

Any hints would be very much appreciated. :-)

Martin

Last edited by masa (2008-02-21 09:35:45)

redbot · 2008-02-21 10:04:08

I often nest forms with conditional tags and this has always worked for me with no problems and no perceivable slowdowns.
And with this technique you can even nest a conditional into the same conditional (which is not possible in a single form without using php directly).
Note though I’m not talking from a technical point of view so I don’t know if it is causing a too intensive work for the server but – as I said – there is apparently no problem at all

Last edited by redbot (2008-02-21 10:31:32)

masa · 2008-02-21 10:21:55

redbot wrote:

I often nest forms with conditional tags and this has always worked for me with no problems and no perceivable slowdowns.
And with this technique you can even nest a conditional into the same conditional (which is not possible in a single form without using php directly).

Great tip! I was just banging my head against that wall as we speak.
That should be added to the documentation.

Thanks very much!

ruud · 2008-02-21 12:08:34

There’s no real limit in using forms.

The nesting problem should really be solved by a new parser. I’ve been working on that for the past days. Writing a parser that is both backwards-compatible, which can handle nested tags properly and isn’t several times slower than the current parser… that’s a challenge. The parser in crockery was up to 5 times slower (for nested tags only). I think I’ve reduced that to 3x now, but perhaps there’s room for improvement. For sequential tags (not nested), the differences are not as big (crockery parser is, IIRC, around 2x slower than the 4.0.6 parser).

redbot · 2008-02-21 12:37:02

ruud wrote:

The nesting problem should really be solved by a new parser. I’ve been working on that for the past days.

Great news ruud,
I have two questions:
1) are you planning to include the new parser in the 4.0 branch or 4.1 (crockery)?
2) just for curiosity, how does the new parser compares – in terms of speed – with the nested forms technique described before?

ruud · 2008-02-21 17:26:32

I hope it can be included in 4.0.x series, because the nesting problem, although we can claim it’s just a limitation of the current parser, is really an annoying bug.

To give an idea of the time needed to parse/load a form, I’ll give some examples. Bear in mind, I’m developing on ancient hardware (which is good in a way, because it shows more clearly which parts are slower), so on modern hardware, this should be at least 10x faster.

Loading a form, according to the tag trace, takes about 1ms on my system.

Let’s take this code (5 nested tags), for example:

<txp:tag1>
  <txp:tag2>
    <txp:tag3>
      <txp:tag4>
        <txp:tag5>
          content
        </txp:tag5>
      </txp:tag4>
    </txp:tag3>
  </txp:tag2>
</txp:tag1>

For testing, I parse that 1000 times to get a somewhat stable measurement and am currently getting these results (average per parse):

4.0.6: 2.2ms
crockery: 9.4ms
my parser: 5.5ms (note that while I’ve spent some time optimizing, there’s still a bit room for improvement here, though not much).

If I take 10 self-closing tags in a row and parse that, I get these results:

4.0.6: 2.4ms
crockery: 3.9ms
my parser: 3.2ms

As you can see, the performance difference is much higher for nested tags. That’s because the 4.0.6 parser just looks for the next possible matching closing tag, not taking into account tag nesting. The two other parsers actually build a tag tree to find out where the closing tag is. That takes time.

Suppose in the first example, tag2 is a conditional tag (not necessary, but I believe that’s a common case where forms are used to increase speed). You could do:

<txp:tag1><txp:tag2><txp:output_form /></txp:tag2></txp:tag1>

and put this in the form:

<txp:tag3><txp:tag4><txp:tag5>content</txp:tag5></txp:tag4></txp:tag3>

Both get parsed. First one (two container tags):

4.0.6: 1.2ms
crockery: 3.3ms
my parser: 2.3ms

Second one (included form):

4.0.6: 1.3ms
crockery: 4.3ms
my parser: 2.7ms

Adding 1ms for loading the form, that gives these results when the tag2 conditional is true (so the form is included):

4.0.6: 3.5ms (1.2ms + 1.3ms + 1ms)
crockery: 8.6ms
my parser: 6.0ms

Perhaps contrary to what one would expect, for the old parser, using a form to include content (if that content has to be parsed anyway) is slightly slower (3.5ms vs 2.2ms), but minor compared to the 280ms it takes (runtime from tag trace) to load the default frontpage in a TXP 4.0.6 install on my server.

HOWEVER… if the conditional does not trigger (= form not loaded), the setup that uses a form is 1ms faster. Of course, the more code (amount of TXP tags) you put in the form, the bigger the performance difference will be, if you do this for code that is inside a conditional that rarely triggers.

For the other two parsers (crockery and my own), using a form is faster in most cases, no matter if the conditional tag2 triggers or not, which is easy to explain. When you have to parse 5 nested tags, to find the closing tag for tag1, you have to wade through all the tags in between (4 nested tags), then moving on to the second level you have to wade through 3 remaining nested tags to find the closing tag for tag2, because for each nesting level, the parser starts again at the start tag of that particular nesting level. So if you are nesting many many layers deep, the most deeply nested tags are seen (and skipped) many times (which takes time) before they are actually executed. Using a form hides those tags from view until you get much closer (in terms of nesting depth) to them.

In most cases though, I suspect the difference is speed is so little that the decision on whether to use a form or not is based on ease of maintenance instead of speed.

Although a proper parser is slower than the one currently in TXP 4.0.6, there have been improvements some other parser related functions recently (after the 4.0.6 release), which make if/else constructs at least twice as fast (and often much much faster), so when combined with such a new parser, I’d expect the speed to be about the same, depending on how you use TXP tags in your templates.

redbot · 2008-02-21 18:32:28

Wow ruud, that’s what I call an exhaustive answer…
Just a last question and I promise I’ll stop bothering: will your parser take care of the existing problem with nesting the same conditional in the same form (now you have to insert the second conditional in another form to make it work)?
for example

<txp:if_section name="a">
<txp:if_section name="b">
do something
</txp:if_section>
</txp:if_section>

P.S. thanks for all your great work!

ruud · 2008-02-21 18:40:10

Yes, that’s exactly the nesting problem I was talking about (non-identical nested tags can be parsed just fine in TXP 4.0.6). I just named the tags in the example tag1 – tag5 to indicate the nesting level. Having them all named <txp:tag> would still work.

masa · 2008-02-21 18:49:08

Ruud, that is terrific – I’ll be looking forward to it!
And yes, thanks for your excellent work! :-)

redbot · 2008-02-21 19:45:04

ruud wrote:

Yes, that’s exactly the nesting problem I was talking about (non-identical nested tags can be parsed just fine in TXP 4.0.6).

Thank you for clarifying ruud, I just wanted to be sure I wasn’t misunderstanding …that’s exactly what I was hoping for!!

Textpattern CMS

Textpattern CMS support forum

#1 2008-02-21 09:34:03

Nesting of forms – any limits or pitfalls?

#2 2008-02-21 10:04:08

Re: Nesting of forms – any limits or pitfalls?

#3 2008-02-21 10:21:55

Re: Nesting of forms – any limits or pitfalls?

#4 2008-02-21 12:08:34

Re: Nesting of forms – any limits or pitfalls?

#5 2008-02-21 12:37:02

Re: Nesting of forms – any limits or pitfalls?

#6 2008-02-21 17:26:32

Re: Nesting of forms – any limits or pitfalls?

#7 2008-02-21 18:32:28

Re: Nesting of forms – any limits or pitfalls?

#8 2008-02-21 18:40:10

Re: Nesting of forms – any limits or pitfalls?

#9 2008-02-21 18:49:08

Re: Nesting of forms – any limits or pitfalls?

#10 2008-02-21 19:45:04

Re: Nesting of forms – any limits or pitfalls?

Board footer