hi cliff,
  my comments below in [] brackets below..
/ eitan

-----Original Message-----
From: ___cliff rayman___ [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, January 02, 2001 5:37 PM
To: Eitan Suez
Cc: [EMAIL PROTECTED]
Subject: Re: feature request/suggestion??



Eitan Suez wrote:

> 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.

why?
reality is - Gerald will actually read and listen to what we have
to say.  my chance of getting Gerald to make a change is MUCH
greater than my chance of getting Macromedia to adjust to embperl.
especially on the issue of example text, since i do not see a good way
to parse it without embperl's help.

[ good point.  still i don't think that is the correct way
  to solve this issue.
 ]

>
>
>   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).

exactly!

>
>
>   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.

can a dreamweaver extension be written taking into account
the existing embperl syntax, that allows the gui to render the page with
sample data??  if not, then your above statements are good theory, a theory
i tend to agree with, but do nothing for me in practice.  the reality is,
today,
my designer cannot design a good looking web page using embperl statements
within dreamweaver.

[ i do not know enough about dreamweaver to tell you for sure
  whether they just display some sort of placeholder gif where
  some dynamic element should reside or whether they actually
  interpret the statement and display its actual value.  my
  guess is the former.  currently there exist extensions for jsp,
  coldfusion, asp, and a few others but not embperl.

  the issue of designing web pages using gui's has been debated
  for a long time.  there are many that argue that web pages
  are not the equivalent of an ms word document and that wysiwyg
  does not really work in the context of the web.  this is
  a strong statement but has some merit -- here we are 5 or 6 years
  after the explosion of the web and still looking for a good
  gui design tool!  i personally use homesite in text mode and a
  browser for the visual feedback.  that's what i've always used
  and am pretty happy with it.

  i know that dreamweaver is popular among many non-programmers
  but i know of few programmers that use it.  i've thought about
  writing an extension for embperl but i honestly don't think i
  can find the time.

  microsoft makes wysiwyg design tools (or attempts to anyway) and
  their visual interdev product has both 'source' and 'design' tabs
  but their tools are not designed for embperl.

  maybe your web designer is too high maintenance?  :)


/ eitan
]



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to