RE: XMLSubsMatch Questions.. (urgent!)

[John Drago]

Using the Script_OnStart handler in your Global.asa should be able to handle that, but I'm not sure if that could create a race condition.   That would require some testing.   If you're doing it in a hosted environment with multiple applications running on the same instance of Apache, and therefore need things to change on a per-request basis, I suppose you could store your tag registry somewhere on a per-domain basis.  This could insulate you against race conditions.   Regards, John Drago     From: Ryan Dietrich [mailto:[EMAIL PROTECTED] Sent: Friday, July 30, 2004 10:22 AM To: 'John Drago'; [EMAIL PROTECTED] Subject: RE: XMLSubsMatch Questions.. (urgent!) Yeah, I’ll start looking there.  I think my biggest hot button is registering the tags to scan for on a per request basis. Simply, if I only register the query module, the only tags that Apache::ASP will scan for are the query tags, and asp:use and asp:include (as they are defaults..)   I have a feeling I’ll be ripping up some code this weekend J …   Cheers,   -Ryan Dietrich   From: John Drago [mailto:[EMAIL PROTECTED] Sent: Friday, July 30, 2004 12:12 PM To: 'Ryan Dietrich'; [EMAIL PROTECTED] Subject: RE: XMLSubsMatch Questions.. (urgent!)   That would work too.   That would be the next logical evolution for XMLSubsMatch, to at least allow it to search for several types of tags   I suppose you could override sub Apache::ASP::ParseXMLSubs, wrapping the while(1){...} loop inside a foreach(){...} loop, iterating through each element in $self->{xml_subs_match}, which would have to become an array instead of a scalar.   You may also need to take a good look at sub Apache::ASP::config, which is where $self->{xml_subs_match} gets its value.   There's problably a better way to do it that I'm not seeing too.   Regards, John Drago       From: Ryan Dietrich [mailto:[EMAIL PROTECTED] Sent: Friday, July 30, 2004 9:56 AM To: 'John Drago'; [EMAIL PROTECTED] Subject: RE: XMLSubsMatch Questions.. (urgent!) I think we can safely extend the current XMLSubsMatch module without making too much of a mess…   In global.asa we would define..   PerlSetVar  XMLSubsMatch asp:(use|include)   This would register two tags into our current namespace, asp:use and asp:include.. We would define them in a package in global.asa…   The “use” call would call a pre-defined function in the request, to register tags for scanning in execution.   The register call within the “use”d module would look something like this..   sub register {   my $asp = shift;   $asp->register(‘query:tag’, \&query); }   sub query { … }   In the end, this could really rock!!    -Ryan Dietrich   From: John Drago [mailto:[EMAIL PROTECTED] Sent: Friday, July 30, 2004 10:32 AM To: 'Ryan Dietrich'; [EMAIL PROTECTED] Subject: RE: XMLSubsMatch Questions.. (urgent!)   Hello Ryan,   I would be interested in working with you to add this functionality.   My team is implementing a TagLib extension for Apache::ASP, so at the top of your ASP script (or perhaps in Script_OnStart) you can import tag->namespace references. For instance, at the top of your script, you would have something like so: <%@ TagLib Prefix="application" Package="MyApp::Application" %> <%@ TagLib Prefix="query" Package="MyApp::Query" %> ... <query:someTag someArg="someVal" />   Then, in MyApp/Query.pm, you would have the following:   package MyApp::Query; ... package MyApp::Query::someTag;   sub Render {     my ($s,$args,$html) = @_;     .     return "some html here"; }# end Render()   Because we may have a need for recursive parsing, the output to a tag's Render() method will also be parsed. So your Render() method could return something like: "<query:anotherTag />" or whatever.  We may need to work on the exact syntax there, because MyApp::Query::XXX wouldn't be aware of its imported Tag Prefix (i.e. "query").  Perhaps "__PREFIX__" would be good enough.   For discussion on this topic, take a look at the thread ".NET-style components and development" from a few months back: http://www.mail-archive.com/asp%40perl.apache.org/msg01980.html   Regards, John Drago       From: Ryan Dietrich [mailto:[EMAIL PROTECTED] Sent: Thursday, July 29, 2004 10:54 PM To: [EMAIL PROTECTED] Subject: XMLSubsMatch Questions.. (urgent!) Hello all, I’m making that “templating toolkit” decision right now.  Need to move QUICKLY. J   My #1 goal is to totally separate my html and code from each other.  XMLSubs is the style of the technical solution that I want to use.   However, I’ll be registering many, many, many tags.. This causes a few problems the way they are implemented currently..  Please help!   1. Defining all these function calls in global.asa will get very messy quickly. (and will be painful to maintain), can you do the following?  (I could do a “use Class qw(list of function names)” but that would get messy as well..   PerlSetVar  XMLSubsMatch user:\w+  Class::MyTagHandler   2. I’ll need to have multiple top level domains.  I tried to set do the following, but it seemed to overwrite the first one..   PerlSetVar  XMLSubsMatch application:\w+ PerlSetVar  XMLSubsMatch query:\w+   It appears that there can only be one XMLSub at a time?   3. Once I have registered all these names, I don’t want to selectively include which tags to scan in.  (based on the modules that they are in)..  Something like this would be nice..   <asp:use class=”Class::MyTagHandler”/>   This would add JUST the tags that were defined in that class to the “scan list”..  (of course, I could have multiple “use” classes as well)..   If this is all beyond Apache::ASP, let me know, I miss doing mod_perl, despise cold fusion, and don’t want to migrate to Java, so any help you guys can give me I would totally appreciate!   -Ryan Dietrich