On Thu, 13 Jan 2000, Joshua Chamas wrote:
> Hey,
>
> A possible XML extension for Apache::ASP came up when
> Paul Linder created an internal mapping for <msg>$string</msg>
> to translate to Locale::PGetText::gettext($string), for
> internationalization, and only for his version of the module.
>
> I think that it would be good to extend this mechanism
> in general, such that any <tag></tag>, or just <tag args>
> could be mapped to a subroutine, thus implementing
> generic XML extentions for the module.
>
> Here's my try at this... a generic XML tag set seems to
> look like <tag %args>[$string</tag>] where the part in
> brackets is optional ... maybe if XMLSubs is set to
> some tag names, these tags would then have their namesake
> function called.
First off, it's <tag %args>[$string]</tag> or <tag %args/> - the syntax is
extremely strict and I'll come down on you like a ton of bricks if you
don't stick to it :)
A valid regexp for ascii and Latin-1 only XML parsing is:
while ($contents =~ /([^<]*)<(\/)?([^>]+)>/) {
But then you have to do a bit more to determine whether you've gotten a PI,
DOCTYPE, CDATA or ELEMENT - but you can probably ignore that!
>
> So Paul would set XMLSubs to msg, then define the msg()
> function in global.asa which would then be called. $string
> would get set to $_, and args would be passed in as %args,
> so internally this would happen:
>
> $_ = $string; &msg(%args);
>
> I thought about passing %args in as a hash ref &msg({%args}),
> but think that this might slow things down for the common
> use, with less %args, with the overhead of creating the
> hash ref, also the @_ for sub msg{} would be easier to
> work with as just my %args = @_;
>
> So then for Paul, he would have defined in his global.asa
>
> sub msg { Locale::PGetText::gettext($_) }
>
> for his <msg>$string</msg> XMLSubs mapping. The return
> output would be inserted into the final HTML.
>
> What about embeded XML tags you ask? Good question. Its
> really an implementation nightmare for me to solve, but
> I would have to keep breaking up $_ into smaller parts,
> resolving the deepest tag first, allowing tags to operate
> on the output of embedded tags, like
>
> <msg>
> <msg2>$string</msg2>
> </msg>
>
> where the output from &msg2 would be set to $_ for &msg.
>
> Matt, I have also CC'd you here, since you are the
> XML pro in these parts.
>
> Any suggestions or feedback ? Thanks.
Well, overall I think it's a bad idea. Sorry. I've just had (like 10
minutes ago) this discussion on Perl-XML. I think that you shouldn't be
extending a perfectly good system with this cruft - not only do you have to
parse <% %> (easy) but now have to look out for all sorts of special tags?
My personal preference would perhaps be a separate module that processed an
XML based CFML type page - in that system you could implement this - go for
your life, but I don't think it works particularly well as part of the
design of ASP.
Hope I haven't put you off.
Also, I don't see the benefit between what you've proposed and:
<%= msg($string) %>
That seems far more logical to me.
Keep the declarative stuff in declaritive languages and keep ASP procedural.
If someone wants to see an interesting XML based little language written in
about 200 lines of code give me a shout.
--
<Matt/>
Details: FastNet Software Ltd - XML, Perl, Databases.
Tagline: High Performance Web Solutions
Web Sites: http://come.to/fastnet http://sergeant.org
Available for Consultancy, Contracts and Training.
