*** jhauser has quit IRC | 00:11 | |
*** benji_york has quit IRC | 00:11 | |
MJ | philiKON: The partial interface + adapter works fine | 00:22 |
---|---|---|
philiKON | good to know :) | 00:22 |
philiKON | thanks for your email on the book example by the way | 00:22 |
MJ | except that I now have to make the container class also contain the partial interface... | 00:22 |
philiKON | haven't looked at the code yet | 00:22 |
philiKON | will do so soon | 00:22 |
MJ | :) | 00:22 |
philiKON | right | 00:23 |
MJ | The example is simple enough... simple mathematics. | 00:23 |
philiKON | yep | 00:23 |
MJ | And just me being pedantic | 00:23 |
philiKON | but maybe already too not-straightforward enough to blur the reader's mind about what's really going on (annotations) | 00:23 |
MJ | BTW, how would one use conflict resolution in zope 3 with adapters like these? | 00:24 |
MJ | Perhaps | 00:24 |
MJ | The goal is illustration, I realize that | 00:25 |
philiKON | dunno about conflict resolution. what do you mean exactly? | 00:25 |
MJ | In z2 zodb you can use app-level conflict resolution | 00:25 |
MJ | we use that with our rating class | 00:26 |
MJ | If thread A reads, then thread B reads and writes, then thread A writes | 00:26 |
MJ | you can have the class patch it up | 00:27 |
philiKON | right. adapters do add some indirecdtion there | 00:27 |
MJ | Exactly | 00:27 |
MJ | So the IAnnotatable cannot resolve the conflict | 00:27 |
philiKON | that's a very good question i'll keep in mind | 00:27 |
philiKON | i presume not the IAnnotatable but the IAnnotations needs to solve the conflict | 00:28 |
MJ | Maybe MVCC make that less of a problem | 00:28 |
philiKON | maybe | 00:28 |
MJ | exatly | 00:28 |
MJ | but the lookup process to detect who is able to resolve it is going to be costly | 00:29 |
MJ | better to retry the whole request perhaps | 00:29 |
philiKON | i'm unsure yet how to such resolving should happen anyway | 00:29 |
MJ | Nope | 00:29 |
MJ | One would have to figure out what changed and who's responsible for those changes | 00:30 |
MJ | tricky | 00:30 |
MJ | Perhaps something for Jim to ponder. | 00:30 |
philiKON | that's what i'm thinking *grin* | 00:31 |
MJ | I, for one, am going to lay that to rest for the night at least.. | 00:31 |
MJ | Bedtime :) | 00:31 |
MJ | Thanks for the help again, Philipp | 00:31 |
MJ | Night all! | 00:31 |
philiKON | night | 00:32 |
*** timte has quit IRC | 00:45 | |
*** roym` has quit IRC | 00:47 | |
*** ruda_porto has quit IRC | 01:12 | |
*** bobessutio has joined #zope3-dev | 02:11 | |
*** deo has quit IRC | 02:25 | |
*** bobessutio has left #zope3-dev | 02:27 | |
*** projekt01 has quit IRC | 02:35 | |
*** epx has joined #zope3-dev | 02:42 | |
epx | hi. | 02:42 |
epx | I have read a book about zope x3 (von Weitershausen's), but I am having some difficult time to see "the big picture" of zope3, applied to making real-world web applications. Anyone knows some working example software I could study? | 02:44 |
d2m | epx: have you looked at the download on the book-webpage ? http://worldcookery.com | 02:52 |
epx | not yet. didn't know where to begin | 03:05 |
epx | thanks! | 03:05 |
*** yota has quit IRC | 03:14 | |
*** ignas has joined #zope3-dev | 03:38 | |
*** epx has quit IRC | 04:12 | |
*** projekt01 has joined #zope3-dev | 04:31 | |
projekt01 | Do the OOBTree and the IOBTree have the same API? | 04:32 |
*** projekt01 has quit IRC | 06:10 | |
*** d2m has quit IRC | 09:43 | |
*** Theuni has joined #zope3-dev | 12:55 | |
*** Alef has joined #zope3-dev | 13:06 | |
philiKON | Theuni, just replied to your email on the german transl | 13:20 |
* Theuni checks | 13:20 | |
*** sashav has joined #zope3-dev | 13:27 | |
MJ | philiKON: I just chucked the partial interface and adapter | 13:27 |
MJ | and moved the DC stuff to the implementation instead | 13:28 |
MJ | Makes it all round cleaner | 13:28 |
philiKON | ok | 13:28 |
philiKON | matter of taste i guess | 13:28 |
MJ | No need to adapt really | 13:28 |
MJ | Also makes the container stuff much cleaner | 13:28 |
MJ | No need to make the editor contain the partial interface as well | 13:29 |
*** Theuni has quit IRC | 13:36 | |
*** sashav has quit IRC | 13:50 | |
*** Theuni has joined #zope3-dev | 13:51 | |
*** andrew_m has quit IRC | 14:06 | |
*** andrew_m has joined #zope3-dev | 14:13 | |
*** projekt01 has joined #zope3-dev | 14:15 | |
*** deo has joined #zope3-dev | 14:23 | |
*** yota has joined #zope3-dev | 14:56 | |
*** philiKON has quit IRC | 15:04 | |
*** philiKON has joined #zope3-dev | 15:11 | |
*** Alef has quit IRC | 16:17 | |
*** Alef has joined #zope3-dev | 16:17 | |
*** Alef has quit IRC | 16:26 | |
*** J1m has joined #zope3-dev | 16:28 | |
*** Alef has joined #zope3-dev | 16:29 | |
*** timte has joined #zope3-dev | 16:57 | |
*** mexiKON has joined #zope3-dev | 17:03 | |
*** Arnia has joined #zope3-dev | 17:12 | |
*** philiKON has quit IRC | 17:21 | |
projekt01 | Hi, J1m, back from holiday? | 17:35 |
projekt01 | J1m, I work together with Julien from nuxeo at the ecm workflow next week. | 17:36 |
J1m | No, just home to mow the lawn and check email. | 17:36 |
J1m | k | 17:37 |
projekt01 | Does your OK for the lxml mean, we can add a branch for the migration and including xpdlcore | 17:37 |
J1m | fow what migration? | 17:37 |
J1m | for what migration? | 17:38 |
projekt01 | ... xpdl core uses lxml and the ecm wmfc package uses xpdlcore | 17:38 |
projekt01 | Right now we use a replacement for zope.wfmc at the ecm project | 17:39 |
projekt01 | zope.wfmc should use xpdlcore which uses lxml in the future, right? | 17:39 |
J1m | I still don't know what migration you are talking about. | 17:39 |
projekt01 | migration/integration | 17:40 |
J1m | Um, I don't really care. | 17:40 |
J1m | I think the rewrite of the xml parser was a waste of time. | 17:40 |
J1m | The sax parser worked fine imo, but of someone else wants to take over maintenance and use a different strategy, that's OK with me. | 17:41 |
projekt01 | I mean this proposal: | 17:41 |
projekt01 | http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/XpdlcoreInclusion | 17:41 |
J1m | ok, I'm -0 on that propsoal. | 17:42 |
projekt01 | Ok | 17:43 |
projekt01 | Cool, have a nice weekend | 17:44 |
J1m | Thanks | 17:44 |
*** sashav has joined #zope3-dev | 18:01 | |
*** mexiKON has quit IRC | 18:02 | |
*** philiKON has joined #zope3-dev | 18:05 | |
*** sashav has quit IRC | 18:11 | |
*** Alef has quit IRC | 18:28 | |
*** J1m has quit IRC | 18:37 | |
*** bskahan has joined #zope3-dev | 18:43 | |
*** roym` has joined #zope3-dev | 20:37 | |
roym` | I need to create a view w/NEXT/PREV buttons for a folder's contents. | 20:39 |
roym` | My plan is to define an Interface with next()/prev() methods, then | 20:39 |
roym` | write an adapter for my content object to the Interface. Has this already | 20:39 |
roym` | been done? | 20:39 |
*** sashav has joined #zope3-dev | 21:37 | |
philiKON | roym`, this is really a matter of the browser view. no need to adapt, i think | 21:41 |
philiKON | what you're talking about is generally referred to as batching | 21:41 |
roym` | philiKON, ok - maybe this is about batching in batches of one... | 21:45 |
philiKON | ah, ic | 21:45 |
philiKON | i misunderstood you | 21:45 |
philiKON | in this case an adapter seems feasible | 21:46 |
roym` | imagine going thru a subfolder of recipes, one at a time. | 21:46 |
philiKON | righ | 21:46 |
roym` | am I right in assuming that I need to grow my own solution here? | 21:47 |
philiKON | an adapter for IContained could yield the next/previous item in its containing parent | 21:47 |
philiKON | yes | 21:47 |
roym` | thanks - that's what I had figured. | 21:48 |
roym` | btw, your RecipeView example (pg 231) inherits from BrowserView. srichters book claims that this is no longer necessary. | 21:48 |
philiKON | well | 21:49 |
philiKON | phone | 21:49 |
roym` | I couldn't however find the way he mentions in his book. | 21:49 |
roym` | sorry - phone? | 21:49 |
philiKON | i'm on the phone | 21:49 |
roym` | ah. | 21:49 |
philiKON | back | 21:54 |
philiKON | well, i don't think BrowserView is deprecated | 21:55 |
philiKON | so, at least that "no longer" is not entirely right | 21:55 |
philiKON | it's correct that it's not necessary | 21:55 |
philiKON | however | 21:55 |
philiKON | for the sake of clarity, I still do it, even in my own code | 21:55 |
philiKON | why? | 21:55 |
philiKON | because it explains, where the __init__ and self.context, self.request come from | 21:55 |
philiKON | zcml is doing too much magic there if you ask me | 21:55 |
philiKON | zcml should be about registering stuff, not about saving two lines of python code that could very well be there and explain (esp. to newbies) a lot | 21:56 |
roym` | agreed wholeheartedly... | 21:56 |
roym` | I find it tedious to restart the engine each time zcml changes. | 21:57 |
*** alienoid has joined #zope3-dev | 21:59 | |
*** sashav has quit IRC | 22:22 | |
*** alienoid has quit IRC | 22:29 | |
roym` | is there a way to register a page in ZCML as an alias for another? | 22:32 |
roym` | I have a view named "xx.html" and I want "index.html" to be the same view without duplicating the declaration. | 22:32 |
philiKON | nay, you'd have to duplicate the zcml directive | 22:43 |
*** bskahan has quit IRC | 22:52 | |
*** bskahan has joined #zope3-dev | 22:59 | |
*** bskahan has quit IRC | 23:26 | |
roym` | I am trying to figure out how to use a python View class to handle | 23:35 |
roym` | both form submission, and display (just like Philipp's RecipeView | 23:35 |
roym` | class). However, I want to render my own ZPT file - how would I do | 23:35 |
roym` | this? Should I define a __call__ method? I don't understand the | 23:35 |
roym` | use of response.redirect(".") in the example.. | 23:35 |
roym` | 23:35 | |
*** bskahan has joined #zope3-dev | 23:39 | |
*** sashav has joined #zope3-dev | 23:41 | |
*** Alef has joined #zope3-dev | 23:57 |
Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!