Mailing List Archive

On Thu, 23 Mar 2000, Frerk Meyer wrote:

> I propose to rethink the syntax of the brakets of Embperl.
...
>
> I would suggest an alternative syntax for Embperl like
> <%- being the same as [- and so on just to keep
> our HTML-pages safe after they are worked on by
> the graphics department.

Please YES!!!!

I have been forced to switch to Apache::ASP for just that reason -
OK I know: I could have pre- and post-processed everything on the way
in and out of the graphics tools - but thats just *too* much bother.

Let's go as close to the established de-facto standards as possible.

---
Henrik Tougaard ht000@foa.dk
FOA Trade Union for Public employees Denmark.
#include <disclaim.std>

>
> I would suggest an alternative syntax for Embperl like
> <%- being the same as [- and so on just to keep
> our HTML-pages safe after they are worked on by
> the graphics department.
>
Next version of Embperl give you the possibility to configure whatever
syntax you like. I hope to get a first beta out during april

Gerald

>
> I have been forced to switch to Apache::ASP for just that reason -
> OK I know: I could have pre- and post-processed everything on the way
> in and out of the graphics tools - but thats just *too* much bother.
>
> Let's go as close to the established de-facto standards as possible.
>
Question (so I can make the next version better): Embperl makes a lot
efforts to work with the code these Highlevel HTML editor produces. For
example our customers use MS Frontpage to edit pages which contains Perl
blocks, and Embperl is still able to interpret them afterwards (e.g. it
converts things like &lt; back to <).

What problems you exactly have when using [ .. ] blocks? Is it that the perl
code is visible to the designers or is it that your editor breaks the perl
code? If it breaks the perl code, what does it do to the code?

Also consider code like <TR BGCOLOR=[+ $col +]> or even <TR [$ if $col
$]BGCOLOR="#ffffff"[$endif$]>, how should this look with the new syntax?

More comments on this topic would be very helpfull! Anything you say now has
the chance to go into the next version...

Gerald

> The WYSIWYG editors don't break the perl-code (at least I haven't seen
> that (yet:), but the EmbPerl code breaks the wysiwyg. Especially if
> you have tables with reasonably complex perl-code in them.
> The formatting is all wierd, which does make it a bit pointles to use
> a visual tool to format the layout.
>
> Eg. Dreamweaver is able to represent any expression in <%..%> as a
> small icon letting the graphics designer do his job without my code
> interfering. DW is a good engough tool that it will leave whatever I
> put in the <%..%> alone, so I have not had use for the '&lt;' -> '>'
> conversion (we shy away from MS Frontpage because it changes things
> for apparently no good reason!).
>

Ok, for working in this way, I agree it would be really usefull to change to
<% etc.
The [.+ etc. was basicly choosen, so you _don't_ get the small icons for your
perl code, because it was (the time I started Embperl) very hard to edit
them in this editors, because you had to go to lot of dialogs. Using [.+ etc.
you can edit them as simple text, but of course you are totaly right that
this breaks the layout if the perl code inside gets to large.

> >
> > Also consider code like <TR BGCOLOR=[+ $col +]> or even <TR [$ if $col
> > $]BGCOLOR="#ffffff"[$endif$]>, how should this look with the new syntax?
> >
>
> Something like:
> <TR BGCOLOR=<%= $col %>

Is there missing an closing '>' ?


> and
> <TR <% if ($col) {%> BGCOLOR="#ffffff"<%}%>>
>
> I must have been using Apache::ASP too much ;-)
> But seriously: I do like the idea of using Perl syntax to control
> things. I haven't considered whether it would ruin EmbPerl or not...
>

For me it's harder to read, but this is a matter of taste. Of course using
the Perl control structures has adavtages.

In my plans for the next version, I like to improve also this area (you can
already do it with [* *], but it does not work under all conditions)

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 925151
WWW: http://www.ecos.de Fax: +49 6133 925152
-------------------------------------------------------------

On Fri, 24 Mar 2000, Gerald Richter wrote:
> > >
> > > Also consider code like <TR BGCOLOR=[+ $col +]> or even <TR [$ if $col
> > > $]BGCOLOR="#ffffff"[$endif$]>, how should this look with the new syntax?
> > >
> >
> > Something like:
> > <TR BGCOLOR=<%= $col %>
>
> Is there missing an closing '>' ?

Of course! It does look a bit too lisp'ish though. That could be
construed as an advantage for the current [+ .. +] scheme.
>
>
> > and
> > <TR <% if ($col) {%> BGCOLOR="#ffffff"<%}%>>
> >
> > I must have been using Apache::ASP too much ;-)
> > But seriously: I do like the idea of using Perl syntax to control
> > things. I haven't considered whether it would ruin EmbPerl or not...
> >
>
> For me it's harder to read, but this is a matter of taste. Of course using
> the Perl control structures has adavtages.
>
Not the least of which is not having to remember another set of
control structures. I usually take a break when I use a dangling if in
C++!

> In my plans for the next version, I like to improve also this area (you can
> already do it with [* *], but it does not work under all conditions)
>

---
Henrik Tougaard ht000@foa.dk
FOA Trade Union for Public employees Denmark.
#include <disclaim.std>

Gerald Richter wrote:

> Question (so I can make the next version better): Embperl makes a lot
> efforts to work with the code these Highlevel HTML editor produces. For
> example our customers use MS Frontpage to edit pages which contains Perl
> blocks, and Embperl is still able to interpret them afterwards (e.g. it
> converts things like &lt; back to <).

Editors with support for ASP tags don't change the code at all. That is
the
point. So no action is required afterwards and designer won't see the
code, but only a replacement icon.

> What problems you exactly have when using [ .. ] blocks? Is it that the perl
> code is visible to the designers or is it that your editor breaks the perl
> code? If it breaks the perl code, what does it do to the code?

I've tested Dreamweaver, GoLive and Homesite. They do all ASP, some do
ColdfusionML, SSI or PHP. The best one was Dreamweaver, the worst
GoLive (only ASP). I couln't test Frontpage.

> Also consider code like <TR BGCOLOR=[+ $col +]> or even <TR [$ if $col
> $]BGCOLOR="#ffffff"[$endif$]>, how should this look with the new syntax?

<% is like [- and
<%= is like [+
Example:
<TR BGCOLOR="<%= $col %>"> (The editors I tested had no problem with
double
closing tags as long as they use '%>'
The other example was given in a previous posting, I'm not an expert in
ASP syntax.

> More comments on this topic would be very helpfull! Anything you say now has
> the chance to go into the next version...

I guess there is no need to make the syntax configurable to any sequence
of characters as brackets but just the popular ones with priority to ASP
because of my tests.

> Gerald
--
Frerk Meyer mailto:fm@channel-one.de
Channel.One http://www.channel-one.de

Why not just wrap embperl in html comments?
<!--[-
# this is what i usually do for complex perl code
-]-->

I know it's not the best solution, but it's something.

ilia.


> -----Original Message-----
> From: Gerald Richter [mailto:richter@ecos.de]
> Sent: Thursday, March 23, 2000 11:48 PM
> To: Henrik Tougaard
> Cc: Embperl@Perl. Apache. Org
> Subject: RE: [- vs <% vs <?
>
>
> > The WYSIWYG editors don't break the perl-code (at least I haven't seen
> > that (yet:), but the EmbPerl code breaks the wysiwyg. Especially if
> > you have tables with reasonably complex perl-code in them.
> > The formatting is all wierd, which does make it a bit pointles to use
> > a visual tool to format the layout.
> >
> > Eg. Dreamweaver is able to represent any expression in <%..%> as a
> > small icon letting the graphics designer do his job without my code
> > interfering. DW is a good engough tool that it will leave whatever I
> > put in the <%..%> alone, so I have not had use for the '&lt;' -> '>'
> > conversion (we shy away from MS Frontpage because it changes things
> > for apparently no good reason!).
> >
>
> Ok, for working in this way, I agree it would be really usefull
> to change to
> <% etc.
> The [.+ etc. was basicly choosen, so you _don't_ get the small
> icons for your
> perl code, because it was (the time I started Embperl) very hard to edit
> them in this editors, because you had to go to lot of dialogs.
> Using [.+ etc.
> you can edit them as simple text, but of course you are totaly right that
> this breaks the layout if the perl code inside gets to large.
>
> > >
> > > Also consider code like <TR BGCOLOR=[+ $col +]> or even <TR [$ if $col
> > > $]BGCOLOR="#ffffff"[$endif$]>, how should this look with the
> new syntax?
> > >
> >
> > Something like:
> > <TR BGCOLOR=<%= $col %>
>
> Is there missing an closing '>' ?
>
>
> > and
> > <TR <% if ($col) {%> BGCOLOR="#ffffff"<%}%>>
> >
> > I must have been using Apache::ASP too much ;-)
> > But seriously: I do like the idea of using Perl syntax to control
> > things. I haven't considered whether it would ruin EmbPerl or not...
> >
>
> For me it's harder to read, but this is a matter of taste. Of course using
> the Perl control structures has adavtages.
>
> In my plans for the next version, I like to improve also this
> area (you can
> already do it with [* *], but it does not work under all conditions)
>
> 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 925151
> 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
>
>

Ilia Lobsanov wrote:
>
> Why not just wrap embperl in html comments?
> <!--[-
> # this is what i usually do for complex perl code
> -]-->
>
> I know it's not the best solution, but it's something.
>
> ilia.
>
This is no solution in our environment, because
Adobe GoLive! rearranges HTML comments:

Orginal SSI:
<!--#a -->
b
<!--#c -->
d
<!--#e -->

After GoLive!:
<!--#a -->
<!--#c -->
<!--#e -->
b
d

Result is that even conditional HTML is not possible
(or an GoLive! expert has a hint for us).
--
Frerk Meyer mailto:fm@channel-one.de
Channel.One http://www.channel-one.de