<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0">
  <channel>
    <title>philippewang.info</title>
    <link>http://philippewang.info/</link>
    <description>
BASHGXD : BashGXD Another Super HTML Generator XD
</description>
    <language>fr</language>
    <generator>BASHGXD Another Super HTML Generator XD</generator>
    <item>
    <guid>http://philippewang.info/programmation.bashgxd.xml</guid>
      <title>
BASHGXD : BashGXD Another Super HTML Generator XD
</title>
      <link>http://philippewang.info/programmation.bashgxd.htm</link>
      <pubDate>Mon, 5 Feb 2007 01:37:06 +0100</pubDate>
      <description><![CDATA[
<!-- BODY - N LINES -->
<div style="text-align:left;width:70%;text-align:justify">
<h1>BASHGXD : BashGXD Another Super HTML Generator XD</h1>
<h2>Coming in 2007 (or 2008 if ever I get really really really busy)</h2>


<p>
  BashGXD is the system I use to generate most of the xHTML pages of
  this web site. It is based on Gnu Bash and Gnu Make, and now some 
  Objective Caml... 
</p>

<p>
  The purpose of this system is to allow you to build your pages in
  <a href="http://www.w3.org/TR/xhtml11/">XHTML 1.1</a> [that is
  described by
  <a href="http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">this DTD</a>
  (<a href="http://en.wikipedia.org/wiki/Document_Type_Definition">Document 
    Type Definition</a>)],
  using some "templates" (or "containers") to generate the final
  files.
  Unlike Apache/PHP system that generates some dynamic pages, this
  system generates mostly static pages that take no
  <a href="http://en.wikipedia.org/wiki/Common_Gateway_Interface">CGI</a> 
  arguments.
</p>

<p>
  The first good point of this system is the security matter: 
  whereas dynamic pages can introduce security holes, especially if
  the script language is reflexive, generating static pages can't
  introduce this kind of security hole.
</p>

<p>
  The second good point is that it saves bandwidth. Let me explain.
  If you use dynamic generation, the default behaviour is to send as a
  response to each request a newly generated page. Well, if that page
  is different each time, you don't have a choice but use a dynamic
  system. But if you keep sending the same page, you will have to
  check at the generator level if the page is the same or not as last
  time, and then send the good http header.
  And if you use static pages, you don't have to deal with that.
</p>

<p>
  The third good point is that the static pages are generated! That
  means that you don't entirely write them by hand. Most of the
  rendering job must be done by scripts, which is the purpose of
  BashGXD. BashGXD allows you to generate the pages only when you need
  to (re)generate them.
</p>

<p>
  A forth good thing is that staic pages don't need to be generated
  each time they are asked. If you use PHP or another dynamic system,
  and want to simulate this, you handle caches so that pages are
  partially static and take less generation time... So you save time
  and CPU time... 
</p>

<p>
  Okay now one bad point: today it's not possible to make a good web
  site without dynamic treatments of requests. It's totally necessary
  to use CGI applications (which can be in php or perl or other, it
  doesn't matter) to handle the data submitted by the visitors.
  So BashGXD will soon integrate some dynamic stuff... :-/
  (actually there is already a little bit of that but it was done
  specifically, so it can be used for BashGXD as it)
</p>

<p>
  Another bad point: you need to know XHTML (very) well, or at least
  be ready to learn it, because it's unusable if you don't want to
  write in XHTML. Even if it's really quite easy to use to me (as I
  designed the system), it may be really hard to someone that doesn't
  deal with Makefiles, and bash. About the use of Objective Caml, for
  the moment it's only to write external generic programs, so it's not
  necessary to know Caml at all.  
</p>

<p>
  A third bad point is that it's really not WYSIWYG at all. Well it's
  not a bad point to every one. So while people are using their brains
  to make easy-to-use-WYSIWYG editors, I am designing a system that
  has nothing to do with such systems. Hey WYSIWYG tools are often
  very useful and I do use them. But not for websites, it's too "hard"
  to handle them "efficiently". I don't want to use my mouse to write
  a post in a blog: I just want to write the text and ask for it to be
  published, not clicking a thousand times before I get to the right
  page to finally write the post with the risk it disappears because
  the web browser has crashed. So I use
  <a href="http://homepage.mac.com/zenitani/emacs-e.html">(Carbon)
  Emacs</a>
  because it's an efficient text editor. Of course BashGXD doesn't
  depend on Emacs. You can use VIm as well, or gedit, kate, kwrite,
  and even Microsoft Notepad! It doesn't matter as long as you have
  make and bash (and Objective Caml...) (and several gnu utils, such
  as sed).
  Well, it doesn't mean that I haven't used nor won't use WYSIWYG
  tools to build web sites. It just mean that I won't do it for my own
  web site...
</p>

<p>
  Now that I've built several pages with this "tool", I can tell that
  it's quite efficient for what I do, except for the
  <a href="http://philippewang.info//blog/index.xml">blog</a>: it's a little bit "slow".
  So in December 2006, I started adding some 
  <a href="http://ocaml.org/">Objective Caml</a>
  programs, and that adds one more dependency.
  Soon I'll add some data handlers...
</p>


<p>
  For the moment, there is no JavaScript...
  Nothing prevents me to include some JavaScript in my web site, but
  myself. Right now I don't want to use JavaScript. Maybe my mind will
  change... 

</p>





  
</div>
      ]]></description>
    </item>
  </channel>
</rss>

