Yaws API discussion

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Yaws API discussion

Mickael Remond-2
Hello,

I feel that there is a need to improve an aspect of yaws api.

The ssi function can be used to include some external html template. My need is to be able to add some dynamic generated values (for example the title in the html header portion)

I am thinking on the best way to do that. The most evident thing is to pass a dictionnary of substitution that needs to be  performed in the included file.

I think it might not be interesting to implement nested evaluation of included files.

What do you think ?
Any clever idea ?

--
Micka?l R?mond
http://www.erlang-fr.org/



Reply | Threaded
Open this post in threaded view
|

Yaws API discussion

Eric Merritt-3
Mickael,

 Per your request I am going to make a few
suggestions. I would, however, warn readers that I
will be swimming in what some consider a holy war
area. I do not intend any kind of little war here, I
am just providing suggestions based on my experience
and knowlege.

I believe that the problem you are having stems from a
core problem with the paradigm yaws has adopted. Yaws,
like PHP and JSP Scriptlets, is founded upon the idea
that actual logic should be embedded in the html page.
This is a bad thing(TM). It limits scalability of the
application by quite a bit. I am not refering to
scalability in terms of speed or performance, but to
scalablity in terms of application size,
reliablity/maintenance, and extensablility.

I am rambling here so forgive me. Back in the early
'80s users of smalltalk realized that the ui design
paradigms of the time were lacking for large projects.
To address the issue they came up with a paradigm
called MVC (Model, View, Controller). This basically
stated that your model (data, logic) should be
seperated from your controller (flow control logic)
and all of that should be seperated from your view
code. It eventually was expoused that the view code
should be extreamly limited. In that it only allows
you to manipulate data provided from your model layer.


This was a really good idea for UIs, and when the WEB
came about it proved to be a really good idea for
webapplications as well.

 To use some hisorical examples, the inventors of JSP
realized this same issue after they released the first
JSP specification. In that original specification JSPs
allowed only scriptlets (which is java code imbedded
in the html and delimited by <% %> tags). This
approach was obviously not MVC like in any way. In
fact, it cuased quite allot of headaches for
developers then (and even in somecases now). Thier
next release included the idea of 'TagLibs' which are
custom tags that use data from provided from some
backend process (via session and request variables).
Now the use of scriptlets are frowned upon almost
universally and are actaully not allowed to be used in
most big projects. This still wasn't really a complete
MVC solution as the coder had to code allot of the
controller and logic framework himself, but it did
provide a foundation. Projects like Struts have made
good use of this foundation and provide full blown MVC
frameworks now. Using these frameworks has made web
application programming much much easier.
 

Well to get back to your problem. If your
Model/Controller layer only provided data to your view
and your view simply made use of that data all you
would need to do is include the header and it could
make use of all the data that was globally available
in the page. In JSPs that is simply an <@include 'page
location'> directive. The included page then simply
makes use of the data already provided.

I realize that the yaws api is based to quite a large
extent on PHP, but PHP is a very poor choice for
large, extensable applications. Don,t get me wrong PHP
is a great thing for quick and dirty applications.
Basically for those applications that only span a few
pages or that are only designed to live a short time.
Anything beyond that and PHP starts to fall down.

I would suggest that you take a look at some of the
Java page rendering technology. They have allot of
experience in this type of thing by now. Probably
start out with the taglib stuff and then take a look
at Struts (available at jakarta.apache.org/struts).
Perhaps also take a look at webmacro
(www.webmacro.org) and velocity
(jakarta.apache.org/velocity). I personally like the
idea of taglibs and compiled pages (I think they are
much faster), but the template engines and thier
restricted data manipulation langauges are nice as
well.

I guess I went kind of long, sorry. I also hope I did
not get anyone too angry.

Thanks,
Eric

--- mickael.remond wrote:

> Hello,
>
> I feel that there is a need to improve an aspect of
> yaws api.
>
> The ssi function can be used to include some
> external html template. My need is to be able to add
> some dynamic generated values (for example the title
> in the html header portion)
>
> I am thinking on the best way to do that. The most
> evident thing is to pass a dictionnary of
> substitution that needs to be  performed in the
> included file.
>
> I think it might not be interesting to implement
> nested evaluation of included files.
>
> What do you think ?
> Any clever idea ?
>
> --
> Micka?l R?mond
> http://www.erlang-fr.org/
>


__________________________________________________
Do You Yahoo!?
Yahoo! Autos - Get free new car price quotes
http://autos.yahoo.com


Reply | Threaded
Open this post in threaded view
|

Yaws API discussion

Alex Peake
Let me state a counter-point.

Microsoft, in its release of ASP.NET also took this approach of separating the UI from the data.
However, they have just released a product called WebMatrix, which goes back to the "old" way - my
guess is that too many people are comfortable with the "mixed" approach and so Microsoft responded.

>From my own point of view, I have built large dynamic web sites with this mixed approach, and have
had no problems evolving the solution at all.

Alex


> -----Original Message-----
> From: owner-erlang-questions
> [mailto:owner-erlang-questions]On Behalf Of Eric Merritt
> Sent: Monday, July 15, 2002 10:14 AM
> To: mickael.remond; erlang-questions
> Subject: Re: Yaws API discussion
>
>
> Mickael,
>
>  Per your request I am going to make a few
> suggestions. I would, however, warn readers that I
> will be swimming in what some consider a holy war
> area. I do not intend any kind of little war here, I
> am just providing suggestions based on my experience
> and knowlege.
>
> I believe that the problem you are having stems from a
> core problem with the paradigm yaws has adopted. Yaws,
> like PHP and JSP Scriptlets, is founded upon the idea
> that actual logic should be embedded in the html page.
> This is a bad thing(TM). It limits scalability of the
> application by quite a bit. I am not refering to
> scalability in terms of speed or performance, but to
> scalablity in terms of application size,
> reliablity/maintenance, and extensablility.
>
> I am rambling here so forgive me. Back in the early
> '80s users of smalltalk realized that the ui design
> paradigms of the time were lacking for large projects.
> To address the issue they came up with a paradigm
> called MVC (Model, View, Controller). This basically
> stated that your model (data, logic) should be
> seperated from your controller (flow control logic)
> and all of that should be seperated from your view
> code. It eventually was expoused that the view code
> should be extreamly limited. In that it only allows
> you to manipulate data provided from your model layer.
>
>
> This was a really good idea for UIs, and when the WEB
> came about it proved to be a really good idea for
> webapplications as well.
>
>  To use some hisorical examples, the inventors of JSP
> realized this same issue after they released the first
> JSP specification. In that original specification JSPs
> allowed only scriptlets (which is java code imbedded
> in the html and delimited by <% %> tags). This
> approach was obviously not MVC like in any way. In
> fact, it cuased quite allot of headaches for
> developers then (and even in somecases now). Thier
> next release included the idea of 'TagLibs' which are
> custom tags that use data from provided from some
> backend process (via session and request variables).
> Now the use of scriptlets are frowned upon almost
> universally and are actaully not allowed to be used in
> most big projects. This still wasn't really a complete
> MVC solution as the coder had to code allot of the
> controller and logic framework himself, but it did
> provide a foundation. Projects like Struts have made
> good use of this foundation and provide full blown MVC
> frameworks now. Using these frameworks has made web
> application programming much much easier.
>
>
> Well to get back to your problem. If your
> Model/Controller layer only provided data to your view
> and your view simply made use of that data all you
> would need to do is include the header and it could
> make use of all the data that was globally available
> in the page. In JSPs that is simply an <@include 'page
> location'> directive. The included page then simply
> makes use of the data already provided.
>
> I realize that the yaws api is based to quite a large
> extent on PHP, but PHP is a very poor choice for
> large, extensable applications. Don,t get me wrong PHP
> is a great thing for quick and dirty applications.
> Basically for those applications that only span a few
> pages or that are only designed to live a short time.
> Anything beyond that and PHP starts to fall down.
>
> I would suggest that you take a look at some of the
> Java page rendering technology. They have allot of
> experience in this type of thing by now. Probably
> start out with the taglib stuff and then take a look
> at Struts (available at jakarta.apache.org/struts).
> Perhaps also take a look at webmacro
> (www.webmacro.org) and velocity
> (jakarta.apache.org/velocity). I personally like the
> idea of taglibs and compiled pages (I think they are
> much faster), but the template engines and thier
> restricted data manipulation langauges are nice as
> well.
>
> I guess I went kind of long, sorry. I also hope I did
> not get anyone too angry.
>
> Thanks,
> Eric
>
> --- mickael.remond wrote:
> > Hello,
> >
> > I feel that there is a need to improve an aspect of
> > yaws api.
> >
> > The ssi function can be used to include some
> > external html template. My need is to be able to add
> > some dynamic generated values (for example the title
> > in the html header portion)
> >
> > I am thinking on the best way to do that. The most
> > evident thing is to pass a dictionnary of
> > substitution that needs to be  performed in the
> > included file.
> >
> > I think it might not be interesting to implement
> > nested evaluation of included files.
> >
> > What do you think ?
> > Any clever idea ?
> >
> > --
> > Mickakl Rimond
> > http://www.erlang-fr.org/
> >
>
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Autos - Get free new car price quotes
> http://autos.yahoo.com
>




Reply | Threaded
Open this post in threaded view
|

Yaws API discussion

Eric Merritt-3
Alex,

 I am glad that you had success. I would guess (not
having looked at the code I could very well be wrong
here) that you may have used parts of MVC even if you
didn't use a framework or werent thinking about it
conciously. I have seen this happen quite allot with
other types of patterns. Programmers reinvent patterns
(like singletons in OO) all the time without ever
knowing it. Even if you didnt go this route I think
that a decent coder can make either approach work. I
would make the argument that using MVC makes it much
easier and increases your chance of success especially
for mediocre programmers or those without allot of
experience. In my opinion, really good coder could
probably write a dynamic, extensably app in brainf**k
but I would want to do it myself. For that matter I
wouldnt want to be the one to maintain it after he
leaves.

 As for Microsofts solution IBM tried to do the
samething with a project call Net.Data that failed
pretty miserably. My other argument is that Microsoft
(like many companies) tends to target the lowest
common denominator with its products. In this
instance, I woulds say that the lowest common
denominator here are those mediocre programmers
mentioned above. Doing things right and according to a
set pattern makes things much more difficult in the
begining, but over time it pays off. Many programmers
either just want to get it done quick, or dont think
about the long term, hence the preference for the
embedded solutions like PHP/ASP. This may be the
reason Microsoft decided to go back to the 'old'
solution.

In any case, I congradulate you on your success and
thank you for your opposing viewpoint.

Thanks,
Eric

 Ps. please excuse my terrible spelling, yahoo still
hasn't gotten the spellcheck feature to work in
mozilla.

--- Alex Peake <apeake> wrote:

> Let me state a counter-point.
>
> Microsoft, in its release of ASP.NET also took this
> approach of separating the UI from the data.
> However, they have just released a product called
> WebMatrix, which goes back to the "old" way - my
> guess is that too many people are comfortable with
> the "mixed" approach and so Microsoft responded.
>
> From my own point of view, I have built large
> dynamic web sites with this mixed approach, and have
> had no problems evolving the solution at all.
>
> Alex
>
>
> > -----Original Message-----
> > From: owner-erlang-questions
> > [mailto:owner-erlang-questions]On
> Behalf Of Eric Merritt
> > Sent: Monday, July 15, 2002 10:14 AM
> > To: mickael.remond;
> erlang-questions
> > Subject: Re: Yaws API discussion
> >
> >
> > Mickael,
> >
> >  Per your request I am going to make a few
> > suggestions. I would, however, warn readers that I
> > will be swimming in what some consider a holy war
> > area. I do not intend any kind of little war here,
> I
> > am just providing suggestions based on my
> experience
> > and knowlege.
> >
> > I believe that the problem you are having stems
> from a
> > core problem with the paradigm yaws has adopted.
> Yaws,
> > like PHP and JSP Scriptlets, is founded upon the
> idea
> > that actual logic should be embedded in the html
> page.
> > This is a bad thing(TM). It limits scalability of
> the
> > application by quite a bit. I am not refering to
> > scalability in terms of speed or performance, but
> to
> > scalablity in terms of application size,
> > reliablity/maintenance, and extensablility.
> >
> > I am rambling here so forgive me. Back in the
> early
> > '80s users of smalltalk realized that the ui
> design
> > paradigms of the time were lacking for large
> projects.
> > To address the issue they came up with a paradigm
> > called MVC (Model, View, Controller). This
> basically
> > stated that your model (data, logic) should be
> > seperated from your controller (flow control
> logic)
> > and all of that should be seperated from your view
> > code. It eventually was expoused that the view
> code
> > should be extreamly limited. In that it only
> allows
> > you to manipulate data provided from your model
> layer.
> >
> >
> > This was a really good idea for UIs, and when the
> WEB
> > came about it proved to be a really good idea for
> > webapplications as well.
> >
> >  To use some hisorical examples, the inventors of
> JSP
> > realized this same issue after they released the
> first
> > JSP specification. In that original specification
> JSPs
> > allowed only scriptlets (which is java code
> imbedded
> > in the html and delimited by <% %> tags). This
> > approach was obviously not MVC like in any way. In
> > fact, it cuased quite allot of headaches for
> > developers then (and even in somecases now). Thier
> > next release included the idea of 'TagLibs' which
> are
> > custom tags that use data from provided from some
> > backend process (via session and request
> variables).
> > Now the use of scriptlets are frowned upon almost
> > universally and are actaully not allowed to be
> used in
> > most big projects. This still wasn't really a
> complete
> > MVC solution as the coder had to code allot of the
> > controller and logic framework himself, but it did
> > provide a foundation. Projects like Struts have
> made
> > good use of this foundation and provide full blown
> MVC
> > frameworks now. Using these frameworks has made
> web
> > application programming much much easier.
> >
> >
> > Well to get back to your problem. If your
> > Model/Controller layer only provided data to your
> view
> > and your view simply made use of that data all you
> > would need to do is include the header and it
> could
> > make use of all the data that was globally
> available
> > in the page. In JSPs that is simply an <@include
> 'page
> > location'> directive. The included page then
> simply
> > makes use of the data already provided.
> >
> > I realize that the yaws api is based to quite a
> large
> > extent on PHP, but PHP is a very poor choice for
> > large, extensable applications. Don,t get me wrong
> PHP
> > is a great thing for quick and dirty applications.
> > Basically for those applications that only span a
> few
> > pages or that are only designed to live a short
> time.
> > Anything beyond that and PHP starts to fall down.
> >
> > I would suggest that you take a look at some of
> the
> > Java page rendering technology. They have allot of
> > experience in this type of thing by now. Probably
> > start out with the taglib stuff and then take a
> look
> > at Struts (available at
> jakarta.apache.org/struts).
> > Perhaps also take a look at webmacro
> > (www.webmacro.org) and velocity
> > (jakarta.apache.org/velocity). I personally like
> the
> > idea of taglibs and compiled pages (I think they
> are
> > much faster), but the template engines and thier
> > restricted data manipulation langauges are nice as
> > well.
> >
> > I guess I went kind of long, sorry. I also hope I
> did
> > not get anyone too angry.
> >
> > Thanks,
> > Eric
> >
> > --- mickael.remond wrote:
> > > Hello,
> > >
> > > I feel that there is a need to improve an aspect
> of
> > > yaws api.
> > >
> > > The ssi function can be used to include some
> > > external html template. My need is to be able to
> add
> > > some dynamic generated values (for example the
> title
> > > in the html header portion)
> > >
> > > I am thinking on the best way to do that. The
> most
> > > evident thing is to pass a dictionnary of
> > > substitution that needs to be  performed in the
> > > included file.
> > >
> > > I think it might not be interesting to implement
> > > nested evaluation of included files.
> > >
> > > What do you think ?
> > > Any clever idea ?
> > >
> > > --
> > > Mickakl Rimond
> > > http://www.erlang-fr.org/
> > >
> >
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Yahoo! Autos - Get free new car price quotes
> > http://autos.yahoo.com
> >
>
>
=== message truncated ===


__________________________________________________
Do You Yahoo!?
Yahoo! Autos - Get free new car price quotes
http://autos.yahoo.com


Reply | Threaded
Open this post in threaded view
|

Yaws API discussion

Chris Pressey
In reply to this post by Eric Merritt-3
On Mon, 15 Jul 2002 10:14:23 -0700 (PDT)
Eric Merritt <cyberlync> wrote:

> Mickael,
>
>  Per your request I am going to make a few
> suggestions. I would, however, warn readers that I
> will be swimming in what some consider a holy war
> area. I do not intend any kind of little war here, I
> am just providing suggestions based on my experience
> and knowlege.
>
> I believe that the problem you are having stems from a
> core problem with the paradigm yaws has adopted. Yaws,
> like PHP and JSP Scriptlets, is founded upon the idea
> that actual logic should be embedded in the html page.
> This is a bad thing(TM). It limits scalability of the
> application by quite a bit. I am not refering to
> scalability in terms of speed or performance, but to
> scalablity in terms of application size,
> reliablity/maintenance, and extensablility.

My two cents:

I agree that it is a Bad Thing<tm>, for the reason that interleaving
different languages in the same source code file results a polyglot that
is harder to understand and consequently harder to maintain.  In order to
write a good 'active page' you need to write good HTML and good code, and
few people specialize in both.

Even more unpopular opinion follows:

I don't see the big deal with yaws besides performance (which, as has been
mentioned, it gets by "cheating" like mad.)  On sourceforge it is
described as "small and beautiful" but I find it to be neither, at least
in comparison to pico.  No offense meant to Klacke, but it's only as well
designed as any project called "yet another foo" would be expected to be.
I feel it is trying to do too much.

So, I'm writing my own web server.  Mainly I'm doing so because of the
usual Erlang-hacker excuse, that nothing available out there provides
quite the right balance of features that I'm looking for (of course this
is just to hide the fact that it's more fun to roll your own :)

For the sake of elegant design I have consciously decided not to support
documents consisting of interleaved Erlang and HTML in my project.
Instead, templates have fields which are filled out from values in a
dictionary.

While I do not suppose it will be able to compete with yaws in terms of
sheer performance, that can always be added later, once driver-side
http-header parsing is a documented feature...

-Chris


Reply | Threaded
Open this post in threaded view
|

Yaws API discussion

Eric Merritt-3
See inline ->

--- Chris Pressey <cpressey> wrote:
 

> My two cents:
>
> I agree that it is a Bad Thing<tm>, for the reason
> that interleaving
> different languages in the same source code file
> results a polyglot that
> is harder to understand and consequently harder to
> maintain.  In order to
> write a good 'active page' you need to write good
> HTML and good code, and
> few people specialize in both.

I agree with you here. Most people dont realize this,
or they dont agree with the supposition (I attribute
this to lack of experience in the domain).

> Even more unpopular opinion follows:
>
> I don't see the big deal with yaws besides
> performance (which, as has been
> mentioned, it gets by "cheating" like mad.)  On
> sourceforge it is
> described as "small and beautiful" but I find it to
> be neither, at least
> in comparison to pico.  No offense meant to Klacke,
> but it's only as well
> designed as any project called "yet another foo"
> would be expected to be.
> I feel it is trying to do too much.

 Well in defense of klacke, he achieved his design
goals. Which is more then I can say for many projects.
The resultof his efforts is exaclty what he wanted.

> So, I'm writing my own web server.  Mainly I'm doing
> so because of the
> usual Erlang-hacker excuse, that nothing available
> out there provides
> quite the right balance of features that I'm looking
> for (of course this
> is just to hide the fact that it's more fun to roll
> your own :)

  Not a bad idea.

> For the sake of elegant design I have consciously
> decided not to support
> documents consisting of interleaved Erlang and HTML
> in my project.
> Instead, templates have fields which are filled out
> from values in a
> dictionary.
 
  As far as I am concerned this is the right choice.
But dont forget that you need to support lists as
well. Also are you going to go with the specialed
template language approach or the tag approach? If you
go with the tag approach I would suggest that you use
something other then <> as tag delimiters. Awhile back
I wrote a custom template engine for a client and made
use of [] for tag delimiters. It made the parser much
easier to write and the tags tended to stand out
pretty well against the html.

> While I do not suppose it will be able to compete
> with yaws in terms of
> sheer performance, that can always be added later,
> once driver-side
> http-header parsing is a documented feature...

Why not? go ahead and lift the code from yaws, thats
what open source is about. In this case, the
documentation is yaws itself. Also, if you compile
your templates to erlang you should get pretty close
to the performance of yaws.

> -Chris


__________________________________________________
Do You Yahoo!?
Yahoo! Autos - Get free new car price quotes
http://autos.yahoo.com


Reply | Threaded
Open this post in threaded view
|

Yaws API discussion

Willem Broekema
In reply to this post by Chris Pressey
Chris Pressey wrote:
> I agree that it is a Bad Thing<tm>, for the reason that interleaving
> different languages in the same source code file results a polyglot that
> is harder to understand and consequently harder to maintain.  In order to
> write a good 'active page' you need to write good HTML and good code, and
> few people specialize in both.

For an example of a web page template language that does not prevent you
from editing the page with a (WYSIWYG) HTML editor (so logic and
presentation can be done apart from each other): take a look at Zope Page
Templates.

There, variables, loops, including other page snippets etc are all done by
setting special attributes in the regular HTML tag. This allows the
template page to be valid (X)HTML. There can be dummy contents that will
replace at request time with the appropriate value.

Here's a simple example (the whole <span> tag will get replaced by the title):

   <span tal:replace="template/title">Title goes here...</span>

Iteration over a list (with one row dummy contents, so template can be
previewed unparsed, to see how it will look after parsing):

  <tr tal:repeat="person cool_people">
     <td tal:content="person/name">Bill</td>
     <td tal:content="person/age">23</td>
   </tr>


It's probably a problem that Zope is Object Oriented: person/name means
"the name attribute of the object named person". Erlang records are a poor
substitute for this, especially because 'person/name' may also refer to the
'name' *method* of the person object.

Nevertheless,  I like using attributes as template commands seems better
than using special <? or [ tags, so that may be something to consider in Yaws.

Some ZPT links, if you're interested:

  ZPT Tutorial
   - http://www.zope.org/Wikis/DevSite/Projects/ZPT/TutorialPart1

  ZPT in the Zope Book
   - http://www.zope.org/Documentation/ZopeBook/ZPT.stx
   - http://www.zope.org/Documentation/ZopeBook/AdvZPT.stx (advanced)


- Willem



Reply | Threaded
Open this post in threaded view
|

Yaws API discussion

Jimmie Houchin
In reply to this post by Chris Pressey
What is the target developer for any of these said web app servers?

Is the target a webshop which has seperate HTML designers and web
programming developers? Or are they designed for the person/people who
can do (is doing) it all?

If peaceful coexistance between HTML people and programmers is a
requirement, then Zope is an excellent example, for that is a primary
goal of Zope. However if that is not a requirement then Quixote (yet
another Python web app server) provides an interesting perspective.

http://www.amk.ca/python/writing/mx-architecture/
http://www.mems-exchange.org/software/quixote/

Being Python based and its users proficient Python programmers they
prefer to stay as close to and within Python as much as possible for
their web app development. Even their templating language PTL's (Python
Template Language) goal is to be very Pythonic in flavor.

Whether or not their design goals are shared here, it is an interesting
read to see other perspectives. The authors of this web app server are
very familiar with Zope and chose this direction for their own development.

Take a look.

Jimmie Houchin



Reply | Threaded
Open this post in threaded view
|

Yaws API discussion

Eric Merritt-3
See inline -->
--- Jimmie Houchin <jhouchin> wrote:
> What is the target developer for any of these said
> web app servers?
>
> Is the target a webshop which has seperate HTML
> designers and web
> programming developers? Or are they designed for the
> person/people who
> can do (is doing) it all?

 I would have to disagree with this logic a bit. Shops
change, either growing or getting smaller. Today you
could have one guy that does it all. Next your or five
years from now you could have a dedicated team of 15
html guys and five coders. I would have to say you
split it into the easiest solution for both. Coders
generally wont have a problems with a simple template
language/tag set so go that route. If things change
down the road you still have it covered.

> If peaceful coexistance between HTML people and
> programmers is a
> requirement, then Zope is an excellent example, for
> that is a primary
> goal of Zope.
 
The only issue I really have with zope is I dont like
how it mixes html and view logic. Feel free to
disagree with me, but this would seem to make it
harder to distinguise between markup and view logic
especially on a large/complex page. I also dont really
like the idea of extending the existing html standard.
I realize that once it gets out to the browser you end
up with plain html but it still doesnt sit well with
me.
 


__________________________________________________
Do You Yahoo!?
Yahoo! Autos - Get free new car price quotes
http://autos.yahoo.com


Reply | Threaded
Open this post in threaded view
|

Yaws API discussion

Chris Pressey
In reply to this post by Eric Merritt-3
On Tue, 16 Jul 2002 10:09:14 -0700 (PDT)
Eric Merritt <cyberlync> wrote:

>  Well in defense of klacke, he achieved his design
> goals. Which is more then I can say for many projects.
> The resultof his efforts is exaclty what he wanted.

According to motivation.yaws, he wanted something less ad-hoc than PHP,
and yaws is that.

(But I want something even less ad-hoc than yaws :)

> [snip]
>   As far as I am concerned this is the right choice.
> But dont forget that you need to support lists as
> well. Also are you going to go with the specialed
> template language approach or the tag approach? If you
> go with the tag approach I would suggest that you use
> something other then <> as tag delimiters. Awhile back
> I wrote a custom template engine for a client and made
> use of [] for tag delimiters. It made the parser much
> easier to write and the tags tended to stand out
> pretty well against the html.

Currently I'm using tags formatted like ${This}, because it evolved from
some (now quite old) Perl CGI code.  They stand out quite well.

Iterating over lists is currently done in the Erlang handlers (in .beam
files) and the whole table is exported as a single tag.  This is less than
ideal since it hard-codes things like cell alignment.  It's also not very
scaleable, but who wants to see an HTML table with a million cells in it
anyway?  Better to break it up into many smaller pages.

I'm intrigued by Zope's "format by example" approach, and if I'm going to
improve on the templating I might go in that direction...

-Chris