IRC log of #zope3-dev for Wednesday, 2006-01-11

ChrisWno, I meant havign to dropping crappy little .zcml files into etc/package-includes00:00
ChrisWthankfully, zope 3 is flexible so I can do it my way ;-)00:00
ChrisWand I would love to have the time to implement a .conf-based replacement for zcml00:00
*** russf has quit IRC00:01
projekt01Chrisw, they are great, if you have a package downloaded with the correct SETUP.cfg, the will copy the right *-configure.zcml to the site-package folder00:01
projekt01I didn't see a better way for a framework which is not the same as a custom project.00:02
*** ChrisW_ has joined #zope3-dev00:06
*** MrTopf has quit IRC00:12
*** Aiste has quit IRC00:15
*** zbir has quit IRC00:16
*** ChrisW has quit IRC00:20
*** russf has joined #zope3-dev00:26
*** mkerrin has quit IRC00:37
*** russf has quit IRC00:38
*** MrTopf has joined #zope3-dev00:39
*** ChrisW_ has quit IRC00:48
*** RockyBurt is now known as RockyBurt|away00:55
*** alga has quit IRC00:59
*** russf has joined #zope3-dev01:20
*** MrTopf has quit IRC01:25
*** benji_york has quit IRC01:27
*** wrobel has quit IRC01:29
*** wrobel has joined #zope3-dev01:30
*** philiKON has joined #zope3-dev01:31
*** zbir has joined #zope3-dev01:35
*** sashav has quit IRC01:38
*** philiKON has quit IRC01:59
*** philiKON has joined #zope3-dev02:09
*** J1m has quit IRC02:09
*** projekt01 has quit IRC02:09
*** philiKON has quit IRC02:11
*** RockyBurt|away is now known as RockyBurt02:13
*** Aiste has joined #zope3-dev02:33
*** yota has quit IRC02:49
*** stub has joined #zope3-dev03:08
*** dman13_ has joined #zope3-dev03:46
*** dman13 has quit IRC03:46
*** Aiste has quit IRC04:07
*** MiUlEr has joined #zope3-dev04:10
*** MiUlEr has left #zope3-dev04:10
*** ruda_porto has quit IRC04:13
*** Aiste has joined #zope3-dev04:15
*** rom|aw has quit IRC04:19
*** wrobel has quit IRC04:21
*** d2m has quit IRC04:58
*** natea has quit IRC05:05
*** tarek has quit IRC05:30
*** tarek has joined #zope3-dev05:31
*** zbir has quit IRC06:31
*** adamSummers has joined #zope3-dev06:39
adamSummershi there06:39
*** tahara has joined #zope3-dev06:49
*** tahara has quit IRC06:52
*** jinty has quit IRC07:01
*** RockyBurt has quit IRC07:11
*** natea has joined #zope3-dev07:40
*** stub has quit IRC08:08
*** eins has joined #zope3-dev08:14
*** zagy has joined #zope3-dev08:20
*** tarek has quit IRC08:21
*** cursor has joined #zope3-dev08:22
*** tarek has joined #zope3-dev08:24
*** stub has joined #zope3-dev08:26
*** zagy has quit IRC08:46
*** wrobel has joined #zope3-dev08:48
*** sashav has joined #zope3-dev08:49
*** sashav has quit IRC08:50
*** MJ has quit IRC08:54
*** zagy has joined #zope3-dev09:08
*** natea_ has joined #zope3-dev09:09
*** zagy has quit IRC09:10
*** zagy has joined #zope3-dev09:10
*** zagy has quit IRC09:13
*** zagy has joined #zope3-dev09:15
*** hdima has joined #zope3-dev09:16
*** natea has quit IRC09:19
*** ChrisW has joined #zope3-dev09:28
*** d2m has joined #zope3-dev09:29
*** _pcardune has joined #zope3-dev09:37
*** jhauser has quit IRC09:38
*** hdima has quit IRC09:47
*** zagy has left #zope3-dev09:48
*** pcardune has quit IRC09:54
*** zagy has joined #zope3-dev09:54
*** dobee has joined #zope3-dev10:00
*** hdima has joined #zope3-dev10:04
*** anguenot has quit IRC10:09
*** dobee_ has joined #zope3-dev10:15
*** dobee has quit IRC10:28
*** sashav has joined #zope3-dev10:28
ChrisWanyone up yet?10:29
ChrisWsrichter: ping?10:29
adamSummersI been up for hours - its 5pm10:35
ChrisWwell, it's only 10am here10:35
ChrisWand I need people with Zen ;-)10:35
ChrisWI wonderif Philipp's still in China10:35
ChrisWI have noooo idea where Stefan is nowadays...10:35
adamSummersIts 4:30 in Beijing, if that gives you any indication....10:36
ChrisWpm or am?10:36
ChrisWhe must be slacking somewhere ;-)10:37
*** MJ has joined #zope3-dev10:40
*** tahara has joined #zope3-dev10:43
*** dobee_ has quit IRC10:46
*** andres has joined #zope3-dev10:46
*** tonico has quit IRC11:01
*** srichter has quit IRC11:01
*** WebMaven has quit IRC11:01
*** andrew_m has quit IRC11:01
*** andrew_m has joined #zope3-dev11:01
*** tonico has joined #zope3-dev11:01
*** srichter has joined #zope3-dev11:01
*** WebMaven has joined #zope3-dev11:02
*** Theuni has joined #zope3-dev11:02
*** ChrisW has quit IRC11:02
*** SteveA has joined #zope3-dev11:03
*** andres_ has joined #zope3-dev11:05
*** j-w has joined #zope3-dev11:11
*** andres has quit IRC11:16
*** MrTopf has joined #zope3-dev11:22
*** xenru has quit IRC11:28
*** jinty has joined #zope3-dev11:44
*** _anguenot has joined #zope3-dev11:46
*** jinty has quit IRC12:11
*** j-1 has joined #zope3-dev12:13
*** j-w has quit IRC12:15
*** ignas has joined #zope3-dev12:24
*** xenru has joined #zope3-dev12:44
*** j-1 is now known as j-w12:47
*** mgedmin has joined #zope3-dev12:52
*** mkerrin has joined #zope3-dev12:53
*** _pcardune has quit IRC13:28
*** ChanServ sets mode: +o srichter13:41
*** xenru has quit IRC13:42
*** faassen has joined #zope3-dev13:59
*** MrTopf has quit IRC13:59
*** MrTopf has joined #zope3-dev13:59
*** dobee has joined #zope3-dev14:10
*** andres_ is now known as andres14:11
*** Aiste has quit IRC14:26
*** yota has joined #zope3-dev14:51
*** ruda_porto has joined #zope3-dev15:08
*** RockyBurt has joined #zope3-dev15:14
*** _anguenot has quit IRC15:19
*** _anguenot has joined #zope3-dev15:22
*** povbot` has joined #zope3-dev15:35
*** andrew_m has quit IRC15:35
*** andrew_m has joined #zope3-dev15:37
*** benji_york has joined #zope3-dev15:39
*** povbot has quit IRC15:41
*** RockyBurt has quit IRC15:43
*** RockyBurt has joined #zope3-dev15:44
*** sashav has quit IRC15:47
*** alga has joined #zope3-dev15:55
* VladDrac needs someone with some knowledge of zope3 pagetemplate internals15:57
*** mgedmin has quit IRC16:01
*** niemeyer has joined #zope3-dev16:07
*** efge has joined #zope3-dev16:08
*** jinty has joined #zope3-dev16:20
*** alga has quit IRC16:25
*** philiKON has joined #zope3-dev16:28
*** elbixio has joined #zope3-dev16:28
*** adamSummers has quit IRC16:28
*** jinty has quit IRC16:47
*** russf has quit IRC17:05
*** ruda_porto has quit IRC17:08
*** romanofski has joined #zope3-dev17:12
*** zbir has joined #zope3-dev17:20
*** eins has quit IRC17:24
pcardunemenu 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 IRC17:30
*** cursor has quit IRC17:30
*** srichter has quit IRC17:37
*** srichter has joined #zope3-dev17:40
*** mgedmin has joined #zope3-dev17:41
*** ChanServ sets mode: +o srichter17:42
*** alga has joined #zope3-dev17:43
*** ruda_porto has joined #zope3-dev17:52
*** tonico has quit IRC17:56
*** tonico has joined #zope3-dev18:05
*** zagy has quit IRC18:08
*** tonico has quit IRC18:09
*** romanofski has quit IRC18:10
*** romanofski has joined #zope3-dev18:10
*** alga_ has joined #zope3-dev18:18
*** MrTopf has quit IRC18:19
*** tonico has joined #zope3-dev18:26
*** elbixio has quit IRC18:26
*** cursor has joined #zope3-dev18:27
*** philiKON has quit IRC18:49
*** vinsci has joined #zope3-dev18:54
*** vlado has quit IRC19:00
*** Theuni has quit IRC19:02
*** _anguenot has quit IRC19:07
*** ruda_porto has quit IRC19:14
*** ruda_porto has joined #zope3-dev19:15
*** romanofski has quit IRC19:15
*** zagy has joined #zope3-dev19:19
*** mkerrin has quit IRC19:20
*** xtant_26 has joined #zope3-dev19:27
*** mkerrin has joined #zope3-dev19:27
*** xtant_26 has quit IRC19:27
*** flujan has joined #zope3-dev19:40
flujanhi 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
flujanAnd Can Zope  persist objects in relational database ? as turbogears for example.19:43
*** dobee has quit IRC19:44
faassenflujan: you can use sqlos19:46
faassenfor 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-dev19:48
*** j-w has quit IRC19:49
faassenRockyBurt: as opposed to SQLObject?19:51
RockyBurtfaassen: either opposed or adapting19:51
faassenRockyBurt: what's the issue with SQLObject? I mean, there may be many issues, I don't debate it. :)19:52
RockyBurtmost likely opposed tho19:52
faassenI mean, why another ORM?19:52
RockyBurtwell, 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 zcml19:53
RockyBurtthis would enable people to adapt existing zope3-based apps to store content in an rdbms without having to change code19:54
RockyBurtusing the zodb transaction machinery to deal with rdbms transactions (possibly) as well, etc19:54
faassenRockyBurt: so you're talking about something like APE.19:55
faassenRockyBurt: along the lines of what Florent posted in his weblog a while back.19:55
RockyBurtnot ape, too low level, although ape has its advantages as well19:55
faassenthe 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
efgebut the disadvantage is that it's not a ZODB storage so is not very transparent :)19:56
efgeor not enough for my taste19:56
*** MJ has quit IRC19:56
RockyBurtefge: right, which is i'm trying to achieve much better transparency without having to go as low level as the zodb19:56
efgeRockyBurt: ... using sqlos you mean?19:57
faassenwell, 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-dev19:57
RockyBurtwell, or sqlos replacement ;)19:57
efgesqlobject and ZODB persistence mechanisms are pretty different19:57
faassensure, I'm not claiming sqlos couldn't be evolved.19:57
efgeI know, I'm burried in ZODB to code this right now :)19:57
faassenyes, but I really think this is getting very close to a Not Invented Here thing.19:57
faassenI mean, if every persistence machinery zope 3 uses has to work like the ZODB..19:58
faassenthen what's the point about Zope 3 being able to work easily with external Python systems?19:58
efgemy goal is indeed to simplify the hooks needed19:58
efgebut still have them under the ZODB layer19:58
faassenI 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
RockyBurtefge: 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 api19:58
faassenand I want my queries.19:59
faassenand I want my mapping of existing relational databases into an object model.19:59
flujanfaassen: This is my question... Zope3 can work easily sith any other python programs?19:59
efgefaassen: oh I want them too don't worry :)19:59
faassenI'm not sure how you'd keep those features there if you make it ZODB-like..19:59
faassenI mean, you'd still want to be able to use SQLObject's api.20:00
RockyBurtfaassen: 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 sense20:00
faassenunless you want to invent a whole new way to declare all that, which seems a waste.20:00
faassenthough of course it'd be nice if interfaces/schema and SQLObject declarations could be more alike somehow.20:00
efgeI'll need to add some api for queries of course, I'll check what's available20:00
efgeand I'll use schemas to define the mappings and relational aspects20:01
faassenflujan: 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
efgeanyway that's still beginning of work in progress so I'll tell more in a few weeks20:01
SteveAstub had some plan to make basic generated SQLObject classes from SQL20:01
faassenefge: well, you'll have to extend schemas to express that information.20:01
RockyBurtmy biggest beef is defining mappings in code, i think that should be external20:01
SteveAalong with basic interfaces20:01
faassenSteveA: that's interesting. use the relational database's information on its tables along with schemas.20:01
faassenSteveA: to deduce what the SQLObject declaration would look like.20:02
faassenSteveA: you might be able to get away with less schema annotations then.20:02
efgeyes mapinng the sql schemas to zope 3 schemas is part of my plan20:02
faassenRockyBurt: I don't want to have to write a lot of ZCML to do it either, though.20:02
faassenbut 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
RockyBurtfaassen: for a mapping? but a mapping is precisely configuration which is why zcml was created to begin with20:03
srichterflujan: 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 code20:03
faassenbut a new ORM mapping, I hope not.20:03
*** zagy_ has joined #zope3-dev20:03
andresSteveA, 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
faassenRockyBurt: is a form configuration?20:04
RockyBurtfaassen: depends on what form configuration means ;)20:04
RockyBurtlayout of fields on a form is not form configuration ;)20:04
RockyBurtworkflow actions of a form could possibly be form configuration20:04
faassenRockyBurt: 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 database20:04
efgefaassen: sqlobject is based on classes and metaclasses defining behaviour. zope persistence and storage is based on entirely different things20:04
faassenRockyBurt: so I don't see the value of being able to change that externally.20:04
faassenRockyBurt: 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
RockyBurtbeing 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 that20:05
faassenefge: 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
RockyBurti guess i'm just too much stuck on EJB CMP XML declarations in j2ee because it just made more sense to me20:06
efgewell what if really doesn't match?20:06
faassenefge: I really don't think Zope should be in the business of object relational mappings too.20:06
*** niemeyer has quit IRC20:07
faassenefge: perhaps there's another Python ORM tool that matches better, I don't know. but write a new one?20:07
RockyBurtfaassen: 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 that20:07
faassenRockyBurt: 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 days20:08
faassenRockyBurt: I'm supporting using an existing one which has a lot of thinking and development already in it.20:08
efgefaassen: 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
efgethe impedance mismatch is huge20:09
faassenefge: then we engage those people.20:09
faassenefge: we go talk to them.20:09
*** zagy has quit IRC20:09
faassenefge: and the impendance mismatch is not so huge we're not successfully using it with Five in Zope 2.20:09
RockyBurtfaassen: 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 useful20:09
faassenI disagree that the current efforts are not useful. :)20:09
faassenI agree they can be improved.20:09
RockyBurtsorry, i didn't mean that ;)20:09
efgefaassen: besides I need a mapper that can not only talk sql but also filesystem and LDAP... it's more than SQL20:09
RockyBurti meant they're not as useful as they could be (at least to me)20:09
faassenefge: I need a universal McGuffin too. :)20:10
faassenefge: but it's rather ambitious, such a universal mcguffin.20:10
faassenefge: to abstract over all those storages to me sounds like losing the benefits particular storages offer.20:10
faassenefge: 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
RockyBurtfaassen: such is the compromises with any abstraction layer :)20:11
faassenRockyBurt: sure,  we should extend the current efforts.20:11
faassenRockyBurt: better have something that integrates less seamlessly but offers its own abstractions then.20:11
faassenRockyBurt: you can't seamlessly port your code from ZODB to RDB and back.20:12
faassenRockyBurt: but you can use SQL when you use the RDB backend.20:12
faassenRockyBurt: and the catalog when you use the ZODB.20:12
faassenRockyBurt: 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
faassenRockyBurt: as the assumptions are very different.20:12
faassenRockyBurt: I'm also wondering how desirable that is in the end in practice, being able to do it. not sure.20:13
efgewell we'll see in a month, I've researched existing alternatives and they don't fit the bill20:13
faassenefge: I'm wondering whether your bill is the right one. :)20:14
RockyBurtfaassen: 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
faassenRockyBurt: and how succesful is EJB3?20:14
RockyBurtfaassen: EJB3 isn't released yet ;)20:14
faassenRockyBurt: okay. :)20:14
RockyBurtbut EJB3 is modeled after Hibernate which is extremely popular (and has taken a huge community share away from EJB2)20:15
faassenI mean, why not see this as implementation an dinterfaces?20:15
faassenyou have an interface that says, this thing has this and this attribute.20:15
faassenand you have an implementation, that either subclasses from Persistent.20:15
faassenor subclasses from SQLObject.20:15
faassenthat worries about how to persist things.20:15
faassenif 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
RockyBurtthat means you have to write 2 implementations to support both20:15
RockyBurtwhich is exactly what i'm trying to avoid20:16
faassenRockyBurt: but you'll have to worry about changing your implementation anyway.20:16
faassenRockyBurt: as your query logic will need to change.20:16
faassenRockyBurt: and you'll likely get drastically different performance characteristics.20:16
faassenRockyBurt: if you really are able to do this, I imagine you can regenerate your code using archgenXML.20:17
faassenRockyBurt: I mean, if you *really* have everything declared then you could use such methods.20:17
faassenRockyBurt: 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
RockyBurtfaassen: 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
faassenRockyBurt: well, my ORM lets me use raw SQL if I need to.20:18
RockyBurtORM is already an abstraction that forces you to lose some direct rdbms capability20:18
RockyBurtfaassen: using raw SQL is one thing, being able to define relationships, primary keys, special colum types etc etc is another20:18
RockyBurti've yet to find an ORM that let you control everything (at that point there is no ORM)20:19
faassenRockyBurt: you can define primary keys and relationships with SQLObject..20:19
faassenRockyBurt: don't know how far it goes with special column types.20:19
faassenRockyBurt: I imagine you can extend it if you need to.20:20
faassenRockyBurt: 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
faassenRockyBurt: persistence.20:21
RockyBurtregardless, 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 functionality20:21
faassenRockyBurt: 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
RockyBurtperhaps sqlos should/could be extended to allow for more transparency but still maintain the existing way of doing it20:22
faassenRockyBurt: I agree that we should be able to use SQLObject more transparently. Florent worries me way more with his ambitious.20:22
faassenRockyBurt: ambition.20:22
RockyBurtfaassen: 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 methinks20:22
faassenRockyBurt: 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
RockyBurtagreed, which is a good reason to stick with it20:23
faassenRockyBurt: we already got transparent persistence with the ZODB.20:23
faassenRockyBurt: 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_yorkoops, wrong window :)20:24
faassenRockyBurt: but I'm sure there's much more.20:24
RockyBurtbut 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
faassenbenji_york: oh, It hought you were going to say something profound. :)20:24
andresfaassen, 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 user20:24
benji_yorkfaassen :)20:24
faassenRockyBurt: 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
faassenandres: yes, that would be good.20:25
*** benji_york is now known as benji20:25
faassenandres: j-w and I were talking today about autogenerating a zope 3 schema from SQLObject's declarations.20:25
faassenandres: having to define that stuff twice seems a waste.20:25
RockyBurtandres: after having had this discussion i think that would be the best starting point20:25
andresbecause talking wont bring us further and i guess everyone using sqlos makes his own improvements.20:25
andresbut not in a way that they are usefull for trunk.20:26
faassenandres: I agree that after this we should take some concrete action. :)20:26
RockyBurtjust 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
faassenandres: 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
RockyBurtthats another reason i'd like to keep working with sqlos since sqlos has FiveSQLOS20:27
faassenRockyBurt: yeah, j2ee experience is good to hear in all this.20:27
*** J1m has joined #zope3-dev20:27
faassenRockyBurt: you should post something comparing j2ee and zope one day.20:27
faassenRockyBurt: I'd be interested to hear about this.20:27
faassenJ1m: you just missed the Grant Storage Abstraction discussion.20:28
faassennot Grant.20:28
faassenthat would be something else. then we'd just have a storage abstraction for permissions.20:28
RockyBurtfaassen: 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 people20:28
flujansurely... such article will be very useful to comparison purposes20:28
andresfaassen, 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
faassenRockyBurt: I just want to know about it from a zope perspective. :)20:29
RockyBurtfaassen: i do intend on blogging on it sometime soon so i'll have to keep all of this in mind :)20:29
faassenandres: well, Tres Seaver did a bridge module in Five that makes z3 interfaces out of z2 ones.20:29
faassenandres: 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
faassenRockyBurt: cool20:30
andresfaassen, 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
faassenandres: good point. we'll have to worry about making it happen afterwards.20:32
faassenandres:  that should be doable though, I think.20:32
andresYou dont have that problem with zope2if -> zope3if.20:32
faassenandres: true.20:32
andresfaassen, yes, you can do it afterwards, but then its again not that "transparent"20:33
andresAs you cant use implements and whatnot.20:33
faassenandres: yes, so perhaps we have to reach for higher magic.20:35
*** romanofski has joined #zope3-dev20:35
andresfaassen, it shouldnt be too hard to do with directlyProvides or so.20:35
andresfaassen, all i tried to say, what, that it wont "feel" like a normal interface.20:36
faassenandres: you've done more thinking about this than I have20:36
faassenandres: anyway, this would need more thought and experimentation from my side.20:37
andresBut still, this is one thing, we should note.20:40
faassenandres: yes.20:40
andresProviding a traverser which somehow works with joins would be usefull too.20:41
faassenandres: 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
faassenandres: yes.20:41
andresI have one but its a bit raw.20:41
faassenandres: though on the other hand, zope 3 objects aren't traversable like that on the fly either, unless they're folderish, I guess20:42
andresfaassen, but for me a join is much like a folder.20:43
andresfaassen, and i dont think it should be on by default.20:43
*** ruda_porto has quit IRC20:43
*** ruda_porto has joined #zope3-dev20:44
faassenandres: right.20:44
*** cursor has quit IRC20:45
*** sashav has quit IRC20:47
*** efge has quit IRC20:47
*** sashav has joined #zope3-dev20:53
*** ignas has quit IRC20:59
*** tarek has quit IRC20:59
*** tarek has joined #zope3-dev21:03
*** ruda_porto has quit IRC21:05
*** tarek_ has joined #zope3-dev21:05
*** alga_ has quit IRC21:08
*** faassen has quit IRC21:11
*** Aiste has joined #zope3-dev21:12
*** ruda_porto has joined #zope3-dev21:21
*** mgedmin has quit IRC21:29
*** dman13_ is now known as dman1321:29
*** povbot has joined #zope3-dev22:17
*** MiUlEr has quit IRC22:17
*** mkerrin has quit IRC22:24
*** povbot` has joined #zope3-dev22:46
*** povbot has quit IRC22:53
*** alga has quit IRC22:54
*** projekt01 has joined #zope3-dev23:01
*** romanofski has quit IRC23:06
*** zagy_ has quit IRC23:07
*** povbot has joined #zope3-dev23:31
*** povbot` has joined #zope3-dev23:40
*** J1m has joined #zope3-dev23:43
*** pcardune has joined #zope3-dev23:44
*** alga has joined #zope3-dev23:46
*** natea_ has quit IRC23:51
*** povbot has quit IRC23:52
*** sashav has quit IRC23:58

Generated by 2.15.1 by Marius Gedminas - find it at!