You are viewing a plain text version of this content. The canonical link for it is here.
Posted to embperl@perl.apache.org by Kee Hinckley <na...@somewhere.com> on 2002/03/05 22:44:01 UTC
Designing embperl for WYSIWYG editors - hope in embperl 2?
Site templates often contain page-specific code. Tools like
DreamWeaver don't deal with this well (eventually they'' need
design-time conditionals, but they aren't there yet). Embperl deals
with it fine, but....
As an example, a page might have a navigation element that appeared as
Home
on the front page, and
<a href="/index.html">Home</a>
on all other pages.
I can think of two ways of handling that in Embperl, although there are others
[$ if (PageIs('/index.html')) $]
Home
[$ else $]
<a href="/index.html">Home</a>
[$ endif $]
or
[- ShowLink('Home', '/index.html') -]
In the former case PageIs checks the SCRIPT_NAME environment
variable, special cases index.html and / as the same, and returns the
appropriate value. In the second case we define a [$ sub $]
somewhere that does the right thing.
Note that that was the simple case, consider the following:
<tr>
<td><img name="home" border="0"
src="/images/nav_on_home.gif" width="122" height="24"
alt="MeAIMH Home">
</td>
</tr>
and
<tr>
<td><a href="/index.html" onMouseOut="MM_swapImgRestore()"
onMouseOver="MM_swapImage('home','',
'/images/nav_on_home.gif',1)">
<img name="home" border="0" src="/images/nav_off_homes.gif"
width="122" height="25" alt="MeAIMH Home"></a>
</td>
</tr>
Here's the problem regardless of the complexity. The first Embperl
example is going to show up in a program like DreamWeaver as
EPTAG Home EPTAG <a href="/index.html">Home</a> EPTAG
which will completely blow out the design and make it very hard for
the designer to figure out what things look like. (That assumes
you've installed my DreamWeaver extensions for marking Embperl tags,
otherwise it looks even worse.) The second example is no better, it
shows up as EPTAG, giving the designer no clue what it's going to
look like.
Here's what I'd like to be able to do, making up some syntax on the
fly. (Including a new kind of sub declaration, but you get the idea.)
<a href="/index.html" eplsub=pagelink>Home</a>
[$ sub pagelink($tagname, $tagarray, $taghash, $tagstring,
$content, $endtag) $]
[$ if (PageIs($taghash->{href})) $]
[+ $content +]
[$ else $]
[+ $tagstring . $content . $endtag +]
[$ endif $]
[$ endsub $]
I've stolen some of these ideas from HTML::Parser. $tagname in this
case would be 'a'. $tagarray is an array of the elements in the tag
(e.g. href,eplsub) in order. $taghash is the lookup array. $content
is either empty (this is a non-enclosing tag) or contains everything
between this tag and its end tag. $tagstring is the text of the tag
with arguments, and $endtag is the terminating tag if any.
There might be a better way of specifying which tags get executed
(eplsub might upset some compliance checkers). You could use css
tags and the sub could be something like:
[$ sub a:pagelink $]
You'll note that the second example I gave isn't quite so easy.
You'd probably want to have the default be no link, and the code
would generate the HTML for the more complex roll-over case,
depending on naming conventions for the images.
Thoughts?
--
Kee Hinckley - Somewhere.Com, LLC
http://consulting.somewhere.com/
nazgul@somewhere.com
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: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org
Re: Recipe at top of the file (was: Designing embperl for WYSIWYG editors - hope in embperl 2?)
Posted by Gerald Richter <ri...@ecos.de>.
>
> 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.
>
You can't do this, because Embperl has to know how to process the file,
before it could process the file and exctract the name of the recipe from
the file.
What you can do is, to make a (meta-)recipe that decides what recipe to use
for example by using the file extentions, or you can use the newly
indtroduced application object to do this. Look at eg/web/epwebapp.pl, this
is an application object, it's get_recipe method is called by Embperl for
every file it processes, eg/web/epwebapp.pl get_recipe now looks at the file
extention of the file on the filesystem and at the file extention of the
file that the user requested and chooses the correct recipe, syntax and
other parameters.
Gerald
-------------------------------------------------------------
Gerald Richter ecos electronic communication services gmbh
Internetconnect * Webserver/-design/-datenbanken * Consulting
Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz
E-Mail: richter@ecos.de Voice: +49 6133 925131
WWW: http://www.ecos.de Fax: +49 6133 925152
-------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org
Re: Designing embperl for WYSIWYG editors - hope in embperl 2?
Posted by Gerald Richter <ri...@ecos.de>.
>
> 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: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org
Re: Designing embperl for WYSIWYG editors - hope in embperl 2?
Posted by Kee Hinckley <na...@somewhere.com>.
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/
nazgul@somewhere.com
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: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org
Re: Designing embperl for WYSIWYG editors - hope in embperl 2?
Posted by Gerald Richter <ri...@ecos.de>.
Hi,
yes, of course there is hope :-)
>
> Here's what I'd like to be able to do, making up some syntax on the
> fly. (Including a new kind of sub declaration, but you get the idea.)
>
> <a href="/index.html" eplsub=pagelink>Home</a>
>
> [$ sub pagelink($tagname, $tagarray, $taghash, $tagstring,
> $content, $endtag) $]
>....
Here is what can be done at the moment. Look if/how this fits to your idea,
then we can see how can evolve it to do the right thing.
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) ;
if (!$self -> {-xxxInit})
{
$self -> {-xxxInit} = 1 ;
Init ($self) ;
}
return $self ;
}
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
Gerald
-------------------------------------------------------------
Gerald Richter ecos electronic communication services gmbh
Internetconnect * Webserver/-design/-datenbanken * Consulting
Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz
E-Mail: richter@ecos.de Voice: +49 6133 925131
WWW: http://www.ecos.de Fax: +49 6133 925152
-------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org