On Jun 2, 2005, at 11:18 PM, Ian Bicking wrote:
We've talked about this slightly before, but I think now more than ever stan can be that DOM. I don't think it would be too much work; it would mostly require removing assumptions that other nevow modules are available. I think stan could be broken out of nevow and into a standalone thing by pulling these modules: nevow.stan nevow.tags nevow.loaders nevow.context And the package: nevow.flat I'm willing to do the work, and I'm willing to remove assumptions it makes and refactor things until they are clean. The module which would require the most work is nevow.context -- an internal rendering implementation detail that Nevow makes explicit but I would want to hide from non-Nevow users of stan. nevow.context was the first module of nevow to be written, and has a bunch of crufty bad�decisions that haven't yet been refactored out of existence. But I'd like to do it, and this would give me an excuse to.
nevow.loaders.htmlfile does a good job of parsing normal html. nevow.loaders.xmlfile parses strict XHTML and allows more tag tricks, but I think casual users won't notice the difference, especially for the purpose you desire.
HTML rather than XHTML? I'm curious what the motivation for this is, and if you know what the couple of rules would be. I think it wouldn't be too hard. Hmm, I guess the motivation for the previous point is the next point?
stan is whitespace in, whitespace out. It keeps comments. It uses a dict for attributes, but this could be changed easily. nevow.url uses a list of tuples, because order is actually important there. This means it needs to have a different API; it has .add() as well as .replace(). Add adds a new key value pair, even if the key is already present; replace finds any existing keys and puts a new value in it's place, preserving the original order.
This is really, really, really a bad idea. While browsers claim to be whitespace agnostic, they make a huge rendering distinction between "no whitespace present" and "any whitespace present". Nevow preserves any whitespace that was originally in your template, but when generating tags from Python it can't, so it doesn't. That said, it is something I have considered writing before. Woven had it. I found it to be more trouble than it is worth. I think it should be added, but you should have to go out of your way to turn it on, and it should be off by default.
A great idea. It would be trivial to add file/line/column information and populate it differently in each of the loaders. I love it, I'm going to go do it right now.
Nevow was designed as an optimization of woven, and as a result is pretty fast. It has a two-pass system where one pass is taken when the template is initially loaded (once per template per process, assuming the template doesn't change on disk) and non-important nodes are optimized out of what actually happens at render time. There's also a bunch of low hanging optimization work in nevow.context. When I originally wrote it, I was worried about people mutating things so I made lots of copies. In the meantime, it turns out that the "correct" style of using it is to not mutate things but be somewhat functional and side effect free. Since mutating is still nice for some things, the objects which get mutated get copied before you get called to mutate them. But, a lot, lot more copying currently happens than is necessary. Yet another thing I have been meaning to do but haven't gotten around to, that this might encourage me to do.
Agreed. dp |
_______________________________________________ Web-SIG mailing list [email protected] Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
