| ChrisW | no, I meant havign to dropping crappy little .zcml files into etc/package-includes | 00:00 |
|---|---|---|
| ChrisW | thankfully, zope 3 is flexible so I can do it my way ;-) | 00:00 |
| ChrisW | and I would love to have the time to implement a .conf-based replacement for zcml | 00:00 |
| *** russf has quit IRC | 00:01 | |
| projekt01 | Chrisw, they are great, if you have a package downloaded with the correct SETUP.cfg, the setup.py will copy the right *-configure.zcml to the site-package folder | 00:01 |
| projekt01 | I didn't see a better way for a framework which is not the same as a custom project. | 00:02 |
| *** ChrisW_ has joined #zope3-dev | 00:06 | |
| *** MrTopf has quit IRC | 00:12 | |
| *** Aiste has quit IRC | 00:15 | |
| *** zbir has quit IRC | 00:16 | |
| *** ChrisW has quit IRC | 00:20 | |
| *** russf has joined #zope3-dev | 00:26 | |
| *** mkerrin has quit IRC | 00:37 | |
| *** russf has quit IRC | 00:38 | |
| *** MrTopf has joined #zope3-dev | 00:39 | |
| *** ChrisW_ has quit IRC | 00:48 | |
| *** RockyBurt is now known as RockyBurt|away | 00:55 | |
| *** alga has quit IRC | 00:59 | |
| *** russf has joined #zope3-dev | 01:20 | |
| *** MrTopf has quit IRC | 01:25 | |
| *** benji_york has quit IRC | 01:27 | |
| *** wrobel has quit IRC | 01:29 | |
| *** wrobel has joined #zope3-dev | 01:30 | |
| *** philiKON has joined #zope3-dev | 01:31 | |
| *** zbir has joined #zope3-dev | 01:35 | |
| *** sashav has quit IRC | 01:38 | |
| *** philiKON has quit IRC | 01:59 | |
| *** philiKON has joined #zope3-dev | 02:09 | |
| *** J1m has quit IRC | 02:09 | |
| *** projekt01 has quit IRC | 02:09 | |
| *** philiKON has quit IRC | 02:11 | |
| *** RockyBurt|away is now known as RockyBurt | 02:13 | |
| *** Aiste has joined #zope3-dev | 02:33 | |
| *** yota has quit IRC | 02:49 | |
| *** stub has joined #zope3-dev | 03:08 | |
| *** dman13_ has joined #zope3-dev | 03:46 | |
| *** dman13 has quit IRC | 03:46 | |
| *** Aiste has quit IRC | 04:07 | |
| *** MiUlEr has joined #zope3-dev | 04:10 | |
| *** MiUlEr has left #zope3-dev | 04:10 | |
| *** ruda_porto has quit IRC | 04:13 | |
| *** Aiste has joined #zope3-dev | 04:15 | |
| *** rom|aw has quit IRC | 04:19 | |
| *** wrobel has quit IRC | 04:21 | |
| *** d2m has quit IRC | 04:58 | |
| *** natea has quit IRC | 05:05 | |
| *** tarek has quit IRC | 05:30 | |
| *** tarek has joined #zope3-dev | 05:31 | |
| *** zbir has quit IRC | 06:31 | |
| *** adamSummers has joined #zope3-dev | 06:39 | |
| adamSummers | hi there | 06:39 |
| *** tahara has joined #zope3-dev | 06:49 | |
| *** tahara has quit IRC | 06:52 | |
| *** jinty has quit IRC | 07:01 | |
| *** RockyBurt has quit IRC | 07:11 | |
| *** natea has joined #zope3-dev | 07:40 | |
| *** stub has quit IRC | 08:08 | |
| *** eins has joined #zope3-dev | 08:14 | |
| eins | morning | 08:14 |
| *** zagy has joined #zope3-dev | 08:20 | |
| *** tarek has quit IRC | 08:21 | |
| *** cursor has joined #zope3-dev | 08:22 | |
| *** tarek has joined #zope3-dev | 08:24 | |
| *** stub has joined #zope3-dev | 08:26 | |
| *** zagy has quit IRC | 08:46 | |
| *** wrobel has joined #zope3-dev | 08:48 | |
| *** sashav has joined #zope3-dev | 08:49 | |
| *** sashav has quit IRC | 08:50 | |
| *** MJ has quit IRC | 08:54 | |
| *** zagy has joined #zope3-dev | 09:08 | |
| *** natea_ has joined #zope3-dev | 09:09 | |
| *** zagy has quit IRC | 09:10 | |
| *** zagy has joined #zope3-dev | 09:10 | |
| *** zagy has quit IRC | 09:13 | |
| *** zagy has joined #zope3-dev | 09:15 | |
| *** hdima has joined #zope3-dev | 09:16 | |
| *** natea has quit IRC | 09:19 | |
| *** ChrisW has joined #zope3-dev | 09:28 | |
| *** d2m has joined #zope3-dev | 09:29 | |
| *** _pcardune has joined #zope3-dev | 09:37 | |
| *** jhauser has quit IRC | 09:38 | |
| *** hdima has quit IRC | 09:47 | |
| *** zagy has left #zope3-dev | 09:48 | |
| *** pcardune has quit IRC | 09:54 | |
| *** zagy has joined #zope3-dev | 09:54 | |
| *** dobee has joined #zope3-dev | 10:00 | |
| *** hdima has joined #zope3-dev | 10:04 | |
| *** anguenot has quit IRC | 10:09 | |
| *** dobee_ has joined #zope3-dev | 10:15 | |
| *** dobee has quit IRC | 10:28 | |
| *** sashav has joined #zope3-dev | 10:28 | |
| ChrisW | anyone up yet? | 10:29 |
| ChrisW | srichter: ping? | 10:29 |
| adamSummers | I been up for hours - its 5pm | 10:35 |
| ChrisW | *grinz* | 10:35 |
| ChrisW | well, it's only 10am here | 10:35 |
| ChrisW | and I need people with Zen ;-) | 10:35 |
| ChrisW | I wonderif Philipp's still in China | 10:35 |
| adamSummers | :) | 10:35 |
| ChrisW | I have noooo idea where Stefan is nowadays... | 10:35 |
| adamSummers | Its 4:30 in Beijing, if that gives you any indication.... | 10:36 |
| ChrisW | pm or am? | 10:36 |
| adamSummers | pm | 10:36 |
| ChrisW | ah | 10:36 |
| ChrisW | he must be slacking somewhere ;-) | 10:37 |
| *** MJ has joined #zope3-dev | 10:40 | |
| *** tahara has joined #zope3-dev | 10:43 | |
| *** dobee_ has quit IRC | 10:46 | |
| *** andres has joined #zope3-dev | 10:46 | |
| *** tonico has quit IRC | 11:01 | |
| *** srichter has quit IRC | 11:01 | |
| *** WebMaven has quit IRC | 11:01 | |
| *** andrew_m has quit IRC | 11:01 | |
| *** andrew_m has joined #zope3-dev | 11:01 | |
| *** tonico has joined #zope3-dev | 11:01 | |
| *** srichter has joined #zope3-dev | 11:01 | |
| *** WebMaven has joined #zope3-dev | 11:02 | |
| *** Theuni has joined #zope3-dev | 11:02 | |
| *** ChrisW has quit IRC | 11:02 | |
| *** SteveA has joined #zope3-dev | 11:03 | |
| *** andres_ has joined #zope3-dev | 11:05 | |
| *** j-w has joined #zope3-dev | 11:11 | |
| *** andres has quit IRC | 11:16 | |
| *** MrTopf has joined #zope3-dev | 11:22 | |
| *** xenru has quit IRC | 11:28 | |
| *** jinty has joined #zope3-dev | 11:44 | |
| *** _anguenot has joined #zope3-dev | 11:46 | |
| *** jinty has quit IRC | 12:11 | |
| *** j-1 has joined #zope3-dev | 12:13 | |
| *** j-w has quit IRC | 12:15 | |
| *** ignas has joined #zope3-dev | 12:24 | |
| *** xenru has joined #zope3-dev | 12:44 | |
| *** j-1 is now known as j-w | 12:47 | |
| *** mgedmin has joined #zope3-dev | 12:52 | |
| *** mkerrin has joined #zope3-dev | 12:53 | |
| *** _pcardune has quit IRC | 13:28 | |
| *** ChanServ sets mode: +o srichter | 13:41 | |
| *** xenru has quit IRC | 13:42 | |
| *** faassen has joined #zope3-dev | 13:59 | |
| *** MrTopf has quit IRC | 13:59 | |
| *** MrTopf has joined #zope3-dev | 13:59 | |
| *** dobee has joined #zope3-dev | 14:10 | |
| *** andres_ is now known as andres | 14:11 | |
| *** Aiste has quit IRC | 14:26 | |
| *** yota has joined #zope3-dev | 14:51 | |
| *** ruda_porto has joined #zope3-dev | 15:08 | |
| *** RockyBurt has joined #zope3-dev | 15:14 | |
| *** _anguenot has quit IRC | 15:19 | |
| *** _anguenot has joined #zope3-dev | 15:22 | |
| *** povbot` has joined #zope3-dev | 15:35 | |
| *** andrew_m has quit IRC | 15:35 | |
| *** andrew_m has joined #zope3-dev | 15:37 | |
| *** benji_york has joined #zope3-dev | 15:39 | |
| *** povbot has quit IRC | 15:41 | |
| *** RockyBurt has quit IRC | 15:43 | |
| *** RockyBurt has joined #zope3-dev | 15:44 | |
| *** sashav has quit IRC | 15:47 | |
| *** alga has joined #zope3-dev | 15:55 | |
| * VladDrac needs someone with some knowledge of zope3 pagetemplate internals | 15:57 | |
| *** mgedmin has quit IRC | 16:01 | |
| *** niemeyer has joined #zope3-dev | 16:07 | |
| *** efge has joined #zope3-dev | 16:08 | |
| *** jinty has joined #zope3-dev | 16:20 | |
| *** alga has quit IRC | 16:25 | |
| *** philiKON has joined #zope3-dev | 16:28 | |
| *** elbixio has joined #zope3-dev | 16:28 | |
| *** adamSummers has quit IRC | 16:28 | |
| *** jinty has quit IRC | 16:47 | |
| *** russf has quit IRC | 17:05 | |
| *** ruda_porto has quit IRC | 17:08 | |
| *** romanofski has joined #zope3-dev | 17:12 | |
| *** zbir has joined #zope3-dev | 17:20 | |
| *** eins has quit IRC | 17:24 | |
| pcardune | menu item lookups don't seem to work for location proxied objects, it tries to order them using the interfaces provided by LocationProxy rather than the proxied object, is there any way around this? | 17:24 |
| *** hdima has quit IRC | 17:30 | |
| *** cursor has quit IRC | 17:30 | |
| *** srichter has quit IRC | 17:37 | |
| *** srichter has joined #zope3-dev | 17:40 | |
| *** mgedmin has joined #zope3-dev | 17:41 | |
| *** ChanServ sets mode: +o srichter | 17:42 | |
| *** alga has joined #zope3-dev | 17:43 | |
| *** ruda_porto has joined #zope3-dev | 17:52 | |
| *** tonico has quit IRC | 17:56 | |
| *** tonico has joined #zope3-dev | 18:05 | |
| *** zagy has quit IRC | 18:08 | |
| *** tonico has quit IRC | 18:09 | |
| *** romanofski has quit IRC | 18:10 | |
| *** romanofski has joined #zope3-dev | 18:10 | |
| *** alga_ has joined #zope3-dev | 18:18 | |
| *** MrTopf has quit IRC | 18:19 | |
| *** tonico has joined #zope3-dev | 18:26 | |
| *** elbixio has quit IRC | 18:26 | |
| *** cursor has joined #zope3-dev | 18:27 | |
| *** philiKON has quit IRC | 18:49 | |
| *** vinsci has joined #zope3-dev | 18:54 | |
| *** vlado has quit IRC | 19:00 | |
| *** Theuni has quit IRC | 19:02 | |
| *** _anguenot has quit IRC | 19:07 | |
| *** ruda_porto has quit IRC | 19:14 | |
| *** ruda_porto has joined #zope3-dev | 19:15 | |
| *** romanofski has quit IRC | 19:15 | |
| *** zagy has joined #zope3-dev | 19:19 | |
| *** mkerrin has quit IRC | 19:20 | |
| *** xtant_26 has joined #zope3-dev | 19:27 | |
| *** mkerrin has joined #zope3-dev | 19:27 | |
| *** xtant_26 has quit IRC | 19:27 | |
| *** flujan has joined #zope3-dev | 19:40 | |
| flujan | hi guys! I am searching for a web framework with works with python.I didn't want to mixe much of my python code with the web framework since I will reuse it in other softwares. I install and tried Zope3 and I always must do a Interface for my python classes.So, is there a way to just work with python inside zope3 without the xml stuff and so on? | 19:43 |
| flujan | And Can Zope persist objects in relational database ? as turbogears for example. | 19:43 |
| *** dobee has quit IRC | 19:44 | |
| faassen | flujan: you can use sqlos | 19:46 |
| faassen | http://codespeak.net/z3/sqlos/ | 19:47 |
| faassen | for SQLObject use. | 19:47 |
| * RockyBurt just got done with why there should be a more transparent ORM framework for zope3 with andres and j-w ;) | 19:48 | |
| *** pcardune has left #zope3-dev | 19:48 | |
| *** j-w has quit IRC | 19:49 | |
| faassen | RockyBurt: as opposed to SQLObject? | 19:51 |
| RockyBurt | faassen: either opposed or adapting | 19:51 |
| faassen | RockyBurt: what's the issue with SQLObject? I mean, there may be many issues, I don't debate it. :) | 19:52 |
| RockyBurt | most likely opposed tho | 19:52 |
| faassen | I mean, why another ORM? | 19:52 |
| RockyBurt | well, my biggest standpoint right now is that since zope already provides a nice persistence api (via zodb) then it would make a lot more sense for a zope-enabled ORM framework to piggy back off of that api so no more coding is required (ie your same objects would work in zodb or rdbms without any coding changes) -- this basically means providing an external mapping framework for tables/cols, etc probably based on zcml | 19:53 |
| RockyBurt | this would enable people to adapt existing zope3-based apps to store content in an rdbms without having to change code | 19:54 |
| RockyBurt | using the zodb transaction machinery to deal with rdbms transactions (possibly) as well, etc | 19:54 |
| faassen | RockyBurt: so you're talking about something like APE. | 19:55 |
| faassen | RockyBurt: along the lines of what Florent posted in his weblog a while back. | 19:55 |
| RockyBurt | not ape, too low level, although ape has its advantages as well | 19:55 |
| faassen | the advantage of SQLObject is that it's there, it's mature, it has a community, it's not our own wheel invented again, and it has lots of features and thought went into it. | 19:55 |
| efge | but the disadvantage is that it's not a ZODB storage so is not very transparent :) | 19:56 |
| efge | or not enough for my taste | 19:56 |
| *** MJ has quit IRC | 19:56 | |
| RockyBurt | efge: right, which is i'm trying to achieve much better transparency without having to go as low level as the zodb | 19:56 |
| efge | RockyBurt: ... using sqlos you mean? | 19:57 |
| faassen | well, I hope that can be built on top of SQLObject somehow. I really think Zope shouldn't invent its own wheel in this area. | 19:57 |
| *** sashav has joined #zope3-dev | 19:57 | |
| RockyBurt | right | 19:57 |
| RockyBurt | well, or sqlos replacement ;) | 19:57 |
| efge | sqlobject and ZODB persistence mechanisms are pretty different | 19:57 |
| faassen | sure, I'm not claiming sqlos couldn't be evolved. | 19:57 |
| efge | I know, I'm burried in ZODB to code this right now :) | 19:57 |
| faassen | yes, but I really think this is getting very close to a Not Invented Here thing. | 19:57 |
| faassen | I mean, if every persistence machinery zope 3 uses has to work like the ZODB.. | 19:58 |
| faassen | then what's the point about Zope 3 being able to work easily with external Python systems? | 19:58 |
| efge | my goal is indeed to simplify the hooks needed | 19:58 |
| efge | but still have them under the ZODB layer | 19:58 |
| faassen | I can see the abstract attraction of using something that fits Zope better, but I can see the attraction of using stuff that's there and has a community and a lot of thought into it too. :) | 19:58 |
| RockyBurt | efge: yes, i'm saying stay on top of the zodb (where sqlos is) to provide the framework, but hook into the zodb for transaction machinery events and application development api | 19:58 |
| faassen | and I want my queries. | 19:59 |
| faassen | and I want my mapping of existing relational databases into an object model. | 19:59 |
| flujan | faassen: This is my question... Zope3 can work easily sith any other python programs? | 19:59 |
| efge | faassen: oh I want them too don't worry :) | 19:59 |
| faassen | I'm not sure how you'd keep those features there if you make it ZODB-like.. | 19:59 |
| faassen | I mean, you'd still want to be able to use SQLObject's api. | 20:00 |
| RockyBurt | faassen: the best solution in my mind would be to find some way of hooking SQLObject in but still be transparent (ie not have to have my objects textend SQLOS/SQLObject), i don't want to see another orm framework built, i just want to see working with an orm framework much more natural in a zope3 sense | 20:00 |
| faassen | unless you want to invent a whole new way to declare all that, which seems a waste. | 20:00 |
| faassen | though of course it'd be nice if interfaces/schema and SQLObject declarations could be more alike somehow. | 20:00 |
| efge | I'll need to add some api for queries of course, I'll check what's available | 20:00 |
| efge | and I'll use schemas to define the mappings and relational aspects | 20:01 |
| faassen | flujan: that's a bit broad a question. if it's a python library you can just import it, just like any other python code. concerning python programs, it depends on your programs. | 20:01 |
| efge | anyway that's still beginning of work in progress so I'll tell more in a few weeks | 20:01 |
| SteveA | stub had some plan to make basic generated SQLObject classes from SQL | 20:01 |
| faassen | efge: well, you'll have to extend schemas to express that information. | 20:01 |
| RockyBurt | my biggest beef is defining mappings in code, i think that should be external | 20:01 |
| SteveA | along with basic interfaces | 20:01 |
| faassen | SteveA: that's interesting. use the relational database's information on its tables along with schemas. | 20:01 |
| faassen | SteveA: to deduce what the SQLObject declaration would look like. | 20:02 |
| faassen | SteveA: you might be able to get away with less schema annotations then. | 20:02 |
| efge | yes mapinng the sql schemas to zope 3 schemas is part of my plan | 20:02 |
| faassen | RockyBurt: I don't want to have to write a lot of ZCML to do it either, though. | 20:02 |
| faassen | but I really urge people to take SQLObject as a given and not move towards a new ORM mapping system. Making it fit better is fine. If we can get changes into SQLObject to support our usecase, fine.. | 20:03 |
| RockyBurt | faassen: for a mapping? but a mapping is precisely configuration which is why zcml was created to begin with | 20:03 |
| srichter | flujan: jfmoxeley (who is usually here) came to me with a Python application that computed Baseball statistics. It was no problem to develop a Zope 3 application on top of this code | 20:03 |
| faassen | but a new ORM mapping, I hope not. | 20:03 |
| *** zagy_ has joined #zope3-dev | 20:03 | |
| andres | SteveA, that should be possible already or not? The only problem is, that there are no security declarations for the attributes of the generated class. | 20:04 |
| faassen | RockyBurt: is a form configuration? | 20:04 |
| RockyBurt | faassen: depends on what form configuration means ;) | 20:04 |
| RockyBurt | layout of fields on a form is not form configuration ;) | 20:04 |
| RockyBurt | workflow actions of a form could possibly be form configuration | 20:04 |
| faassen | RockyBurt: I think many declarative things can be expressed in Python code. A mapping tends to be closely code related. it's declarative but ti's closely tied in to the python code that uses it and the structure of the database | 20:04 |
| efge | faassen: sqlobject is based on classes and metaclasses defining behaviour. zope persistence and storage is based on entirely different things | 20:04 |
| faassen | RockyBurt: so I don't see the value of being able to change that externally. | 20:04 |
| faassen | RockyBurt: perhaps hook up declarations externally, and separation of the declarations in Python code from the other code sounds good, but doing it outside Python code seems to be a challenge in language design. | 20:05 |
| RockyBurt | being able to take a third-party product and simply define a new piece of zcml to map its content type fields to rdbms has a lot of value compared to having to write code just to do that | 20:05 |
| faassen | efge: yes, but SQLObject has a lot of functionality and thinking into it, and I don't want us to say 'ooh, Zope is great, Zope is open to other Python code, here is our own ORM, as we think SQLObject doesn't match our story' | 20:06 |
| RockyBurt | i guess i'm just too much stuck on EJB CMP XML declarations in j2ee because it just made more sense to me | 20:06 |
| efge | well what if really doesn't match? | 20:06 |
| faassen | efge: I really don't think Zope should be in the business of object relational mappings too. | 20:06 |
| *** niemeyer has quit IRC | 20:07 | |
| faassen | efge: perhaps there's another Python ORM tool that matches better, I don't know. but write a new one? | 20:07 |
| RockyBurt | faassen: if zope is a web development framework, i wholeheartedly disagree as every other web development framework worth its salt comes up with some solution for that | 20:07 |
| faassen | RockyBurt: I am supporting an ORM mapping used by Zope. I'm not supporting us developing a new one. | 20:08 |
| * srichter agrees strongly with faassen's arguments here; we are trying very hard to not invade other businesses these days | 20:08 | |
| faassen | RockyBurt: I'm supporting using an existing one which has a lot of thinking and development already in it. | 20:08 |
| efge | faassen: all the orm mappers I've seen assume they control the classes and control the world. That's not compatible with Zope and the way it does persistence. | 20:08 |
| efge | the impedance mismatch is huge | 20:09 |
| faassen | efge: then we engage those people. | 20:09 |
| faassen | efge: we go talk to them. | 20:09 |
| *** zagy has quit IRC | 20:09 | |
| faassen | efge: and the impendance mismatch is not so huge we're not successfully using it with Five in Zope 2. | 20:09 |
| RockyBurt | faassen: yes, and i agree that mapping something like SQLObject to zope is definitely the preferred goal ... but i still feel it needs to be more transparent to be useful | 20:09 |
| faassen | I disagree that the current efforts are not useful. :) | 20:09 |
| faassen | I agree they can be improved. | 20:09 |
| RockyBurt | sorry, i didn't mean that ;) | 20:09 |
| efge | faassen: besides I need a mapper that can not only talk sql but also filesystem and LDAP... it's more than SQL | 20:09 |
| RockyBurt | i meant they're not as useful as they could be (at least to me) | 20:09 |
| faassen | efge: I need a universal McGuffin too. :) | 20:10 |
| faassen | efge: but it's rather ambitious, such a universal mcguffin. | 20:10 |
| faassen | efge: to abstract over all those storages to me sounds like losing the benefits particular storages offer. | 20:10 |
| faassen | efge: you'd have to abstract over their different query mechanisms, and it's likely you'll end up with some leaky abstractions that are lowest common denominator. so, that's a huge challenge. | 20:11 |
| RockyBurt | faassen: such is the compromises with any abstraction layer :) | 20:11 |
| faassen | RockyBurt: sure, we should extend the current efforts. | 20:11 |
| faassen | RockyBurt: better have something that integrates less seamlessly but offers its own abstractions then. | 20:11 |
| faassen | RockyBurt: you can't seamlessly port your code from ZODB to RDB and back. | 20:12 |
| faassen | RockyBurt: but you can use SQL when you use the RDB backend. | 20:12 |
| faassen | RockyBurt: and the catalog when you use the ZODB. | 20:12 |
| faassen | RockyBurt: anyway, I think such a seamless port is likely to result in leaky abstractions. you port from ZODB to RDB and suddenly you have performance problems, perhaps. | 20:12 |
| faassen | RockyBurt: as the assumptions are very different. | 20:12 |
| faassen | RockyBurt: I'm also wondering how desirable that is in the end in practice, being able to do it. not sure. | 20:13 |
| efge | well we'll see in a month, I've researched existing alternatives and they don't fit the bill | 20:13 |
| faassen | efge: I'm wondering whether your bill is the right one. :) | 20:14 |
| RockyBurt | faassen: i'm trying to pull from my long time j2ee experience with persistence where EJB is being nearly totally re-done with EJB3 because of a major lack of transparency (amongst other things) | 20:14 |
| faassen | RockyBurt: and how succesful is EJB3? | 20:14 |
| RockyBurt | faassen: EJB3 isn't released yet ;) | 20:14 |
| faassen | RockyBurt: okay. :) | 20:14 |
| RockyBurt | but EJB3 is modeled after Hibernate which is extremely popular (and has taken a huge community share away from EJB2) | 20:15 |
| faassen | I mean, why not see this as implementation an dinterfaces? | 20:15 |
| faassen | you have an interface that says, this thing has this and this attribute. | 20:15 |
| faassen | and you have an implementation, that either subclasses from Persistent. | 20:15 |
| faassen | or subclasses from SQLObject. | 20:15 |
| faassen | that worries about how to persist things. | 20:15 |
| faassen | if you need to switch from one to the other, you'll have to change your implementation, but if you need to switch you'll have to worry about quite a bit other things, like how to convert your queries, say.. | 20:15 |
| RockyBurt | that means you have to write 2 implementations to support both | 20:15 |
| RockyBurt | which is exactly what i'm trying to avoid | 20:16 |
| faassen | RockyBurt: but you'll have to worry about changing your implementation anyway. | 20:16 |
| faassen | RockyBurt: as your query logic will need to change. | 20:16 |
| faassen | RockyBurt: and you'll likely get drastically different performance characteristics. | 20:16 |
| faassen | RockyBurt: if you really are able to do this, I imagine you can regenerate your code using archgenXML. | 20:17 |
| faassen | RockyBurt: I mean, if you *really* have everything declared then you could use such methods. | 20:17 |
| faassen | RockyBurt: but in practice I really think you want to exploit SQL's abilities if you're using a RDB, and the catalog if you're using ZODB, and you can't switch that easily anyway. | 20:17 |
| RockyBurt | faassen: if you *really* need such ultimate flexibilty, you will not be using ORM to begin with, you will need raw SQL (i know this from experience as well as i've had to stop using EJB in some cases because it wasn't flexible enough) | 20:18 |
| faassen | RockyBurt: well, my ORM lets me use raw SQL if I need to. | 20:18 |
| RockyBurt | ORM is already an abstraction that forces you to lose some direct rdbms capability | 20:18 |
| RockyBurt | faassen: using raw SQL is one thing, being able to define relationships, primary keys, special colum types etc etc is another | 20:18 |
| RockyBurt | i've yet to find an ORM that let you control everything (at that point there is no ORM) | 20:19 |
| faassen | RockyBurt: you can define primary keys and relationships with SQLObject.. | 20:19 |
| faassen | RockyBurt: don't know how far it goes with special column types. | 20:19 |
| faassen | RockyBurt: I imagine you can extend it if you need to. | 20:20 |
| faassen | RockyBurt: anyway, even if a ORM makes you give up some control, you still get way more control than with a universal persistent abstraction. | 20:21 |
| faassen | RockyBurt: persistence. | 20:21 |
| RockyBurt | regardless, i'm not saying what i'm saying to displace sqlos/SQLObject ... in my mind if we could reuse SQLObject that'd be terrific (and may be doable) ... i'm basically saying i'd like an alternate way that is much more transparent, and if that still uses SQLObject that means people can fall back to standard SQLObject when the transparency hides too much functionality | 20:21 |
| faassen | RockyBurt: unless that universal persistence abstraction is able to offer a rich query language (as rich as SQL or thereabouts) while also offering the same for ZODB (on top of the catalog), LDAP, etc. | 20:21 |
| RockyBurt | perhaps sqlos should/could be extended to allow for more transparency but still maintain the existing way of doing it | 20:22 |
| faassen | RockyBurt: I agree that we should be able to use SQLObject more transparently. Florent worries me way more with his ambitious. | 20:22 |
| faassen | RockyBurt: ambition. | 20:22 |
| RockyBurt | faassen: one of the biggest reasons i see transparency as a good thing too is decreasing the barrier of entry for python developers getting in to zope dev and using persistence ... letting them use SQLObject as-is or being more transparent would accomodate a great audience methinks | 20:22 |
| faassen | RockyBurt: but I think using SQLObject will decrease the barrier too, as it's a python library with a lot of documentation, a community and a well known brand. | 20:23 |
| RockyBurt | agreed, which is a good reason to stick with it | 20:23 |
| faassen | RockyBurt: we already got transparent persistence with the ZODB. | 20:23 |
| benji_york | :w | 20:23 |
| faassen | RockyBurt: anyway, I agree with the goal of trying to make things more seamless. the main thing I see is Zope 3 interfaces versus SQLObject declarations. | 20:23 |
| benji_york | oops, wrong window :) | 20:24 |
| faassen | RockyBurt: but I'm sure there's much more. | 20:24 |
| RockyBurt | but you have convinced me with regards to replacing SQLObject ... i think if this transparency cannot be achieved a solid existing framework like SQLObject, then it should be dropped :) | 20:24 |
| faassen | benji_york: oh, It hought you were going to say something profound. :) | 20:24 |
| andres | faassen, RockyBurt , perhaps we could collect what transparency improvements we need and which dont seem to be too unrealistic. | 20:24 |
| * benji_york is unmasked as a Vim user | 20:24 | |
| benji_york | faassen :) | 20:24 |
| RockyBurt | +with | 20:24 |
| faassen | RockyBurt: oh, wow, that's beyond what I expected out of this discussion. I just hoped to place some arguments in people's minds that would work through and in a few months attitudes would be slightly different. :) | 20:24 |
| faassen | andres: yes, that would be good. | 20:25 |
| *** benji_york is now known as benji | 20:25 | |
| faassen | andres: j-w and I were talking today about autogenerating a zope 3 schema from SQLObject's declarations. | 20:25 |
| faassen | andres: having to define that stuff twice seems a waste. | 20:25 |
| RockyBurt | andres: after having had this discussion i think that would be the best starting point | 20:25 |
| andres | because talking wont bring us further and i guess everyone using sqlos makes his own improvements. | 20:25 |
| andres | but not in a way that they are usefull for trunk. | 20:26 |
| faassen | andres: I agree that after this we should take some concrete action. :) | 20:26 |
| RockyBurt | just keep in mind that i'm still stuck on plenty of j2ee concepts (which is good and bad) and that whatever solution i end up using with sqlos/sqlobject/whatever needs to also work with z2/five in some fashion :) | 20:26 |
| faassen | andres: we haven't done much of that yet but depending on how often we end up using this we'll definitely investigate adding to the trunk. | 20:26 |
| RockyBurt | thats another reason i'd like to keep working with sqlos since sqlos has FiveSQLOS | 20:27 |
| faassen | RockyBurt: yeah, j2ee experience is good to hear in all this. | 20:27 |
| *** J1m has joined #zope3-dev | 20:27 | |
| faassen | RockyBurt: you should post something comparing j2ee and zope one day. | 20:27 |
| faassen | RockyBurt: I'd be interested to hear about this. | 20:27 |
| faassen | J1m: you just missed the Grant Storage Abstraction discussion. | 20:28 |
| faassen | Grand. | 20:28 |
| faassen | not Grant. | 20:28 |
| faassen | that would be something else. then we'd just have a storage abstraction for permissions. | 20:28 |
| RockyBurt | faassen: the problem is its difficult to do that since j2ee is a set of specifications and interfaces ... each implementation (weblogic, websphere, orion, etc) all bring their own additional features, etc ... so while j2ee VS zope might be good for zope people, its not really that good for j2ee people | 20:28 |
| RockyBurt | hehe | 20:28 |
| flujan | surely... such article will be very useful to comparison purposes | 20:28 |
| andres | faassen, how do you want to create the schema? Thats not easy i think ;-). Especially if you want an real interface out of it. The other way would be easier, but you couldnt specify joins etc. | 20:29 |
| faassen | RockyBurt: I just want to know about it from a zope perspective. :) | 20:29 |
| RockyBurt | faassen: i do intend on blogging on it sometime soon so i'll have to keep all of this in mind :) | 20:29 |
| faassen | andres: well, Tres Seaver did a bridge module in Five that makes z3 interfaces out of z2 ones. | 20:29 |
| faassen | andres: so I was interested in looking there. you can create schema on the fly, I don't see why that would be so hard? I think most information is in SQLObject. And if you want to make it more specific, you could subclass the generated schema (thinking on my feet) to override particular fields. | 20:30 |
| faassen | RockyBurt: cool | 20:30 |
| andres | faassen, not the schema generation itself is the real hard thing, its just that normally the SQLOS instance implements a specific schema. Which wouldnt be possible via the normal implements() because at the time of the generation of the SQLOS instance the schema cant exist yet. | 20:31 |
| faassen | andres: good point. we'll have to worry about making it happen afterwards. | 20:32 |
| faassen | andres: that should be doable though, I think. | 20:32 |
| andres | You dont have that problem with zope2if -> zope3if. | 20:32 |
| faassen | andres: true. | 20:32 |
| andres | faassen, yes, you can do it afterwards, but then its again not that "transparent" | 20:33 |
| andres | As you cant use implements and whatnot. | 20:33 |
| faassen | andres: yes, so perhaps we have to reach for higher magic. | 20:35 |
| *** romanofski has joined #zope3-dev | 20:35 | |
| andres | faassen, it shouldnt be too hard to do with directlyProvides or so. | 20:35 |
| andres | faassen, all i tried to say, what, that it wont "feel" like a normal interface. | 20:36 |
| faassen | andres: you've done more thinking about this than I have | 20:36 |
| andres | -what | 20:36 |
| faassen | andres: anyway, this would need more thought and experimentation from my side. | 20:37 |
| andres | But still, this is one thing, we should note. | 20:40 |
| faassen | andres: yes. | 20:40 |
| andres | Providing a traverser which somehow works with joins would be usefull too. | 20:41 |
| faassen | andres: we may even get ambitious and talk to the SQLObject people after studying the way it works, to see whether we can come up with ways to match it better with Zope 3 persistence, etc. | 20:41 |
| faassen | andres: yes. | 20:41 |
| andres | I have one but its a bit raw. | 20:41 |
| faassen | andres: though on the other hand, zope 3 objects aren't traversable like that on the fly either, unless they're folderish, I guess | 20:42 |
| andres | faassen, but for me a join is much like a folder. | 20:43 |
| andres | faassen, and i dont think it should be on by default. | 20:43 |
| *** ruda_porto has quit IRC | 20:43 | |
| *** ruda_porto has joined #zope3-dev | 20:44 | |
| faassen | andres: right. | 20:44 |
| *** cursor has quit IRC | 20:45 | |
| *** sashav has quit IRC | 20:47 | |
| *** efge has quit IRC | 20:47 | |
| *** sashav has joined #zope3-dev | 20:53 | |
| *** ignas has quit IRC | 20:59 | |
| *** tarek has quit IRC | 20:59 | |
| *** tarek has joined #zope3-dev | 21:03 | |
| *** ruda_porto has quit IRC | 21:05 | |
| *** tarek_ has joined #zope3-dev | 21:05 | |
| *** alga_ has quit IRC | 21:08 | |
| *** faassen has quit IRC | 21:11 | |
| *** Aiste has joined #zope3-dev | 21:12 | |
| *** ruda_porto has joined #zope3-dev | 21:21 | |
| *** mgedmin has quit IRC | 21:29 | |
| *** dman13_ is now known as dman13 | 21:29 | |
| *** povbot has joined #zope3-dev | 22:17 | |
| *** MiUlEr has quit IRC | 22:17 | |
| *** mkerrin has quit IRC | 22:24 | |
| *** povbot` has joined #zope3-dev | 22:46 | |
| *** povbot has quit IRC | 22:53 | |
| *** alga has quit IRC | 22:54 | |
| *** projekt01 has joined #zope3-dev | 23:01 | |
| *** romanofski has quit IRC | 23:06 | |
| *** zagy_ has quit IRC | 23:07 | |
| *** povbot has joined #zope3-dev | 23:31 | |
| *** povbot` has joined #zope3-dev | 23:40 | |
| *** J1m has joined #zope3-dev | 23:43 | |
| *** pcardune has joined #zope3-dev | 23:44 | |
| *** alga has joined #zope3-dev | 23:46 | |
| *** natea_ has quit IRC | 23:51 | |
| *** povbot has quit IRC | 23:52 | |
| *** sashav has quit IRC | 23:58 | |
Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!