Loading ...
Sorry, an error occurred while loading the content.

Re: Yet more code (Was: Re: A nifty code sample to share)

Expand Messages
  • Josh Chamas
    ... Right. I would never take away the current style/method of XMLSubs, just add to it like you suggest. ... So then the parent XMLSubs output would be then
    Message 1 of 16 , Sep 21, 2002
    • 0 Attachment
      Brat Wizard wrote:
      >
      > Josh- why not make it a simple directive, like a pragma-- then it could be
      > specified inline by the end-user whenever (and if-ever) they need it one way
      > or the other.
      >
      > Perhaps something like:
      >
      > $Apache::ASP::XMLSubsPostProc = 1
      >

      Right. I would never take away the current style/method of XMLSubs,
      just add to it like you suggest.

      > <my:sub>
      > <my:nestedsub><%=$blech%> __TOKEN1__</my:nestedsub>
      > <%=$foobar%> __TOKEN2__
      > </my:sub>
      >
      > You could wait until after the first my:sub had been called to interpret the
      > rest-- just process everything post. In my thinking __TOKEN1__ and __TOKEN2__
      > would get resolved by the renderer function on the first pass and
      > <my:nestedsub>, $blech, and $foobar, would get processed immediately
      > afterwards-- after the tokens had been substituted.
      >
      > How would that work out do you think?
      >

      So then the parent XMLSubs output would be then evaluated
      at runtime as ASP script automatically by the system. That
      is an interesting way of looking at doing the pre-processing.

      The only problem with this model is that runtime parsing/eval
      of the code would be expensive. The other preprocessing model
      that I was considering would not do ANY inner code substitution
      on its own, leaving this to the XMLSubs definition to do if
      it wanted to.

      I am not sure which one I would lean to more, but they are both
      interesting models.

      >>my $pgimage = My::PgImage->new(
      >> ASP => $asp,
      >> Attrib => { pg=>"__PG__" sku=>"__SKU__" },
      >> Parent => $pgloop
      >>};
      >>$pgimage->execute(\'');
      >>$pgloop->execute(\$final_data_output_within);
      >
      >
      >
      >>This pre/post processing model would allow pgimage to
      >>work with $self->{Parent}{sth}, or pgloop could populate
      >>its own data in this way. Output from pgimage could be
      >>trapped and inlined, passed into the execute() function
      >>for pgloop.
      >
      >
      > Hmm- sounds a little complicated. Not to mention you are exposing a lot of the
      > $asp guts to the programmer/user that way and the goal should be the exact
      > opposite-- to abstract that away from the programmer and toward the
      > web-monkey/end-user...?
      >
      >

      This was just an example of how the preprocessing model would
      get executed. This would be more for the XMLSubs definer to
      worry about. I ideally to the end user, things would just work.
      I believe that XMLSubs will have to grow in complexity to be
      able to do really doo things that other platform taglib functionality
      offers. I will be looking hard as JSP & AxKit before I do any
      next generation XMLSubs for sure.

      >
      > Actually I was thinking something very similar but for another reason-- if you
      > use delayed processing, like I describe above, conditionals actually get
      > pretty easy I think. You just build them into the my:sub "$body" text and let
      > the post-processing pick them up.
      >

      I see the power of the preprocessing + execute output during post
      processing model. The speed issue is the only one I have to get
      over here. I'll look at some taglib libraries that I would like
      to implement in Apache::ASP & see what kind of power we need here.
      It may be that some things are only possible with the kind of
      power that you suggest, and its a very interesting idea giving
      the XMLSubs programmer the ability to rewrite the code on the fly.

      > All you need to do is make the one adjustment to handle <% %> subs post
      > instead of pre and I think the render function can handle the inbetween
      > stuff. The __TOKEN__ format is very comfortable and intuitive to me in this
      > instance. It seems very obvious that they are serving as placeholders for
      > yet-to-be-in-scope data. And by delaying the <% %> processing, you allow
      > substitution to occur _before_ conditional blocks take place.
      >
      >
      > What is your take on all this?
      >
      > I think we've just descibed a very functional, useable processing paradigm
      > that fits with the current "feel" of the asp system, and with the single
      > exception of moving <% %> substitution to post-processing, you don't have to
      > make any other radical changes to the Apache::ASP framework or api (at least
      > I don't think you do).
      >
      > Your thoughts?
      >

      Pretty good stuff. I'll definately be following up on this later
      when I go to implement, so stay tuned.

      Regards,

      Josh
      ________________________________________________________________
      Josh Chamas, Founder phone:925-552-0128
      Chamas Enterprises Inc. http://www.chamas.com
      NodeWorks Link Checking http://www.nodeworks.com


      ---------------------------------------------------------------------
      To unsubscribe, e-mail: asp-unsubscribe@...
      For additional commands, e-mail: asp-help@...
    • Brat Wizard
      Of course, you could also put just the info to be included into a separate file and allow it to be included at a judicious moment... (nah, that would be too
      Message 2 of 16 , Sep 22, 2002
      • 0 Attachment
        Of course, you could also put just the info to be included into a separate
        file and allow it to be included at a judicious moment... (nah, that would be
        too easy ;)

        But the one thing that _doesn't_ allow for, and the reason why I myself have
        been working on the problem-- is putting together something you can let the
        end-user (the buyer of the account) create/customize/or otherwise abuse w/o
        worrying about compromising the sanctity of the system in the process. They
        can only supply tokens to be substituted and simple formatting directives,
        and not actualy code (although the ()?: structure I presented does allow
        actual code to be executed, something I would have to deal with somehow).



        > I see the power of the preprocessing + execute output during post
        > processing model. The speed issue is the only one I have to get
        > over here.

        --

        --------------------------------------------------------------------------------
        Check out http://www.Wizard.Org for great deals on Electronic Parts
        *NEW* Computer Parts & Accessories - Drives - LCD - Systems - Linux
        --------------------------------------------------------------------------------
        ** Affordable Online Store w/Merchant Card Processing & Paypal **
        Write to us: sales@... -- Get your Store Online Today!
        --------------------------------------------------------------------------------



        ---------------------------------------------------------------------
        To unsubscribe, e-mail: asp-unsubscribe@...
        For additional commands, e-mail: asp-help@...
      Your message has been successfully submitted and would be delivered to recipients shortly.