Re: [Repoze-dev] anyone know a good editor for BFG book?
Am 14.10.2010, 03:41 Uhr, schrieb Chris McDonough chr...@plope.com: Does anyone know someone with technical editing experience whom would be willing to review and edit the BFG book (the docs in book form) for an upcoming 1.3 release for a reasonable amount of money? - C I think I do. Charlie -- Charlie Clark Managing Director Clark Consulting Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] repoze.bfg random intermittent server errors fetching static resources
Am 19.08.2010, 00:34 Uhr, schrieb Iain Duncan iainduncanli...@gmail.com: However, a lot of the time, seemingly random static request just get served up an internal server error 500 by bfg. I can't see why, sometimes I hit reload and it works. If I copy the url into another browser window, it *always* works. But very frequently a bunch of these static files get returned a 500. Do you get any traceback on the BFG side? Charlie -- Charlie Clark Managing Director Clark Consulting Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] Model-based vs. view-based security
Am 29.07.2010, 10:25 Uhr, schrieb Free Ekanayaka free.ekanay...@gmail.com: I agree that model objects and forms are not generally tight together, even though I'd argue that virtually every web application will need basic CRUD for the core entities. Form inference via schema adapter should be possible but I think there is consensus that interfaces that are schemas can cause more problems than they solve. Convenience versus overhead and confusion. TH I use a UML modeling tool to generate all my models and form schemas so I TH tend not to write much code in these entities. That's interesting, any pointer/link for this specific tool? TH I personally think the form schema is much more about the view than the TH model. Sure, however I believe the issue I was raising is orthogonal to this one. Regardless how tight or loosely the form schema is bound to the model, the authorization for a view in Repoze.bfg can effectively be only True or False, which is simple and nice, but sometimes doesn't fit what you need to do. In those cases you are free to add more to it such as, as Chris said, security proxies. Making this standard adds a lot of overhead to cases where it is totally irrelevant. NB. BFG's openness with regard to storage means you have to think about non-ZODB environments if you wish to have object-level security. Let's make an example. You have a web application for sharing drawings, you can upload drawings and for each drawing decide which other users you want to share that drawing with. If you share a drawing with another person, that other person can perform the same operations as you on it, like tagging it or removing it. Now let's say that you have views that act on collections of drawings, like you could have a view for handling an HTTP request for tagging a certain group of drawings or deleting them. The HTTP request for those views would typically have a parameter holding a list for drawing IDs to act on. How do you define the permission on those views? With a model-based permissions system, you would simply make the view public and let the model raise Unauthorized if you attempt to do something on a drawing you don't have access too. However with a view-based permission system you need to use some other pattern, and I'm not sure what would be best. I would think you would need to add something to your application to handle this (something akin to workflow) but I don't see why you can't stick with security. BFG provides all the necessary hooks for fine-grained security. Regarding Maartijn's discussion of configuration close to the objects. Having grown up with Zope 2 I'm not keen to see declareProtected(), etc. return for this even if you have decorators. Much better, in my view, to have adapters and views implement behaviour and secure these. I guess the only thing that's missing is security aware form generation, ie. the ability to lock down parts of the form. With a form generation library such as deform this can be done at the view level, although it's not ideal. Charlie -- Charlie Clark Managing Director Clark Consulting Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] FrOSCon workshop anyone?
Am 30.06.2010, 10:33 Uhr, schrieb Jan Ulrich Hasecke juhase...@googlemail.com: In the last years we had Plone and Grok workshops which were a great success. This year I would like to offer a BFG-workshop for beginners. Is anyone interested to guide such a workshop? Hi Juh, as discussed I'm happy to be on board with this but as I don't get back from the Oil Slick Sprint until the Friday morning I won't be able to do a whole weekend. Your idea of getting people to work through the tutorials with someone on hand for questions is a good one and, depending on how people get on, extending the wiki by adding search functionality. Are you in touch with the organisers? Do you if they could fit a talk on BFG in? Charlie -- Charlie Clark Managing Director Clark Consulting Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] repoze.zodbconn connection handling
Am 25.06.2010, 20:03 Uhr, schrieb Wichert Akkerman wich...@wiggy.net: I am using repoze.zodbconn in a BFG application but I suspect it is not working as it should be: as soon as multiple requests come in at the same time I get a lot of locking errors and broken results: LockError: Couldn't lock '/Users/wichert/Work/code/buildout/blackbox/var/Data.fs.lock' Hiya Wiggy, I've been getting similar issues when I run checks with ab on a site. I thought it was down to Snow Leopard's notoriously sluggish file system. Is this similar to your environment? Charlie -- Charlie Clark Managing Director Clark Consulting Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] repoze.folder API weirdness
Am 17.06.2010, 11:28 Uhr, schrieb Wichert Akkerman wich...@wiggy.net: I noticed something odd in repoze.folder: __setitem__ does not allow you to replace an existing item. This is a result from __setitem__ being an alias for add(). Is that a deliberate design decision? If not I'ld like to change it to allow replacing items. This is standard behaviour for folders (the not accepting duplicates). I think changing it would be against user expectations. Charlie -- Charlie Clark Managing Director Clark Consulting Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] repoze.folder API weirdness
Am 17.06.2010, 16:08 Uhr, schrieb Tim Hoffman zutes...@gmail.com: I would be concerned if you tried to __setitem__ a new page to replace the existing folder of the same name thus blowing away a whole heap of subfolders and documents in the process. Agreed but mv will let you do this but there are things in the shell that shouldn't necessarily be emulated... Charlie -- Charlie Clark Managing Director Clark Consulting Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] EuroPython sprints
Am 28.05.2010, 16:01 Uhr, schrieb Fergus Doyle fergus.do...@largeblue.com: Hi, Is anyone planning any Repoze EuroPython sprints? While I will be giving an introductory talk on BFG on Wednesday afternoon (looks like it's been scheduled to suit my offer of free beer afterwards) I won't be around for any sprints. Four days of conference away from the daylight in what might be the heat of the English summer is enough for me. But I do like the idea of a general WSGI get together. Charlie -- Charlie Clark Managing Director Clark Consulting Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] EuroPython sprints
Am 03.06.2010, 13:13 Uhr, schrieb Gustavo Narea m...@gustavonarea.net: But I do like the idea of a general WSGI get together. We should probably propose it on Web-SIG mailing list then. Sure. Like I said, I won't be sticking around for any sprints in Birmingham (got to see the family and stuff). I am going to try and get some BFG beer sorted for the conference. I hope there are enough of us at the DZUG bash in Dresden in September. Charlie -- Charlie Clark Managing Director Clark Consulting Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] repoze.org doesn't seem to be responding (at least from Australia)
Am 23.05.2010, 11:28 Uhr, schrieb Tim Hoffman zutes...@gmail.com: Hi Subject says it all.. Anyone else experience it or is it just me Invisible here as well. Maybe they've installed Plone? ;-) Charlie -- Charlie Clark Managing Director Clark Consulting Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] Deform 0.1 released
Am 09.05.2010, 21:23 Uhr, schrieb Chris McDonough chr...@plope.com: Yes. I should just remove the definitions in the glossary because they are actually defined better in the chapter I linked to. Looking much better now. In the Say What? section would it be sensible to trumpet the idea of interfaces/specification which allows Colander and Peppercorn to work together and presumably allows either of them to be replaced if required? Just to say they are unrelated is incorrect as they are related by domain but not interdependent. Looking at the data trip I am vaguely reminded of mathematical transformations and wonder if that metaphor might not be useful in this context - putting the various representations/structures in the CAST quadrants. OTOH I never really understood it back then! Would we have 4 quadrants? Storage, Application, Network and Browser? No idea, I about flunked math. I think I should have done as well but we spent more than half of our time doing past papers so even the monkeys in my class had a fair chance of passing! The improved definitions make this less relevant but essentially we have transitions or changes of state where the fields themselves are transformed/adapted as required. This makes Colander and Peppercorn state managers. FWIW from memory CAST related to signedness in trig functions: C | A - S | T Anything similar would lend itself to a graphical reminder of the relevant state. And finally form controls refers to A sequence of form fields. I find this definition misleading but possibly only because it is too brief. I think form controls were the representation of the fields by the browser, but that this definition comes from GUI-programming as isn't directly relevant here. The distinction I'm trying to make is the raw data given to us as the result of a form submission (currently controls vs. the data that peppercorn returns (pstruct)). See above - the fields change state but stay fields. This is a very fiddly area and something I'm still not 100% on despite Philip von W's extensive coverage of zope.formlib in his excellent book. But that wouldn't fit in the sentence Deform passes a set of form controls to the parse method. Why doesn't it just pass the set of form fields? Because we use the word field elsewhere. I was trying to not overlap the vocabulary. I probably failed in places. Sorry, if this is all to picky at the level of the language. I'll try and provide some more useful feedback with a test application this week as this suits my needs for my planned port of begeistert.org to BFG. Cool. Well, hardly a headline website but one that I've not yet found a really adequate blueprint for. Regarding the demos: http://deformdemo.repoze.org/ It might be an idea to extend them for more adventurous use cases as in z3c.form which has an address book and even a spreadsheet. I'd personally also like to see how images would be handled with previews in edit forms and not having them wiped if nothing new is uploaded. From the doc it looks like the support for this reasonably common use case (and something that requires hacking in zope.formlib) is in deform. This is something I'd like to work on in any sprint. I'd prefer dates not to be in parts as input type=date is in HTML and already nicely supported by Opera. More importantly a single text field is also used by the various JS equivalents. Not sure, however, if there is an easy way to detect this but the parts solution could be offered as an alternative widget (using select for day and month and datalist for the year). Charlie -- Charlie Clark Managing Director Clark Consulting Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] Deform 0.1 released
Am 09.05.2010, 07:50 Uhr, schrieb Chris McDonough chr...@plope.com: This piece of software will be an important piece of any new CMS-ish systems I develop going forward, so it's important to me that I get it right. Therefore, as always, and even more so, feedback on the documentation and demo software is appreciated. Tryouts are even more appreciated. Hi Chris, just flipping through the documentation and things are looking good. I like the fact that schemas avoid the confusion that Zope interfaces as schemas can cause. Nevertheless, it can be convenient to be able to tie them together. As with all libraries of this kind the necessary abstraction requires some new concepts or terminologies. I think I understand and like the appstruct, cstruct and pstruct things (if not the names) but only working with them will let me know. However, the definition of pstruct is either incorrect or misleading: pstruct Data deserialized by Peppercorn to a representation suitable for consumption by a deform deserializer. Usually, when used in deform, a cstruct is composed entirely of lists, dictionaries, strings, and file objects. I guess it should be pstruct in the second sentence. What happens to data going through a form and back is key to understanding what any form library has to do. Charlie -- Charlie Clark Managing Director Clark Consulting Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] Deform 0.1 released
Am 09.05.2010, 16:16 Uhr, schrieb Chris McDonough chr...@plope.com: just flipping through the documentation and things are looking good. I like the fact that schemas avoid the confusion that Zope interfaces as schemas can cause. Nevertheless, it can be convenient to be able to tie them together. I'll definitely be working on a system at some point that generates forms from the definition of a content type. I don't know if those definitions will be done in terms of a Zope interface or not yet. So at this point my attitude is it can be convenient to generate forms from content, which may or may not turn out to be the same thing as it can be convenient to generate forms from Zope interfaces. To make myself clear on this - I agree that convenience is great. Anything that means that schema and interface definition do not have to be duplicated. However, the current elision of the difference that is possible in Zope is not a good thing. As with all libraries of this kind the necessary abstraction requires some new concepts or terminologies. I think I understand and like the appstruct, cstruct and pstruct things (if not the names) but only working with them will let me know. However, the definition of pstruct is either incorrect or misleading: pstruct Data deserialized by Peppercorn to a representation suitable for consumption by a deform deserializer. Usually, when used in deform, a cstruct is composed entirely of lists, dictionaries, strings, and file objects. I guess it should be pstruct in the second sentence. Yes. Fixed, thanks. This leads to the following definitions: Usually, when used in deform, a pstruct is composed entirely of lists, dictionaries, strings, and file objects. Usually, when used in deform, a cstruct is composed entirely of lists, dictionaries, strings, and file objects. Clearly additional explanation is required otherwise pstruct and cstruct seem equivalent where they may only be analogous. Looking at the data trip I am vaguely reminded of mathematical transformations and wonder if that metaphor might not be useful in this context - putting the various representations/structures in the CAST quadrants. OTOH I never really understood it back then! ;-) Would we have 4 quadrants? Storage, Application, Network and Browser? Another area where I find the semantics getting in the way: For each schema node in the schema provided by the application developer, Deform creates a field. This happens recursively for each element in the schema. As a result, a tree of fields is created, mirroring the nodes in the schema. Elements and nodes are interchangeable? If so I would suggest sticking with one term in general and using metaphors consistently: graphs have nodes, trees have leaves and compounds are made up of elements. So that a tree of fields is created which mirrors the tree of elements in the schema or some such as I'm not too happy with that either. I think the important thing is the ability to nest elements of the schema. And finally form controls refers to A sequence of form fields. I find this definition misleading but possibly only because it is too brief. I think form controls were the representation of the fields by the browser, but that this definition comes from GUI-programming as isn't directly relevant here. But that wouldn't fit in the sentence Deform passes a set of form controls to the parse method. Why doesn't it just pass the set of form fields? Sorry, if this is all to picky at the level of the language. I'll try and provide some more useful feedback with a test application this week as this suits my needs for my planned port of begeistert.org to BFG. Charlie -- Charlie Clark Managing Director Clark Consulting Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] imperative configuration prevents application extension?
Am 06.05.2010, 10:10 Uhr, schrieb Chris Withers ch...@simplistix.co.uk: This is spot on, and would, in theory, allow an app to override a library that overrides a framework. Cue lots of Jim like wooah! comments and it's all Chris' fault in the code! ;-) Charlie -- Charlie Clark Managing Director Clark Consulting Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] BFG and GAE
Am 05.05.2010, 17:10 Uhr, schrieb Alex Clark acl...@aclark.net: However I'll mention I see guys like philikon (http://i-luuv.appspot.com) and davisagli (http://buildthreat.appspot.com/) building cool apps on GAE and I can't help but wonder what it would be like if the BFG/GAE story was complete and in place. Please forgive the ignorance but is actually cool about those two sites? Charlie -- Charlie Clark Managing Director Clark Consulting Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] BFG and semi-structured databases (a rant)
Am 04.05.2010, 19:20 Uhr, schrieb Laurence Rowe l...@lrowe.co.uk: I suspect that databases such as CouchDB and the others you mention are not well suited to graph traversal. Efficient traversal must occur near the data, otherwise you pay the latency cost on each edge traversed. In ZODB this is achieved through the object cache - you expect most of the target object's parents to already be present in the cache when serving a request. In other systems traversal happens in the database - for an example see http://highscalability.com/neo4j-graph-database-kicks-buttox. eek! In essence, each traversal along a link in a graph is a join, and joins are known to be very expensive. Whilst agreeing enthusiastically with Laurence's assertion that you need to be close to the data for efficient traversal, I'm baffled by the reference to Neo4j which contains such guff. Regarding the original question: BFG is well-suited to using different persistence strategies depending on use-case and preference. Semi-structured data is, however, an oxymoron albeit a fashionable one. Charlie -- Charlie Clark Managing Director Clark Consulting Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] BFG and semi-structured databases (a rant)
Am 04.05.2010, 23:45 Uhr, schrieb Laurence Rowe l...@lrowe.co.uk: It's worth noting that many RDBMS's do now support recursive queries of some kind (Postgres introduced them in 8.4), though it's not yet ubiquitous. Windowing functions and their ilk might well reinvigorate the RDBMS world. They should by rights revolutionise it but the usual feet-dragging and mutually incompatible implementations will probably put a spanner in the works. It would be interesting to see what sort of performance could be had from a single table adjacency list with metadata stored as json (or a python pickle.). After all, you are not compelled to store normalised data in your RDBMS. Marc-André Lemburg is quite a fan of mixed storage and it can be both fast and intuitive as long as you have considerable control of the client applications accessing the data. If this isn't the case then things can go horribly wrong. Nevertheless, I do find the recent NoSQL databases interesting, mostly for their willingness to relax consistence constraints to achieve higher performance. Yes, but you can always disable constraints on a relational database for the same purpose. For of the inadequacies of SQL should not be used as an excuse for poor application design with no attention to data-modelling. Marc-André will be covering this (selective use of pickles, switching off integrity checking) in his talk on the Ghana VAT project at Europython in July (done in Django essentially without Django). Charlie -- Charlie Clark Managing Director Clark Consulting Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] LMS a BFG application
Am 27.04.2010, 05:52 Uhr, schrieb Srikanth T srikant...@mahiti.org: We would like to share with you, an application we have developed using Repoze.BFG and KARL as basis. We want to contribute this project for Open Source Community. The application, is named as *LMS*( Leave management System ). We wish , LMS can act as a reference , for any one who is interested in learning KARL based repoze applications. You can download, source code from : https://sourceforge.net/projects/mahiti-lms Srikanth, you probably want to add a more detailed description of LMS to the Sourceforge site including use cases and screenshots. Sourceforge has much greater exposure than repoze.org. From a BFG perspective it would be great to have some information why you chose BFG for the project. Charlie -- Charlie Clark Managing Director Clark Consulting Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] imperative configuration prevents application extension?
Am 29.04.2010, 13:32 Uhr, schrieb Chris Withers ch...@simplistix.co.uk: So why the big warnings in the book? They're not warnings but reasoned guidance and developer preference. External configuration à la ZCML was not invented by Zope. XML is verbose but good editor support makes things a lot easier. A poor developer can make that hard even if he uses ZCML as a registration mechanism: he might put all of the registrations in a single ZCML file so that someone who wants to take only some of the registrations must effectively take all of them or none of them. Isn't that what people generally do with zcml and why zcml's overrides ability exists? Obviously something similar could also be done with decorators (just comment out the scan and either do imperative config or ZCML in its place). But with ZCML you can usually just cut, paste, and change. If ZCML was not in the picture, you're often probably going to need to think about converting decorator based registrations into imperative analogues or ZCML instead of cut-paste-change. It's something that's always bugged me and neither zcml nor anything else I've seen allow; the idea of turning off an existing piece of configuration. Disabling configuration rather than removing seems to me an invitation for trouble. But you could probably add a disable directive. Can you provide a real world example? Decorators are a little harder 'cos you can't safely rely on the last one wins philosophy so you end up needing some kind of ordering, or raising an exception if something is defined more than once, which precludes one package customising stuff from another if they both use decorators - which is what I'm ideally aiming for :-/ Which is one of the reasons why declarative configuration has its place. Charlie -- Charlie Clark Managing Director Clark Consulting Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] form generation package recommended for use with BFG?
Am 28.04.2010, 21:05 Uhr, schrieb Chris Withers ch...@simplistix.co.uk: Hi All, Is there anything akin to Django's form generation and handling stuff that's recommended for use with BFG? repoze.formish ? Charlie (fresh from spreading the word of BFG at World Plone Day and slightly worried by the Withers increased in BFG ;-) -- Charlie Clark Managing Director Clark Consulting Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] Feedback / help on i18n/l10n docs...
Am 25.04.2010, 15:19 Uhr, schrieb Chris McDonough chr...@plope.com: (In particular, if you need this feature and you want to volunteer to *finish* these docs, I'd be ecstatic. Chris, this is great news! Is there a timeline for this? I'm hoping to start work on porting my first Zope application to BFG at some point in May and, living in Germany, i18n and l10n are definitely nice to have. Charlie -- Charlie Clark Managing Director Clark Consulting Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] Repackaged PIL 1.1.7
Am 16.04.2010, 17:42 Uhr, schrieb Casey Duncan ca...@pandora.com: activate is a bit of a kludge, though it seems easy enough to just have multiple shells open if activate screws with certain tasks. I'm curious though, how do you switch virtualenvs? I can envision creating wrapper scripts that only pollute the environment for a single process (running it in a subshell or whatever), is that what you are doing? I have to admit I haven't used virtualenv a whole lot, so I'm interested in hearing what you seasoned old timers do ;^) I don't know if I count as an old timer but I've been seriously tripped up by activate. virtualenv just sets up local Python environment for a project. All you then need to remember is to run bin/pip, as opposed to pip to install stuff. So, you don't need to worry about closing the shell or wondering about any side-effects when you do something in the same shell a few days later. activate provides minimal additional convenience at the risk of considerable confusion. Charlie -- Charlie Clark Managing Director Clark Consulting Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] GAE or other 'cloud' choices for bfg apps?
Am 15.04.2010, 15:54 Uhr, schrieb Wichert Akkerman wich...@wiggy.net: Isn 't it incredibly hard to predict costs for cloud services? Not a known and predictable requirement basis. There are problems with some of the cheapest options such as Amazon's new auction-based service. But for anything where large resources are required but time is not a given, it's a good model. Indeed The Economist even recently covered the nascent market for resources. http://www.economist.com/business-finance/displaystory.cfm?story_id=15663898 We will at some point come to forget that Amazon ever sold things apart from CPU cycles! There will be issues about concentration - I remember someone at Europython last year euphorically welcoming the fact that 25% (or relatively high percentage) of all sites are now on one of four providers. A thought that fills me with the collywobbles, I'm not afraid to admit. But hopefully utility computing can find its way into smaller data centres both in-house and down the road. Charlie -- Charlie Clark Managing Director Clark Consulting Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] deprecation of zcml for?
Am 07.04.2010, 15:41 Uhr, schrieb Chris McDonough chr...@plope.com: I noticed in the 1.2 docs that view configuration in zcml uses the 'context' predicate instead of the zope 'for' predicate. Just wanted to know if I can still safely use 'for' or whether new code should switch all those. The for spelling will continue to work forever. After Iain pointed this out I checked the book. View seems to relate to a specific object class rather than interface and I can imagine is a convenience for the very common case where interfaces have only a single implementation. Is this assumption correct? Charlie -- Charlie Clark Managing Director Clark Consulting Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] rss feed
Am 07.03.2010, 17:39 Uhr, schrieb Michael Haubenwallner mich...@d2m.at: hi, i was wondering why the repoze.org feed was not coming up in planetzope - seems it does not validate anymore. Please check errors at http://feedvalidator.org/check.cgi?url=http://blog.repoze.org/rss.xml The RSS feed is okay but the Atom one has gone missing. Charlie -- Charlie Clark Managing Director Clark Consulting Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] [issue139] Chameleon - can't create xml and doctype declarations from macro
Am 04.03.2010, 17:38 Uhr, schrieb Jasper Op de Coul b...@bugs.repoze.org: I don't have commit rights to the repoze repository but I attached a patch. Go on, sign up. You know you want to: http://repoze.org/contributing.html But I think the contribution agreement is a bit lightweight and should be beerware at least! ;-) BTW. Where do website bugs go? Charlie -- Charlie Clark Managing Director Clark Consulting Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
