Gerald,
i know you are now contemplating the next major release.
you've indicated your intention to adapt a new parser or rewrite one
from scratch. also, you've indicated that some tags may change,
be eliminated, or made configurable. in that vein i am offering my wish
list for the new tag implementation.
we are using dreamweaver at our site, and it does not
mix well with embperl. since dreamweaver does not
recognize the embperl tags, it renders them in the gui
design window as text.
designers are careful to layout every pixel with care.
if we type in something like:
[- foreach $data (sort keys %{$hashref}){ -]
it will take up space on the interface. the page looks just plain ugly
in the gui, and it is not feasible to make a small change, save the
page,
bring the page up in the browser, etc. etc.. since the designers cannot
properly design a page with embperl code included, i end up having to
add
it by hand when they are done. this is tedious at best.
using a standard tag such as <%
and coupling it with a variable char to indicate the embperl command
type,
we get the following:
[.- becomes <%-
[.! becomes <%!
[.* becomes <%*
[.# becomes <%#
[.$ becomes <%$
the designer can view the tags and edit them when they
go into 'html source' editing mode, but the tags and their contents
will neatly disappear when they are using the gui to layout the page.
the above trick should work fine for everything except [.+. in this
case there is some space that needs to be taken up since some
result will be inserted into the html stream for output. even better
than
taking up space, would be to emit some example text. this would
give the designer the ability to layout the page in the gui with
a wysiwyg environment.
how about enclosing tags with example text? such as:
<%( $ref->[$row]{$fieldvar} (%> EXAMPLE TEXT <%))%>
the <% %> cause everything between the tags to be ignored
by dreamweaver and not rendered in the gui.
the <%( is exactly like using the [.+ except that after the
perl is output, all data in the file is ignored until <%))%> is scanned.
i originally thought of adding an ID (ala html/xml) such as:
<%(MY_ID $ref->[$row]{$fieldvar} (%>EXAMPLE TEXT<%)MY_ID)%>
but i am not sure the extra complication would be warranted. how would
we
handle nested ID's and nested example text?
this technique will also allow dreamweaver to properly size the columns
of a table. currently if i add the following to a table:
[+ $prdstdans[$row]{UOM} +]
it causes the table to be widened to fit the entire field. in this
particular
case the unit of measure field normally returns only two characters, so
the
field ends up being sized much too wide. but if we enter the following:
<%( $prdstdans[$row]{UOM} (%>CS<%))%>
dreamweaver correctly sizes the column for the 2 digit example result.
this new technique would give the designer the ability to layout the
page
in the gui with a wysiwyg environment. the embperl commands can be
added in the source editing window by either the designer or a
programmer,
without destroying how the page is rendered in the dreamweaver gui or in
a static view of the page in a browser.
thanks for your consideration and for a great product which includes
better tech support than anything i have ever paid for.
cliff rayman
genwax.com
i know you are now contemplating the next major release.
you've indicated your intention to adapt a new parser or rewrite one
from scratch. also, you've indicated that some tags may change,
be eliminated, or made configurable. in that vein i am offering my wish
list for the new tag implementation.
we are using dreamweaver at our site, and it does not
mix well with embperl. since dreamweaver does not
recognize the embperl tags, it renders them in the gui
design window as text.
designers are careful to layout every pixel with care.
if we type in something like:
[- foreach $data (sort keys %{$hashref}){ -]
it will take up space on the interface. the page looks just plain ugly
in the gui, and it is not feasible to make a small change, save the
page,
bring the page up in the browser, etc. etc.. since the designers cannot
properly design a page with embperl code included, i end up having to
add
it by hand when they are done. this is tedious at best.
using a standard tag such as <%
and coupling it with a variable char to indicate the embperl command
type,
we get the following:
[.- becomes <%-
[.! becomes <%!
[.* becomes <%*
[.# becomes <%#
[.$ becomes <%$
the designer can view the tags and edit them when they
go into 'html source' editing mode, but the tags and their contents
will neatly disappear when they are using the gui to layout the page.
the above trick should work fine for everything except [.+. in this
case there is some space that needs to be taken up since some
result will be inserted into the html stream for output. even better
than
taking up space, would be to emit some example text. this would
give the designer the ability to layout the page in the gui with
a wysiwyg environment.
how about enclosing tags with example text? such as:
<%( $ref->[$row]{$fieldvar} (%> EXAMPLE TEXT <%))%>
the <% %> cause everything between the tags to be ignored
by dreamweaver and not rendered in the gui.
the <%( is exactly like using the [.+ except that after the
perl is output, all data in the file is ignored until <%))%> is scanned.
i originally thought of adding an ID (ala html/xml) such as:
<%(MY_ID $ref->[$row]{$fieldvar} (%>EXAMPLE TEXT<%)MY_ID)%>
but i am not sure the extra complication would be warranted. how would
we
handle nested ID's and nested example text?
this technique will also allow dreamweaver to properly size the columns
of a table. currently if i add the following to a table:
[+ $prdstdans[$row]{UOM} +]
it causes the table to be widened to fit the entire field. in this
particular
case the unit of measure field normally returns only two characters, so
the
field ends up being sized much too wide. but if we enter the following:
<%( $prdstdans[$row]{UOM} (%>CS<%))%>
dreamweaver correctly sizes the column for the 2 digit example result.
this new technique would give the designer the ability to layout the
page
in the gui with a wysiwyg environment. the embperl commands can be
added in the source editing window by either the designer or a
programmer,
without destroying how the page is rendered in the dreamweaver gui or in
a static view of the page in a browser.
thanks for your consideration and for a great product which includes
better tech support than anything i have ever paid for.
cliff rayman
genwax.com