hi cliff,
i understand your concern. my opinion is that this is
not so much an issue of how you design your dynamic
web page engine as it is an issue of the visual design
tools being made smart enough to understand how the
engine works.
you are correct that the interpretation of the statements
needs to happen at design time in order for this to be
of any use to web page designers who design and lay out
the pages.
that is why tools such as visual interdev, frontpage, and
allaire's homesite build into their editors a "design"
or "browse" tab (or both). this allows a designer to see
exactly what the page looks like at design time (and they
don't have to leave their authoring application to do so).
i would still argue that this has little to do with the
feature i am proposing.
i'd like to go a little further:
i really believe that the design of GUI authoring tools
and the design of a web page generation engine (such as
embperl) should be independent of one another.
gerald ought to be able to build features into embperl
without having to think about how the gui design tool
will look like for the web page author. likewise, the
designer of the gui tool (say, dreamweaver) should not
have to worry about whether a dynamic piece of text is
written as <%text%> or as [+$text+] in order to decide
how to display the gui widget that represents this piece
of text on the screen.
that is what dreamweaver extensions were designed to
do: translate the text into the gui and vice versa.
/ eitan
-----Original Message-----
From: ___cliff rayman___ [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, January 02, 2001 5:00 PM
To: Eitan Suez
Cc: [EMAIL PROTECTED]
Subject: Re: feature request/suggestion??
Eitan Suez wrote:
> > only problem that i can see is one of design. my designer uses
> dreamweaver.
> > how do u design a visually appealing form when the <EMBPERL> tag is
> > not going to have any 'rendering' in the design software??
>
> --- snip----
>
> my point is this: moving the description of the form elements
> to a separate file does not mean that you can't design your pages
> visually. actually one has nothing to do with the other.
>
i think it does, unless i am missing the ability of the extensions.
i understand that dreamweaver extensions can ignore embedded statements.
does
it do anything more than ignore them however??
say we have something in our page that details our price, such as:
Our Price $6.50
in embed perl we would write something like:
Our Price [+ $unitPrice +]
if the tags are ignored, then the space takes up no characters on the design
screen.
if the tags are not ignored, then it takes up too much space on the design
screen.
so, in order for the designer to test the design, they have to:
1) remove embed perl and replace with sample data
2) finish the design,
3) replace all sample data with embed perl.
based on the conf file request u made, all fields are what, zero width? a
default of 10?
how does this form look when it is being designed??
my designer is very picky about asthetics. the above replace, design,
replace cycle
is too labor intensive. they like to see what they are going to get on the
finished site.
IMHO embperl needs something that allows the sample data to show at design
time,
and get replaced by the embedperl data at runtime. something like
Our Price [+ $unitPrice =]$6.50[= +]
dreamweaver would then show the $6.50 price at design time,
embedperl would show the value of variable $unitPrice and strip out the
$6.50 sample data.
--
___cliff [EMAIL PROTECTED]http://www.genwax.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
