in reply to Re: hrm, Eval::Compile
in thread hrm, Eval::Compile

Ok, so I've gone away and had a think about that and I think I can see a way of organising it so that the plugins can remain the same, however there is still another problem.

lets say you have a situation like this:


  (foo)
    <bar><x/></bar>
  (/foo)

[download]

Where for instance foo does a database lookup and for each row of the database returns <bar> with the x value filled in. Now we have a certain number of <bar> directives to compute, the number of which is unknown until foo has been computed.

Each time the program runs there could be a different number of rows retrieved from the database, so unless we compile each time, negating the point of the excercise, there is no way to know how many instances of the compiled <bar> directive to include in the precompiled file.

Replies are listed 'Best First'.
Re^3: hrm, Eval::Compile
by Anonymous Monk on Jul 20, 2011 at 06:50 UTC

    Each time the program runs there could be a different number of rows retrieved from the database, so unless we compile each time, negating the point of the excercise, there is no way to know how many instances of the compiled <bar> directive to include in the precompiled file.

    What? That is a simple foreach loop, as already demonstrated in Re: H.O.P && aXML, Re^4: RFC : Abstraction Markup, Re^7: H.O.P && aXML, Re^7: H.O.P && aXML

[reply]
      I disagree, however I cannot currently figure out how to describe exactly why. I will think about it more and see if I can come up with a concrete example of the problem, or figure out why I am mistaken.
[reply]

        Ok... here is an example, I haven't used this technique for a while but it has been useful before.

        
  <refas tag="foo">/path/to/bar.xml</refas>

        [download]

        Where bar is an xml file containing some values, and refas creates a new plugin on the fly called foo, which substitutes any foo tags it finds in the document with the values they specify, adds it to the command list and restarts the parser.

        Once that command is triggered, anywhere in the document that the tag <foo>x</foo> or <foo>y</foo> exists get substituted for the values contained in foo : <y>somevalue</y>, <x>somevalue</x>.

        The <SQL tag supports a refas mode which uses the columns of the database for the key.

        Another example is that it is possible to build tags on the fly for example :

        
  <<qd>gettype</qd>>
    somedata
  </<qd>gettype</qd>>

        [download]

        Where gettype can be either html or xml, giving either:

          <html>
    somedata
  </html>
 
  or

  <xml>
    somedata
  </xml>

        [download]

        If you can't determine ahead of time what a given tag actually means because it's meaning might be changed at runtime by another tag which branches on the request data, how can you compile it?

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom