Web tool kit : pro - cons ?

Discussion in 'Python' started by vincent_delft, Jul 26, 2003.

  1. I'm looking for a Web Tool kit to build web pages with the following
    criteria (in priority order) :
    - easy to use, develop (reuseability of code, ...)
    - flexible (ideally should run with Python CGIHTTPServer and/or with Apache
    (with or wihout mod_python)
    - possibility to have load balancing and/or caching (for very high loaded
    web pages)

    I've founded lot of tools ...

    I've read the doc of most of them, I've tested some of them.
    But, is there anyone "experienced user" who can give the pro-cons for each
    of those solutions ? (or propose an another)

    Is there a site who list the main charateristics of each of those Web tool
    kit ?

    Thanks


    Zope (www.zope.org),
    SkunkWeb (http://skunkweb.sourceforge.net/),
    Quixote (http://www.mems-exchange.org/software/quixote/),
    Twisted (http://www.twistedmatrix.com/)
    Albatross (http://www.object-craft.com.au/projects/albatross/)
    Cherrypy (...)
    pwo (...)
    ....
     
    vincent_delft, Jul 26, 2003
    #1
    1. Advertising

  2. Irmen de Jong, Jul 26, 2003
    #2
    1. Advertising

  3. Irmen de Jong wrote:

    > vincent_delft wrote:
    >
    >> Is there a site who list the main charateristics of each of those Web
    >> tool kit ?

    >
    > Check out http://www.python.org/cgi-bin/moinmoin/WebProgramming
    >
    > --Irmen de Jong



    Waouuuww...

    So many different tools ....

    Can I get some "guidelines" ?
    My needs are :
    - Build pages via templates (easy to split content and layout)
    - My pages will be defined with "boxes". I would like to have a tool that
    can manage easely such "object".
    - I will use PostgreSQL as backend.
    - possibility to build very simple web site (<10 users) but big web sites
    too ( > 1000 users). So I don't need a Apache/mod_Python, ... for small web
    sites. CGIHTTPserver is enough. But CGIHTTPServer will not be able to
    manage very high load.
     
    vincent_delft, Jul 27, 2003
    #3
  4. vincent_delft wrote:
    > My needs are :
    > - Build pages via templates (easy to split content and layout)


    ZPT seems to be a good option there.

    > - My pages will be defined with "boxes". I would like to have a tool that
    > can manage easely such "object".


    You mean a WYSIWYG web development IDE for Python? I don't think there's
    such a thing.

    > - I will use PostgreSQL as backend.


    I'd suggest you use pyPgSQL or psycopg for this. I'm a little biased
    towards pyPgSQL, being one of it's developers ;-)

    -- Gerhard
     
    =?ISO-8859-1?Q?Gerhard_H=E4ring?=, Jul 27, 2003
    #4
  5. vincent_delft fed this fish to the penguins on Saturday 26 July 2003
    04:01 pm:

    > - Build pages via templates (easy to split content and layout)
    > - My pages will be defined with "boxes". I would like to have a tool
    > that can manage easely such "object".
    > - I will use PostgreSQL as backend.
    > - possibility to build very simple web site (<10 users) but big web
    > sites too ( > 1000 users). So I don't need a Apache/mod_Python, ...
    > for small web sites. CGIHTTPserver is enough. But CGIHTTPServer will
    > not be able to manage very high load.
    >

    Have you considered Zope?

    (And I am NOT an expert in it at all... Merely a dabbler when I can
    find time)

    --
    > ============================================================== <
    > | Wulfraed Dennis Lee Bieber KD6MOG <
    > | Bestiaria Support Staff <
    > ============================================================== <
    > Bestiaria Home Page: http://www.beastie.dm.net/ <
    > Home Page: http://www.dm.net/~wulfraed/ <
     
    Dennis Lee Bieber, Jul 27, 2003
    #5
  6. vincent_delft

    yaipa h. Guest

    Vincent,

    You don't list Webware oddly enough. I have been using it with the
    Cheetah templating engine. Works fine, with good support.

    Python 9 White Paper on Webware
    --------------------------------
    http://www.python9.org/p9-cdrom/index.htm

    Cheetah dev page
    ----------------
    http://www.cheetahtemplate.org/

    Cheers,

    --Alan


    vincent_delft <> wrote in message news:<3f23003f$0$266$>...
    > I'm looking for a Web Tool kit to build web pages with the following
    > criteria (in priority order) :
    > - easy to use, develop (reuseability of code, ...)
    > - flexible (ideally should run with Python CGIHTTPServer and/or with Apache
    > (with or wihout mod_python)
    > - possibility to have load balancing and/or caching (for very high loaded
    > web pages)
    >
    > I've founded lot of tools ...
    >
    > I've read the doc of most of them, I've tested some of them.
    > But, is there anyone "experienced user" who can give the pro-cons for each
    > of those solutions ? (or propose an another)
    >
    > Is there a site who list the main charateristics of each of those Web tool
    > kit ?
    >
    > Thanks
    >
    >
    > Zope (www.zope.org),
    > SkunkWeb (http://skunkweb.sourceforge.net/),
    > Quixote (http://www.mems-exchange.org/software/quixote/),
    > Twisted (http://www.twistedmatrix.com/)
    > Albatross (http://www.object-craft.com.au/projects/albatross/)
    > Cherrypy (...)
    > pwo (...)
    > ...
     
    yaipa h., Jul 27, 2003
    #6
  7. vincent_delft

    Ian Bicking Guest

    On Sun, 2003-07-27 at 05:58, vincent_delft wrote:
    > >> - My pages will be defined with "boxes". I would like to have a tool
    > >> that can manage easely such "object".

    > >
    > > You mean a WYSIWYG web development IDE for Python? I don't think there's
    > > such a thing.
    > >

    > No. Each part of the web page will be "boxes". I would like to be very
    > flexible and display "dynamically" some selected boxes.
    > For example the same page (url) will not display the same boxes if you are
    > administrator, maintener or simple viewer.
    > An another example will be to have possibility to re-use existing boxes. If
    > I have a boxes displaying the last 5 news from Slashdot, I don't want to
    > re-write it each time I need a new bacground color (for example). My Idea
    > is to use those "boxes" like we use classes : if you need some modification
    > you subclass it on the rest remains the same.


    You might want to look at Cheetah, where templates are mapped to Python
    classes. This allows subclassing of templates, defining methods (e.g.,
    a header method), and of course nesting templates.

    Ian
     
    Ian Bicking, Jul 27, 2003
    #7
  8. vincent_delft

    Remi Delon Guest

    > I've read the doc of most of them, I've tested some of them.
    > But, is there anyone "experienced user" who can give the pro-cons for each
    > of those solutions ? (or propose an another)


    The problem is that most people are "experienced users" with only a few of
    the frameworks.
    In order to find out all the little caveats of a perticular framework, one
    has to use it for quite a big project (I'd say at least 6 months).
    I don't think any of us have developed such big projects with more than,
    say, 2 or 3 python frameworks. (in my case, I've only used Zope and CherryPy
    for "real" applications. I've only "played" with the other frameworks).
    This is why it is hard to have one person make a comparison of all the
    frameworks ...

    Having said that, I think that CherryPy definitely meets your
    requirements... (sorry, I couldn't help saying it :)))

    Remi.
    ----------------------
    Specialized python hosting: http://www.python-hosting.com
    CherryPy application server: http://www.cherrypy.org
    Free CherryPy hosting: http://www.freecherrypy.org
    ----------------------
     
    Remi Delon, Jul 28, 2003
    #8
  9. vincent_delft

    Jane Doe Guest

    On Mon, 28 Jul 2003 10:59:05 +0100, "Remi Delon" <>
    wrote:
    >Having said that, I think that CherryPy definitely meets your
    >requirements... (sorry, I couldn't help saying it :)))


    I second that. CherryPy is the Python framework that was the easiest
    to grasp as a newbie.

    Other frameworks that look similar to CherryPy (ie. URLs are actually
    calls to classes and methods) are WebWare + Cheetah, Skunkweb. If
    someone knows of others, I'm all ears :)

    JD.
     
    Jane Doe, Jul 29, 2003
    #9
  10. David Jeske <> wrote in message news:<>...
    > If you are not wedded to Zope for your applications, you may want to
    > look at Clearsilver. (http://www.clearsilver.net) It is a very mature
    > system which was developed at eGroups.com, and today is in use on
    > high-performance sites such as Yahoo! Groups and
    > wunderground.com. Clearsilver includes a full CGI kit which handles
    > form variables, cookies, etc. It also includes a PythonObject<->RDBMS
    > mapping system (MySQL only today, no pgsql yet), and a transparent
    > translation string extraction system. It is not a "server environment"
    > like Zope, and in fact you can use it inside of your server of choice
    > (Apache, Boa, IIS, Zope, etc).
    >
    > I find ZPT's model for replacement hard to work with, because it tries
    > to fit into the xml document namespace. From the ZPT documentation
    > here:
    >
    > http://www.zope.org/Documentation/Books/ZopeBook/current/ZPT.stx
    >
    > This example:
    >
    > <title tal:content="here/title">Page Title</title>
    >
    > Illustrates how ZPT is making it's "tag" (i.e. tal:content) fit in as
    > an attribute defined by a new XML namespace. The problem is, this
    > constrains where you can use template commands to construct the
    > document. Clearsilver uses a model more like PHP where the tags exist
    > as items outside of the XML document parsing. This has the drawback
    > that your template document is not a valid XML document, but it has
    > the advantage that you can put the tags anywhere.
    >
    > For example, in clearsilver, you can construct URLS using sequences of
    > template commands, even looping. Here is a small example (whitespace
    > added for readability):
    >
    > <a href="/url?
    > <?cs each:p=CGI.Params ?>
    > <?cs var:p.name ?>=<?cs var:p.value ?>&
    > <?cs /each ?>"
    > >a_link</a>


    I love Zope's page templates. I do have to admit that I worked at
    Zope Corporation since before Zope was Principia, but am now out in
    the wild stressful world on my own again. But I grew to *hate* the
    above style of templating, which Zope's older model (DTML) follows.
    I've been using DTML since early 1997 and when web applications were
    still fairly simple, I think it was a nice system (DTML was also
    simpler then and focused more on being a templating language than on
    being a programming language, which is what made DTML particularly
    painful on Zope in later years before ZPT).

    I work with some very talented designers. It used to be that they
    would give us (the developers) their designs and we'd rip them to
    shreds and they could never touch them again. Because now they were
    in little bits and pieces and stuffed full of tags-within-tags, with
    silly things like 'standard_html_header' and 'standard_html_footer'
    (never really fitting a technical definition of header once complex
    designs enter the equation) making it very painful to apply what they
    would thing were rudimentary design changes.

    Not so with ZPT. It's not a holy grail, but it's pretty close. Most
    of the time, the designers can tweak the site - even in production -
    without upsetting the natural order of things. Given that they're
    full time graphic designers (sortof a 'sibling' company. they also do
    a lot of large volume print material, etc) and not programmers, this
    is pretty impressive. They are smart enough to watch out for the
    dynamic parts. But we've had very few issues since moving to it.

    What I personally like about ZPT is the fact that it feels natural
    within the HTML/XML environment. It may have taken some getting used
    to initially, but I find it very natural. And it's extra nice because
    I can work in smart text editors like XEmacs or BBEdit, or work in
    GoLive (very nice when used with its WebDAV browser) and can view the
    whole page - including the 'standard header/footer' (usually supplied
    by a standard full page macro, which in itself is very easy to modify
    and edit because it's a single full page and not broken up into chunks
    like header/footer/sidebar - VERY nice. My life is so much better for
    this fact alone!). Sometimes adding a dynamic element to a tag from
    visual mode means just popping up the quick-tag editor and adding in a
    TAL statement. Close the tag editor, and the page is still intact.

    You can even do complex things like the following::

    <tr tal:attributes="class python:test(repeat['item'].even(), 'even',
    'odd')">
    ....
    </tr>

    and have visual editors, or even helpful hilighting editors (BBEdit,
    XEmacs, etc) not be affected by it. Compared to::

    <tr class="<!--#if even-->even<!--#else-->odd<!--#/if-->">

    or this, if you only want the class attribute written on even rows
    (and how we come up with the variable 'even' is being left to the
    imagination here):

    <tr <!--#if even-->class="even"<!--#/if-->>

    most editors just die right here - especially visual ones. In TAL,
    you could do:

    <tr tal:attributes="class python:test(repeat['item'].even(), 'even',
    nothing)">

    and most editors would be fine. (Note: 'nothing' is that ZPT
    equivalent of 'None'. The core components of ZPT (TAL, TALES, METAL)
    were written as specs first, with the idea/hope that other programming
    languages could implement them as well, hence 'nothing'. 'None' could
    have been used in its place just as easily in this situation). Is it
    more verbose? More typing? At times, yes. But there's a nice
    explicit nature about it, and many old Zoper's have learned the hard
    way that explicit is almost always better than implicit (DTML had so
    many implicit actions going on that in the end - even after years of
    use - there were always new surprises waiting in the wings. And
    Radiohead says it best - 'no alarms and no surprises').

    Anyways - this is just my personal experience. But I find that
    (generally) with ZPT, I'm writing better HTML and have a more
    maintainable web site. It's different, but I think it's a good thing.
    I'm happy to get away from Server Side Include and Processing
    Instruction style syntaxes.

    To get back to your example::
    > <a href="/url?
    > <?cs each:p=CGI.Params ?>
    > <?cs var:p.name ?>=<?cs var:p.value ?>&
    > <?cs /each ?>"
    > >a_link</a>


    ZPT (at least in Zope) has a helpful module called ZTUtils that
    contains a lot of nice helper functions for building query strings
    (which I'm increasingly convinced should never be constructed by hand
    unless absolutely necessary, due to issues with URL and/or HTML
    quoting), hidden values, etc. Assuming that CGI.Params is a
    dictionary/mapping, once could do:

    <a tal:define="query python:modules['ZTUtils'].make_query(CGI.Params)"
    tal:attributes="href string:/url?${query}"
    >a_link</a>


    ``make_query`` (which can also use keyword arguments) is extra nice
    because it automatically URL quotes all of the values for the query
    string. This is EXTRA EXTRA nice when passing full LDAP distinguished
    names in a query string, for example.

    > > No. Each part of the web page will be "boxes". I would like to be very
    > > flexible and display "dynamically" some selected boxes.
    > > For example the same page (url) will not display the same boxes if you are
    > > administrator, maintener or simple viewer.

    >
    > This should be pretty easy in most template systems worth their
    > weight.
    >
    > > An another example will be to have possibility to re-use existing boxes. If
    > > I have a boxes displaying the last 5 news from Slashdot, I don't want to
    > > re-write it each time I need a new bacground color (for example). My Idea
    > > is to use those "boxes" like we use classes : if you need some modification
    > > you subclass it on the rest remains the same.

    >
    > Clearsilver has a macro definition facility for doing just this. You
    > can supply arguments to macros, and even call macros recursively. Here
    > is a simple example:
    >
    > <?cs def:makelink(url,title,text) ?>
    > <a href="<?cs var:url ?>"
    > title="<?cs var:title ?>"
    > ><?cs var:text ?></a>

    > <?cs /def ?>
    >
    > <?cs call:makelink("http://www.python.org","Python.org website","Python.org") ?>
    >
    > The paramaters can be any expressions, including constructed strings,
    > or data from your dynamic CGI. For example:
    >
    > <?cs call:makelink("http://" + CGI.host + "/" + CGI.script,"title","link text") ?>
    >
    > As always, there are lots of systems out there, and YMMV.


    Macros do make life happy. :) Or at least, happier. ZPT macros
    (METAL) do things a little differently, but I think it works out for
    the best. To the best of my knowledge, ZPT compilation/rendering
    occurs in two steps - first, macros are expanded (METAL statements are
    executed) into the template like they were there in the template all
    along, and then all of the TAL statements (including ones that were in
    the macros) get executed. One thing this allows, when used in a
    dynamic environment like Zope, is the ability to have the macros be
    expanded at edit time (optionally, of course). When using a full-page
    macro, you can add a new ZPT page, fill it in like this::

    <html metal:use-macro="here/standard_template.pt/macros/page">
    <body>
    <div id="main" metal:fill-slot="body">
    <h3>The body of my new page template</h3>
    </div>
    </body>
    </html>

    Turn on 'expand macros', and the whole macro 'page' defined in the
    page template 'standard_template.pt' gets expanded. Macros define
    'slots' which clients of the macros can choose to fill in. Nicely, if
    you don't fill a slot specified by the macro, its defaults are filled
    in and you can see where the slots are by looking for the 'metal:slot'
    attributes. The above mentioned macro might contain a slot called
    'local_js' and put it on a <script> tag:

    <script type="text/javascript" metal:slot="local_js"><!--
    // local javascript for this page, if needed
    --></script>

    You can use it if desired, by changing 'metal:slot' to
    'metal:fill-slot' and add Javascript to the head of the page - all
    without requiring changing the header or having to have the page
    broken up into statements like:

    <!--#var early_head-->
    <script type="text/javascript" ><!--
    // my local javascript
    --></script>
    <!--#var close_head-->
    <!--#var body_header-->
    ....
    ....
    ....

    Which I've had to do and maintain so many times. I'm not sure when it
    happened - but at some point, this all got to be unmanageable. It's
    easy for situations like an intranet or basic web application where
    you're in control, but when you're on the east coast dealing with a
    west coast designer who dramatically changes layout every day - it
    does grow untenable.

    But I've long been of the personal opinion that HTML and code don't
    mix. I felt that way ever since I started using CGI and wrote my own
    little dynamic web system (pummel/pyml/avantpy) in '96 until I got
    turned on to Bobo (ancestor and still-the-heart of Zope). ZPT lets me
    see my templates as HTML, but still gives me the programmatic control
    I need. It's better than the old days when I'd look at my templates
    and see two conflicting languages that looked alike - an SGML-ish tag
    based templating language inside the SGML tag based HTML language.
    For some reason - using basic XML constructs (namespaced attributes)
    works so much better (for me) than using one set of tags within
    another set of tags.

    I think that's all aided by how relatively clean and simple they've
    managed to keep the core ZPT languages (TAL, METAL).

    But, as always, mileage will definitely vary.

    --
    Jeffrey P Shell
    http://toulouse.amber.org/

    "Tied you up, placed in tube"
    http://euc.cx/
     
    Jeffrey P Shell, Jul 30, 2003
    #10
  11. "Remi Delon" <> wrote in message news:<3f24f3f7@shknews01>...
    > The problem is that most people are "experienced users" with only a few of
    > the frameworks.
    > In order to find out all the little caveats of a perticular framework, one
    > has to use it for quite a big project (I'd say at least 6 months).
    > I don't think any of us have developed such big projects with more than,
    > say, 2 or 3 python frameworks. (in my case, I've only used Zope and CherryPy
    > for "real" applications. I've only "played" with the other frameworks).
    > This is why it is hard to have one person make a comparison of all the
    > frameworks ...


    That's very true. I've been using Zope, Principia, and Bobo almost
    back to their inception, and can't even grok other systems now. No
    offense to CherryPy or any of the other ones. But once you get
    proficient in a tool, it's hard to spend time with another when time
    is.. Well. What is time and who has it anyways? :)

    I've played with a couple of other Python web frameworks, I've even
    written my own (way back in the day when WebObjects was the only major
    app server on the market and *everything* else was home grown, and
    Java was still a cute way to add animation to web pages ;). But aside
    from the big jump to learning Zope 3 - I know I don't see any time in
    my future for doing a serious (ie - more than 'hello world' or
    'guestbook') evaluation of anything else. :\.

    In response to the original question - things that I would use when
    evaluating kits today is community size, maturity, etc. There are a
    lot of "cool little idea" web kits that never reach completion, or
    anything close to it (again - having written one, I know). Some
    projects have been around for a while and have yet to reach a '1.0'
    milestone. Some of those may just be reaching for perfection. Others
    are left to languish while the core developers have to work for a
    living, or find other solutions. Others may be in a state of 'yeah,
    the current version is good enough', but a real 1.0 release never
    quite seems to get made. For the past few years, I've made the SCM
    decision for myself to never run on beta software, and seldom use
    pre-1.0 software, no matter how good it may be, because we've got
    dependability requirements from customers that we have to ensure are
    met. And software that looks immature generally gets ranked low on
    the list of evaluations. (of course, having a low quality 1.0 release
    is not a good idea either ;)

    Quixote and CherryPy both deserve attention for their templating
    systems. I like what I've seen of each more than the many variants of
    "Python Server Pages" out there that try to embed Python in HTML
    (Python's block structure just makes this already messy style
    messier).

    Database Abstraction is another key issue. Zope gets points here not
    only for the built in ZODB database, but for SQL Methods / Database
    Adapters. There is nothing in Zope that is tied to Postgres, MySQL,
    Oracle, Sybase, SQLite, etc. Yet it's always been able to use any of
    them since before it was Zope. There's just a nice simple abstraction
    layer that one seldom has to think about. Other tools try the O-R
    mapping route for abstraction with varying degrees of success.
    SkunkWeb has PyDO, WebWare has one (I can't remember its name right
    now). Zope's model is nice because it's not intrinsic to Zope that
    you use SQL - it's just a nice model to plug into if you need it, when
    you need it. I don't know how other toolkits stack up here. Some may
    just say "go find a Python adapter that works for you and do what you
    want with it", which seems to be as good of a way to go as any.

    Enterprise scalability could be another factor. SkunkWeb has
    aggressive caching and tight integration with Apache as one of its
    features for delivering dynamic chunks of content under high load.
    Zope has its built in transaction system, which makes database work
    nice. Database adapters and other objects can integrate themselves
    into this system to ensure that either everything succeeds and gets
    written, or everything fails and rolls back, and you're not stuck with
    some data in one database but none in another (it's only as infallible
    as the systems that support it. Thank gods for InnoDB in MySQL!).
    Transactions are automatic (but can be handled manually, if desired) -
    a web request begins a transaction, and a successful writing of the
    response commits it. Any exceptions raised abort it. This becomes
    one of those little subtle platform niceties that you forget about but
    are eternally grateful for. Usually ;). Other toolkits may vary - it
    depends on what itch they were initially trying to scratch when they
    started. The transaction stuff in Zope goes back to Bobo and the
    early BoboPOS (which became the ZODB) because of the work I assume
    Digital Creations was doing with databases. Having gone through the
    pain of half written text files generated by mediocre self-written CGI
    scripts, this became an early favorite feature :).

    In any case, this is just my evaluation list as it would stand today,
    given my experiences over the last couple of years. I don't know how
    rosy Zope would come up today if I were evaluating different
    frameworks under this criteria - I always think it would be nice to
    have time to really step back and evaluate some different options, if
    only to get a fresh perspective (kindof like taking some time to
    evaluate Ruby might give one a fresh perspective on programming
    Python). But - there's just no time in the schedule to justify such
    an undertaking, for better or for worse...
     
    Jeffrey P Shell, Jul 30, 2003
    #11
  12. vincent_delft

    Ian Bicking Guest

    On Wed, 2003-07-30 at 01:28, Jeffrey P Shell wrote:
    > Database Abstraction is another key issue. Zope gets points here not
    > only for the built in ZODB database, but for SQL Methods / Database
    > Adapters. There is nothing in Zope that is tied to Postgres, MySQL,
    > Oracle, Sybase, SQLite, etc. Yet it's always been able to use any of
    > them since before it was Zope. There's just a nice simple abstraction
    > layer that one seldom has to think about.


    Praising SQL Methods? Maybe I've been missing something, but SQL
    Methods seem really primitive to me, certainly worse than the DB API
    (though I suppose they preceded the DB API). The transaction stuff is
    convenient -- if sometimes mysterious (like so many Zope things). But
    it's not solving a terribly difficult problem.

    > Other tools try the O-R
    > mapping route for abstraction with varying degrees of success.
    > SkunkWeb has PyDO, Webware has one (I can't remember its name right
    > now). Zope's model is nice because it's not intrinsic to Zope that
    > you use SQL - it's just a nice model to plug into if you need it, when
    > you need it. I don't know how other toolkits stack up here. Some may
    > just say "go find a Python adapter that works for you and do what you
    > want with it", which seems to be as good of a way to go as any.


    PyDO and MiddleKit (Webware's) are both independent of their frameworks
    (it's kind of unfortunate that they appear to be tied, though), as are
    the other ORMs (like my SQLObject). All three provide something
    approximating business objects built around database rows.

    My impression of Zope's SQL Methods is that they encourage distinctly
    un-OO style of programming, and instead everything is done through a
    heap of ad hoc queries and eclectic query results. At least, that's the
    code I've encountered, and it's taken discipline to avoid doing the same
    thing -- maybe there are better ways to use SQL Methods than what I've
    been exposed to. (If so, it would be better if Good Zope Style was
    documented, not just learned through wisdom born of failure -- but I
    haven't found that sort of documentation for Zope yet).

    Ian
     
    Ian Bicking, Jul 30, 2003
    #12
  13. vincent_delft

    Jon Ribbens Guest

    In article <>, Jeffrey P Shell wrote:
    > I work with some very talented designers. It used to be that they
    > would give us (the developers) their designs and we'd rip them to
    > shreds and they could never touch them again. Because now they were
    > in little bits and pieces and stuffed full of tags-within-tags, with
    > silly things like 'standard_html_header' and 'standard_html_footer'
    > (never really fitting a technical definition of header once complex
    > designs enter the equation) making it very painful to apply what they
    > would thing were rudimentary design changes.


    jonpy works around this problem while also avoiding the limitations of
    XML. The templates contain no code at all except <!--wt:name-->
    "magic comments" and $$name$$ replacements. Both of these survive the
    files being mangled by HTML editors and keeping as much as possible
    out of the HTML file means that if you get given brand new
    from-scratch design it is still a quick job to 're-templatify' the new
    HTML.
     
    Jon Ribbens, Jul 30, 2003
    #13
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Learner
    Replies:
    3
    Views:
    3,908
    venkatmath
    Jul 12, 2008
  2. static cons v/s cons

    , Dec 7, 2008, in forum: C Programming
    Replies:
    5
    Views:
    456
    James Kuyper
    Dec 8, 2008
  3. Wayne Erfling
    Replies:
    0
    Views:
    340
    Wayne Erfling
    Nov 18, 2006
  4. Clement
    Replies:
    0
    Views:
    250
    Clement
    Nov 22, 2003
  5. Trans

    Pro/Cons of Load System

    Trans, Oct 27, 2008, in forum: Ruby
    Replies:
    0
    Views:
    77
    Trans
    Oct 27, 2008
Loading...

Share This Page