>
> That does look like it has the functionality, although I the
> macro-substitution perl-code-as-a-string model doesn't look fun to
> parse.
This is the way Embperl compiler currently takes it syntax definitions. Also
it not always looks very nice, it's optimized so that most of the action is
made at compile time. For example when you have eplsub="foo" in your source,
Embperl will insert the constant 'foo' in the resulting perl code, this way
no parsing or string operation, hash lookups etc. has to be done at runtime.
> I'd be happier if were more general. I did a subclass of
> HTML::Parser for a project where the API for a tag:
> sub start {
> my ($this, $pretext, $tagname, $attr, $attrseq, $tagtext) = @_;
> In this case $pretext isn't really reasonable, and the body text of
> the tag is more useful. But one nice thing about this model is that
> you don't have to make special calls to change things...just change
> $attr and $attrseq
> (and if you want, require that the return value of
> the routine indicate whether anything was changed).
Of course this is nicer for the programmer, but ways slower. While this
doesn't matter if you have a few of those tags inside your page, it would
matter if everything is handled this way.
>
> But I'm not going to ask you to change your internal API just for
> this. It's just that this makes debugging a bit painful because of
> the run-time compile, and the macro expansion.
Yes
> Of course I could
> probably get the API I like by doing this:
>
> perlcodeend => q{
> {
> my $sub = get-my-subroutine-from-under-a-rock;
> &$sub(%$txt%, other-info)
> }},
>
Yes, I think this is the way to go
> So, back on track. It seems to me that the way to do this would be
> to write a wrapper routine for more general use. You call it with
> the tag you are interested in, and a subroutine to be called for that
> tag. You manipulate the data (passed by reference) and return
> whether the value changed. The core routine looks at the data, and
> makes the appropriate calls to make the changes.
>
This really seems a good idea
> This ought to work in Embperl::Object (the parent could set up the
> parser, and the children could override the routines that get
> called). That seems doable.
Yes
>
> What happens when there's a conflict (e.g. I subclass from
> Embperl::Syntax::HTML and go for the "a" tag, and then someone
> subclasses me and does the same)? I *think* they ought to both be
> called, from the subclass on up, but I'm not positive, and I don't
> know what would have to happen to make that occur.
>
The Embperl compiler should make this for you, but I have not very well
tested this yet, because it wasn't necessary so far. Anyway this Embperl
handles this, it shouldn't be hard to get this working.
> Logically speaking, what we are discussing here is rather like adding
> style-sheets to Embperl.
Yes, you can call it a kind of style-sheets
Gerald
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
