Thread: RE: [SQLObject] SQLObject & Webware FormKit Integration
SQLObject is a Python ORM.
Brought to you by:
ianbicking,
phd
From: Ian S. <Ian...@et...> - 2004-01-12 21:38:32
|
Ian Bicking wrote: >> Well, I've been thinking about it of course, especially with respect to FormEncode (http://formencode.org). But it's something that I keep putting aside. << Thanks for the update on this and on the Archetypes & PyProtocols links. = They make for interesting reading. Is PyProtocols stable? I keep looking = at PEAK but the fact that the Tutorial PDF runs out at Page 25 just as = it starts to get interesting worries me. Its been that way for a loooong = time. Adaptation looks very promising. I just wish it didn't require all that = extra typing.... -----Original Message----- From: Ian Bicking [mailto:ia...@co...] Sent: Monday, January 12, 2004 8:30 AM To: Ian Sparks Cc: Sqlobject-Discuss@Lists. Sourceforge. Net (E-mail) Subject: Re: [SQLObject] SQLObject & Webware FormKit Integration On Mon, 2004-01-12 at 11:29, Ian Sparks wrote: > Has anyone given any more thought to SO -> Webware (esp Fun/FormKit) = integration? Well, I've been thinking about it of course, especially with respect to FormEncode (http://formencode.org). But it's something that I keep putting aside. With FormEncode, the validation schema would be created through adaptation, probably adapting the object or class (e.g., adapt the object to edit it, adapt the class to create a form for a new object).=20 The adaptation uses PyProtocols (http://peak.telecommunity.com/PyProtocols.html), though it would be familiar to Zope 3 developers. Something slightly less ambitious would probably be pretty easy to make right now. Using FormEncode isn't *very* far off, but I know I still get confused thinking about how the API should work, even when the pieces are ready to be put together. Really, I might have everything in place now, I just haven't tried to actually put it all together. I think most of the stuff I've worked on is in FormEncode's CVS repository. I've submitted a proposal about FormEncode for PyCon, so if that goes through I will probably be doing a lot of work on FormEncode (and SO integration) to get things polished to show it off. (FWIW, I think there's also some considerable overlap with the Archetypes project that Sidnei's working on) Ian |
From: Ian S. <Ian...@et...> - 2004-01-13 14:03:30
|
>> Adaptation looks very promising. I just wish it didn't require all = that extra typing.... Ian Bicking wrote (in response to the above)... >It should usually take less typing. You need only adapt at the last >moment, so you pass objects through based on the expectation they will >later be adapted if necessary. =20 I really meant that Interfaces mean its no longer enough to create a = class. I now need to create an Interface "prototype" and then classes = that implement that Interface. One of the great things about Python (for = me) is that you can say "Does it quack? Ok, lets assume its a duck" = without a lot of rigmarole. I'm probably showing my (deep) ignorance but = the whole Interfaces thing seems to be putting the rigmarole back in. Its kind of a comfort that the very bright people involved with Twisted = and Zope are making big use of Interfaces but at the same time these = projects are noted for their use of python to create things that do not = appear to be very pythonic (Aquisition? reliance on Callbacks?) >But I'm still getting used to it as a paradigm -- I think it will be a >very big deal, but I don't think it's widely understood, even by those >(like me) that are using it. Which is probably why I should do more research into this instead of = whining about having to do a bit more typing.... -----Original Message----- From: Ian Bicking [mailto:ia...@co...] Sent: Monday, January 12, 2004 11:16 AM To: Ian Sparks Cc: Sqlobject-Discuss@Lists. Sourceforge. Net (E-mail) Subject: RE: [SQLObject] SQLObject & Webware FormKit Integration On Mon, 2004-01-12 at 15:38, Ian Sparks wrote: > Thanks for the update on this and on the Archetypes & PyProtocols = links. They make=20 > for interesting reading. Is PyProtocols stable?=20 Yes, I think it's pretty stable. It's a core part of PEAK, and it's fairly mature. I'm sure Zope 3 and Twisted's adaptation are fairly mature too (again because they are fundamental building blocks for those platforms), but PyProtocols was the only one with decent documentation (and isolated distribution). > Adaptation looks very promising. I just wish it didn't require all = that extra typing.... It should usually take less typing. You need only adapt at the last moment, so you pass objects through based on the expectation they will later be adapted if necessary. In FormEncode there's the toPython and fromPython functions, which actually do the necessary adaptation themselves then call the appropriate method, so there's really no extra typing at all. But I'm still getting used to it as a paradigm -- I think it will be a very big deal, but I don't think it's widely understood, even by those (like me) that are using it. Well, I understand the mechanism, but that's different from having an intuition on how it should best be used. And I don't feel like there's many other languages that provide a model for how it might work -- it's really very novel, at least from my experience. Ian |
From: David B. <db...@fi...> - 2004-01-13 16:50:16
|
"Ian Sparks" <Ian...@et...> writes: > I really meant that Interfaces mean its no longer enough to create a > class. I now need to create an Interface "prototype" and then > classes that implement that Interface. One of the great things about > Python (for me) is that you can say "Does it quack? Ok, lets assume > its a duck" without a lot of rigmarole. I'm probably showing my > (deep) ignorance but the whole Interfaces thing seems to be putting > the rigmarole back in. What I find attractive about PyProtocols (and probably the others) is that you still get the "Does it quack?" approach, but you do so with a single adaptation call ("adapt" with PyProtocols"). And that's an often discussed topic in the Python arena - just how do you ask "Does it quack?" So you don't have to attempt random calls into the object. When you couple that with the fact that you can externally adapt or register that an object supports an interface, and it's really a very dynamic way to handle well-defined interfaces. The typing really isn't that much. Yes, you need to define an interface, but to be honest, you should be doing that anyway as a way of documenting the "duck" that your object expects. In terms of the classes itself, if you use the abstract-base-case approach to your interface, just inherit from it for your class. Or, for any class, just add an "advise(instancesProvide=[XXXX]))" call in your class to say it provides interface XXXX. Or, you can indicate your object supports an interface from the "outside" without ever touching your object code (or register an adapter to take an existing object and wrap it to conform to the interface). And in the end, nothing is hard-enforced. Any class can claim to support an interface without really doing so, and you can be in precisely the same state as now as if you hadn't claimed that fact but just used the object. -- David |
From: Ian B. <ia...@co...> - 2004-01-13 17:48:52
|
On Tue, 2004-01-13 at 10:43, David Bolen wrote: > "Ian Sparks" <Ian...@et...> writes: > > I really meant that Interfaces mean its no longer enough to create a > > class. I now need to create an Interface "prototype" and then > > classes that implement that Interface. One of the great things about > > Python (for me) is that you can say "Does it quack? Ok, lets assume > > its a duck" without a lot of rigmarole. I'm probably showing my > > (deep) ignorance but the whole Interfaces thing seems to be putting > > the rigmarole back in. > > What I find attractive about PyProtocols (and probably the others) is > that you still get the "Does it quack?" approach, but you do so with a > single adaptation call ("adapt" with PyProtocols"). And that's an > often discussed topic in the Python arena - just how do you ask "Does > it quack?" Interfaces answer "Does it quack" -- adaptation goes a bit further, saying "Give me something that quacks". Interfaces are like the old, boring type declarations. They might save you from a few bugs, but they don't really give you anything. Adaptation adds real power. It formalizes something we've all been doing in various ad hoc manners for a long time. It's also an alternative to many kinds of traversal -- though where to draw that line (between doing traversal via attribute access vs. adaptation) I haven't yet figured out. > So you don't have to attempt random calls into the object. When you > couple that with the fact that you can externally adapt or register > that an object supports an interface, and it's really a very dynamic > way to handle well-defined interfaces. > > The typing really isn't that much. Yes, you need to define an > interface, but to be honest, you should be doing that anyway as a way > of documenting the "duck" that your object expects. And if you are just writing an "application" (vs. a framework), you probably won't define any interfaces at all. Certainly to use FormEncode you don't need to define any interface -- it only uses interfaces that are already defined (IValidator and IField). In fact, all the adaptation and interfaces are mostly hidden from you. It's really there for when you want to fit different frameworks together, like SQLObject and FormEncode. Ian |
From: David B. <db...@fi...> - 2004-01-13 19:03:23
|
Ian Bicking <ia...@co...> writes: > On Tue, 2004-01-13 at 10:43, David Bolen wrote: (...) > > What I find attractive about PyProtocols (and probably the others) is > > that you still get the "Does it quack?" approach, but you do so with a > > single adaptation call ("adapt" with PyProtocols"). And that's an > > often discussed topic in the Python arena - just how do you ask "Does > > it quack?" > > Interfaces answer "Does it quack" -- adaptation goes a bit further, > saying "Give me something that quacks". Definitely - I oversimplified a bit much. I'd probably rephrase that instead of asking "Does it quack?" the adaption says "Could you quack?" :-) > > The typing really isn't that much. Yes, you need to define an > > interface, but to be honest, you should be doing that anyway as a way > > of documenting the "duck" that your object expects. > > And if you are just writing an "application" (vs. a framework), you > probably won't define any interfaces at all. Depending on your definition of "application" I'd agree. To this point much of my own use of PyProtocols has been within our own application, but at the layer of core components within the application (not really a framework, just central component definitions). These components are expected to interface in various ways over time, so while I don't have the need to define many adapters beyond the interfaces yet, I can envision using that facility down the road. So I'd expect that most applications would at least have an opportunity to use interface definitions at some level, unless they really are just a thin glue layer above other libraries of objects. -- David |
From: Ian B. <ia...@co...> - 2004-01-12 22:14:46
|
On Mon, 2004-01-12 at 15:38, Ian Sparks wrote: > Thanks for the update on this and on the Archetypes & PyProtocols links. They make > for interesting reading. Is PyProtocols stable? Yes, I think it's pretty stable. It's a core part of PEAK, and it's fairly mature. I'm sure Zope 3 and Twisted's adaptation are fairly mature too (again because they are fundamental building blocks for those platforms), but PyProtocols was the only one with decent documentation (and isolated distribution). > Adaptation looks very promising. I just wish it didn't require all that extra typing.... It should usually take less typing. You need only adapt at the last moment, so you pass objects through based on the expectation they will later be adapted if necessary. In FormEncode there's the toPython and fromPython functions, which actually do the necessary adaptation themselves then call the appropriate method, so there's really no extra typing at all. But I'm still getting used to it as a paradigm -- I think it will be a very big deal, but I don't think it's widely understood, even by those (like me) that are using it. Well, I understand the mechanism, but that's different from having an intuition on how it should best be used. And I don't feel like there's many other languages that provide a model for how it might work -- it's really very novel, at least from my experience. Ian |