What people tend to overlook when they make the coupling argument is
the coupling they've already accepted between visual design and
the template code, and that this inevitably requires two people to
make changes: the graphic designer and the programmer.
DOM approaches should make it possible to break that coupling.
Also, as you've found in your meld3 experiments, you can further reduce the coupling between the template and the manipulation code by emphasizing IDs as *the* way to get at nodes (as opposed to something more flexible like ElementTree().which reduces the chance that template restructuring will require code changes. That's one thing that I think is an advantage
of the Meld family over some of the other DOM-like approaches - and that's also why I've been thinking that we maybe don't want to expose the entire Element API in meld3.
coupling...
Posted bychrismat
2006-02-06 04:48 PM
In the very small sample group of people that have given me feedback about meld3, I've found that it's enough just to not document "loudly" the fact that you can use the _ElementInterface API against nodes. This is in the docs, but people don't seem to read closely enough for it to register; they assume the API is only what's explicitly spelled out in README.txt. Because of this happy accident, I'm not sure it would be useful to take active steps to legislate prevention of the use of the _ElementInterface API as a result, because it's often pretty handy if you know exactly what you're doing (e.g. you promise not to whine about coupling once you do ;-)
I'd agree that if this is the tact that we take, the "attributes" method might go away (due to the need to use the class keyword a lot) in favor of manpulating self.attrib directly. Or not. ;-)
http://www.artima.com/forums/flat.jsp?forum=106&thread=146647&start=34&msRange=15
What people tend to overlook when they make the coupling argument is
the coupling they've already accepted between visual design and
the template code, and that this inevitably requires two people to
make changes: the graphic designer and the programmer.
DOM approaches should make it possible to break that coupling.
Also, as you've found in your meld3 experiments, you can further reduce the coupling between the template and the manipulation code by emphasizing IDs as *the* way to get at nodes (as opposed to something more flexible like ElementTree().which reduces the chance that template restructuring will require code changes. That's one thing that I think is an advantage
of the Meld family over some of the other DOM-like approaches - and that's also why I've been thinking that we maybe don't want to expose the entire Element API in meld3.
I'd agree that if this is the tact that we take, the "attributes" method might go away (due to the need to use the class keyword a lot) in favor of manpulating self.attrib directly. Or not. ;-)