At 1:36 PM +0100 3/13/02, Gerald Richter wrote:
>You can define a syntax module that is derived from Embperl::Syntax::HTML,
>this would could contain something like
>
>
>sub new
>
> {
> my $class = shift ;
>
> my $self = Embperl::Syntax::HTML::new ($class) ;
This reminds me of something else I'd been meaning to ask. Have you
considered some type of meta-directive that could be placed at the
top of a file and would specify the recipe with which it should be
processed? Currently the caller decides this, but this would allow
you to make the decision on a per-file basis.
>sub Init
>
> {
> my ($self) = @_ ;
>
> $self -> AddTagBlock ('a', ['eplsub'], ['href'], undef,
>
>
> removenode => 42,
> perlcode => {},
> perlcodeend => q{
> {
> my $txt = XML::Embperl::DOM::Node::iChildsText (%$n%) ;
> # here $txt contains the text between <a> and </a>
>
> my $href = %&'href% ;
> # here we have href
>
> # here we could modify the result by calling subs in
>XML::Embperl::DOM::....
>
> }) ;
> }
> },
> }) ;
>
> }
>
>This is of course not exactly what you want, but I think (at least hope) we
>can extent it in the way so it fit's your needs
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. 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).
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. 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)
}},
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 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.
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.
Logically speaking, what we are discussing here is rather like adding
style-sheets to Embperl.
--
Kee Hinckley - Somewhere.Com, LLC
http://consulting.somewhere.com/
[EMAIL PROTECTED]
I'm not sure which upsets me more: that people are so unwilling to accept
responsibility for their own actions, or that they are so eager to regulate
everyone else's.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
