has
Posts: 15
Nickname: has
Registered: Nov, 2004
|
|
Re: Django vs. Cheetah: 1-0
|
Posted: Feb 4, 2006 10:02 AM
|
|
> I still
> believe that a DOM-style approach would be much more
> painful, in part *because* of the separation between HTML
> and presentation logic.
I'll say it now: there will always be some tradeoffs somewhere, whatever you do. Anyone who claims any of these systems is a free lunch is either naive or fibbing.
FWIW though, I originally built a full, working macro-style engine influenced by the classic systems like PHP and ASP, only to trash it a few months later and completely start over by conceiving, designing and implementing a DOM-style engine from first principles. Pretty painful, but no regrets.
> For example, I am displaying an object with a whole bunch
> of attributes. I'm still deciding which attributes are
> relevant to the user. Using Django I can simply add
> markup with variable references to the template.
> Generalizing from your itunes example right, I would have
> e to add new markup to the template, and then make a
> corresponding addition to the presentation logic in
> Python. This requires more context switching which is one
> of the major well-known sources of productivity slowdown.
If you mean you have to switch from one file to another during development more often, then yes. You have the same issue with Cocoa development, bouncing between drag-d-dropping objects in Interface Builder and typing source code in XCode.
The first counter-argument is that separating the two concerns allows you to use the best tools for developing each: Dreamweaver, FrontPage, HTMLTidy, etc. for one; vi, emacs, Eclipse, lint, etc. for the other.
The second is that, in practice, one tends to minimise those expensive context shifts anyway: first marking a whole bunch of template nodes in the HTML editor, then switching to the code editor to fill in the implementation one bit at a time. You can still test each new feature as you go; any template nodes that aren't yet "hooked up" simply don't do anything.
If anything, with a well-designed DOM-style system it should be much easier to test sections of the template in isolation. Your test harness can directly invoke whichever function manipulates the part of the template you're interested in, then render that portion for verification. You can temporarily stub out sections of code without affecting the markup structure.
Therefore, this separation not only allows you to work in your standard Python tools, it also lets you leverage your existing Python skills and techniques as well. The philosophy of reuse extends beyond just the templates themselves.
..
Furthermore, with a sufficiently flexible and introspective API, things can get very interesting: you can create separate libraries of add-on features, stuff like automatic interpolators that take a template node and a Model object and use key-value bindings to insert content automatically. Add-ons like that will reduce the amount of glue code you need to write between Model layer and template DOM for common tasks, improving productivity. And because it's all external add-ons, you're not bloating the original implementation with the increased maintenance costs and longer learning curve that feature creep causes.
BTW, this last bit is what interests me most about DOM-style engines: whereas macro-style territory has pretty much been done to death by now and I doubt there's much new ideas left to be had, the DOM-style approach still looks to offer plenty room for fresh investigation and experimentation. It's got a definite "but give a man a copy of Lisp..." vibe to it.
..
Finally, if you're still concerned that a DOM-style system may present a marketing problem for folks who can't yet handle abstraction or are just too set in their macro-munging ways, bear in mind that it is possible to implement a macro-style interface as a preprocessor on top of a DOM-style engine, both as a deliberately 'low-end' solution in itself and as a 'transitional bridge'. You can't do it the other way though.
...
> Also, all examples I've seen so far are changing the
> "content" of an element. However, in my sample app, I
> frequently have links whose value is (in part) derived
> from a variable. In Django I can write
>
> <a href="/user/{{username}}">View {{username}}'s info</a>.
>
>
> How do I do that using your system or PyMeld?
A few options.
1. You can specify the whole value in the controller code rather than the markup, e.g.:
infoLink.atts['href'] = os.path.join('/user', username)
2. You can insert a 'dummy' element as placeholder, e.g.
<a ...>View <span node="-con:username"/>'s info</a>
or:
<a ...>View <span node="-con:username">Joe Foo</span>'s info</a>
if you want it to add mockup values so it previews nicely. (Appending '-' to the 'con' directive tells the renderer to automatically omit the <span> and </span> tags on output.)
3. You can get the existing content, perform a string interpolation or substitution, then reinsert the result, e.g.:
<a ...>View %s's info</a>
infoLink.content = infoLink.content % username
Or any combination of the above.
HTH
|
|
Previous Topic
