Re: Re: [Zope3-Users] Re: zalchemy integration
On 8/14/06, Stephan Richter <[EMAIL PROTECTED]> wrote: On Monday 14 August 2006 01:00, Jeff Shell wrote: > If things slow down... uhm, ever... for us, I'd like to see if I can > get us to open up some of the more generic toolkits we've built up in > recent months, as they've been very empowering. You should really do this as you code. Not only do you help out the community, but also yourself, since people will be using the code and make enhancements and help maintaining the code. Further, we are all not duplicating the same stuff. A lot of these are difficult to extract from customer libraries or dependencies on toolkits (also built up internally) that we may not really have license to re-distribute. I know it's probably possible to extricate all of these, but it requires time which is a precious precious precious resource around here lately. I really admire people who share their work because there is a lot of work involved, at least in the initial sharing. Lovely Systems, Roger and I have all been in agreement to publish generic components as we go; if you are subscribed to all check-in messages, you probably saw already a bunch of packages landing in the z3c and lovely namespace. We have tasks setup for this week to open/publish even more packages and extensions. Heh. This past weekend was the first time I actually even got to look in the direction of the zope3-dev and zope3-users lists in two or three months! And those are the only Zope lists I'm subscribed to. Somwhere between working, walking the dog, and sleeping, my life has disappeared. :\ -- Jeff Shell ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: Re: [Zope3-Users] Re: zalchemy integration
On 8/14/06, Stephan Richter <[EMAIL PROTECTED]> wrote: Right, so you fixed the problem with the provider TALES expression, which has to do update()/render() at the same time. My question is: How do you know which content providers are used by a view? Do you manually list them? A Page class (or any provider manager) may optionally list names. The names also provide some ordering support (ensuring that provider A is updated before provider B). If no names are listed in the class, then all Content Providers registered for the page are looked up:: self._content_providers = dict(zapi.getAdapters( (self.context, self.request, self), IContentProvider )) I was thinking about implementing a way to inspect TAL code to determine all the providers that should be looked up before rendering. I even talked to Fred about it already; but it is non-trivial, if I understand him correctly. I wouldn't want to be bound to TAL though. As I mentioned, we use a STAN-inspired system for generating HTML in many places where there's no desire to maintain a separate file just to render something simple - or even moderately complex. As we've also started implementing a system inspired by Rails Helpers which eases some generation of common tasks from formatting to link/URL generation, our need to TAL has decreased. It's still useful in design heavy sites, but I'm really starting to wish for some simplified expressions (even TALES expressions would be nice) to do structured inserts with a helluva-lot-less typing. We still use page templates fairly heavily. I just wouldn't want to depend on TAL code so heavily that any other template/html/xml generation system one wants to plug in really becomes a second or third class citizen at that point. Right, I see you use viewlets/providers heavily; at least we are not the only ones. :-) I would be interested in a lot more dialog here to share best practices and code. We haven't gone into super-heavy usage, but that should start changing this week as we push for the front end UI of this project. Then we'll see if my theories worked :). BTW, another part of the UI power tools is zc.table. I will publish a bunch of extensions later this week. I haven't had too much time to look at `zc.table`. It was a little overwhelming last time I looked at it... I think because of the 'resource library' system being kindof scary. While I haven't pushed my full-Page system concept to its extremes yet, I'm hoping that it can - perhaps - deal with the issues of 'A widget in some form on the page wants to add some javascript or css to the head' issue without badgering the response; something similar to Seaside's `updateRoot` method. -- Jeff Shell ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Re: zalchemy integration
Jeff Shell wrote: 2. There's an 'add to cart' form that is in this page's main template (or other) code, and the user has added something to the cart. The 'update' action of the form adds the item on a post-back. But because it comes *after* the 'cartContents' content provider, the 'cartContents' provider won't show an incremented number until the next stage. We've been calling those "update bugs". -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Re: zalchemy integration
Stephan Richter wrote: > On Monday 14 August 2006 05:27, Philipp von Weitershausen wrote: >> [EMAIL PROTECTED] gets messages to *all* checkins, no matter which >> package. THe problem is that you guys aren't subscribed to >> [EMAIL PROTECTED] so your postings don't show up. > > Yes, I am. I switched on the day the list was created. I know, I was responding to Roger, Jodok, etc. ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Re: zalchemy integration
On Monday 14 August 2006 05:56, Stephan Richter wrote: > On Monday 14 August 2006 05:27, Philipp von Weitershausen wrote: > > [EMAIL PROTECTED] gets messages to *all* checkins, no matter which > > package. THe problem is that you guys aren't subscribed to > > [EMAIL PROTECTED] so your postings don't show up. > > Yes, I am. I switched on the day the list was created. On the other hand, I have been told that my E-mail account is going crazy right now, i.e. rejecting mails. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Re: zalchemy integration
On Monday 14 August 2006 05:27, Philipp von Weitershausen wrote: > [EMAIL PROTECTED] gets messages to *all* checkins, no matter which > package. THe problem is that you guys aren't subscribed to > [EMAIL PROTECTED] so your postings don't show up. Yes, I am. I switched on the day the list was created. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
[Zope3-Users] Re: zalchemy integration
Roger Ineichen wrote: > Hi Mailman > > [...] >>> While we are at it, 'lovely' packages do not show up in >>> http://mail.zope.org/pipermail/checkins until now. >> Mmh, right. Unfortunately I do not have the permissions to fix this. > > If you add lovely to the checkin massages, please add also > the *z3c* top level namespace. [EMAIL PROTECTED] gets messages to *all* checkins, no matter which package. THe problem is that you guys aren't subscribed to [EMAIL PROTECTED] so your postings don't show up. Philipp ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
RE: [Zope3-Users] Re: zalchemy integration
Hi Mailman [...] > > > > While we are at it, 'lovely' packages do not show up in > > http://mail.zope.org/pipermail/checkins until now. > > Mmh, right. Unfortunately I do not have the permissions to fix this. If you add lovely to the checkin massages, please add also the *z3c* top level namespace. Regards Roger Ineichen > Regards, > Stephan > -- > Stephan Richter > CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. > student) Web2k - Web Software Design, Development and > Training ___ > Zope3-users mailing list > Zope3-users@zope.org > http://mail.zope.org/mailman/listinfo/zope3-users > ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Re: zalchemy integration
On Monday 14 August 2006 04:30, Michael Haubenwallner wrote: > Stephan Richter wrote: > > Lovely Systems, Roger and I have all been in agreement to publish generic > > components as we go; if you are subscribed to all check-in messages, you > > probably saw already a bunch of packages landing in the z3c and lovely > > namespace. We have tasks setup for this week to open/publish even more > > packages and extensions. > > While we are at it, 'lovely' packages do not show up in > http://mail.zope.org/pipermail/checkins until now. Mmh, right. Unfortunately I do not have the permissions to fix this. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Re: zalchemy integration
On Monday 14 August 2006 01:00, Jeff Shell wrote: > I (mildly) agree. In my `WebPageSupport` mix-in, I've added a method > `renderProvider`. Primarily it was to get around calling the provider > a second time and having its `update` method called again, although > I've now added some a `hasUpdated` concept to our ContentProvider base > classes. But these are what I've added to our class. Again > `WebPageSupport` is a mix-in (so it can be used with some basice > BrowserView based base classes, as well as some `formlib` base/edit > form based classes) that turns a web page into a ContentProvider > Manager, ensuring that providers that are mentioned in the standard > template(s) as well as ones specifically referenced by a Page are all > updated at the same time:: > > def updateProviders(self): > for provider in self.contentProviders(): > provider.update() > > def renderProvider(self, name): > provider = self.get(name) > if provider is None: > return u"" > return provider.render() > > `updateProviders` is typically called in the `update` phase of the > view/page, and `renderProvider` is typically called in the page > template or other code (like our nevow.Stan / Seaside inspired > system). This behavior is just a little bit more predictable than > `provider:`, is usable outside of TAL/TALES, and jumps straight to > `render` since it's typically being called in the rendering phase of > the surrounding view anyways. Right, so you fixed the problem with the provider TALES expression, which has to do update()/render() at the same time. My question is: How do you know which content providers are used by a view? Do you manually list them? I was thinking about implementing a way to inspect TAL code to determine all the providers that should be looked up before rendering. I even talked to Fred about it already; but it is non-trivial, if I understand him correctly. > (although, we still use `provider:` quite a bit for most of the core > viewlet managers that are used in the main template that have become > practically invisible to us, such as the ones that load up all of the > head resources). Right, I see you use viewlets/providers heavily; at least we are not the only ones. :-) I would be interested in a lot more dialog here to share best practices and code. BTW, another part of the UI power tools is zc.table. I will publish a bunch of extensions later this week. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Re: zalchemy integration
On Sunday 13 August 2006 08:35, Philipp von Weitershausen wrote: > Yeah, I'm not convinced. At least not by the current Boston skin. I find > its code over-structured (subpackages just for the sake of subpackages, > it seems). Also, it isn't as flexible as one would think it is. It > claims it uses viewlets but it has lots of stuff still hammered into a > huge template. I don't find it that much more flexible than Rotterdam. It is a lot more flexible than Rotterdam. It is however constrained by the slots Rotterdam provides, since all the default ZMI views are in reality written for Rotterdam. Roger has developed much more flexible skins that do not conform to Rotterdam slots that have tiny main templates and do everything with viewlets (similar to what Jeff described in his response). Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
[Zope3-Users] Re: zalchemy integration
Stephan Richter wrote: Lovely Systems, Roger and I have all been in agreement to publish generic components as we go; if you are subscribed to all check-in messages, you probably saw already a bunch of packages landing in the z3c and lovely namespace. We have tasks setup for this week to open/publish even more packages and extensions. While we are at it, 'lovely' packages do not show up in http://mail.zope.org/pipermail/checkins until now. Michael -- http://zope.org/Members/d2m http://planetzope.org ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Re: zalchemy integration
On Monday 14 August 2006 01:00, Jeff Shell wrote: > If things slow down... uhm, ever... for us, I'd like to see if I can > get us to open up some of the more generic toolkits we've built up in > recent months, as they've been very empowering. You should really do this as you code. Not only do you help out the community, but also yourself, since people will be using the code and make enhancements and help maintaining the code. Further, we are all not duplicating the same stuff. Lovely Systems, Roger and I have all been in agreement to publish generic components as we go; if you are subscribed to all check-in messages, you probably saw already a bunch of packages landing in the z3c and lovely namespace. We have tasks setup for this week to open/publish even more packages and extensions. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Re: zalchemy integration
On Monday 14 August 2006 01:00, Jeff Shell wrote: > Skinning aside, it's nice to be able to componentize the page. We've > already made some common Viewlets that can be used in a project with > very little fuss, such as Menu renderers. CSS applies most of the > visual styles. The standard template, these days, can usually fit in > as 80 lines of (or less) of nicely structured HTML. Of course, the CSS viewlet base classes come with the package. Roger has recently also checked in base classes for menus. It would be great, if you would contribute your implementations and thoughts to the z3c namespace. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Re: zalchemy integration
On 8/13/06, Philipp von Weitershausen <[EMAIL PROTECTED]> wrote: For the second edition of my book I have implemented a new skin from scratch, using a pure viewlet approach. It was surprisingly simple to do and didn't take a lot of code. The result is very modular. I think a new ZMI skin for Zope (e.g. Boston) should be more like that. All the bits and pieces it has could come from individual viewlets. In the end, the "main" template just decides where the bits and pieces are located. Custom skins can then simply reuse all the viewlets and just move them around in the template as they like. "simply". Isn't there a ban on that word? Or was that just for beer sessions at ZC? :) This application is the first time we've started to really try go with the full-page model. There's a mix-in, ``WebPageSupport``, which basically makes the whole page act like a viewlet manager, thus eliminating the problem of: 1. There's a 'cartContents' viewlet/content provider in the main template. Under normal contentProvider rules, the `provider: ` expression type (or any other method of calling it) would call both `update()/render()` at the same time. 2. There's an 'add to cart' form that is in this page's main template (or other) code, and the user has added something to the cart. The 'update' action of the form adds the item on a post-back. But because it comes *after* the 'cartContents' content provider, the 'cartContents' provider won't show an incremented number until the next stage. We've actually borrowed a few concepts from Rails with their concept of pages having a layout. The layout is basically the typical ``fill-slot="body"`` template pre-filled out, so that the View/Page subclasses just have to provide ``contentForLayout``. Among other things, it makes coding Page Templates a little bit faster as the 'insert header/footer' material, or it's page template equivalent, is removed. A side benefit is that it potentially makes many of these 'pages' could easily be turned into viewlets, into AJAX views, etc, as they all have a method that renders just the guts of that view/page/whatever. Either way, being skeptical of content providers and viewlets at first, I now think they're a great tool. And I've seen from practical experience that they solve lots of skinning problems. I know the Plone guys are rewriting their portlet machinery currently to take advantage of content providers. Very nice. Skinning aside, it's nice to be able to componentize the page. We've already made some common Viewlets that can be used in a project with very little fuss, such as Menu renderers. CSS applies most of the visual styles. The standard template, these days, can usually fit in as 80 lines of (or less) of nicely structured HTML. The `update/render` pairing is just a wonderful concept. For this project we're doing, I got base classes established immediately for pages and views that depended on these methods so that teammates would all use them (or some other common one). It makes views more predictable, and easier to subclass as we can override `update()` to customize view initialization behavior that would previously be done in __init__ (which could then cause confusion if the ZCML directive used was different than what your class sub-classed). Everyone knows to call ``super(, self).update()`` and/or ``super(, self).render()``. There's much less guessing going on with how best to implement a view. These concepts came in from content providers, but it wasn't until I saw the `formlib` code that I really understood their usefulness. I'm still not a big fan of the provider: expression type in TALES. I think it's a misuse of TALES expression types. TALES expression types aren't there to look up things. They are there to express different kinds of expressions: - python: foo.bar - path: foo/bar - string: foobar provider: doesn't fit into that category. In fact, I think it's the only TALES expression that looks up things. Looking up things is the duty of traversal. I really think we should have a provider namespace adapter: I (mildly) agree. In my `WebPageSupport` mix-in, I've added a method `renderProvider`. Primarily it was to get around calling the provider a second time and having its `update` method called again, although I've now added some a `hasUpdated` concept to our ContentProvider base classes. But these are what I've added to our class. Again `WebPageSupport` is a mix-in (so it can be used with some basice BrowserView based base classes, as well as some `formlib` base/edit form based classes) that turns a web page into a ContentProvider Manager, ensuring that providers that are mentioned in the standard template(s) as well as ones specifically referenced by a Page are all updated at the same time:: def updateProviders(self): for provider in self.contentProviders(): provider.update() def renderProvider(self, name): provider = self.get(name) if provider i
[Zope3-Users] Re: zalchemy integration
Roger Ineichen wrote: > We really should use the Boston skin which offers much more > flexibility for such customized ZMI's because of it's > viewlet/manager concept and drop the Rotterdam skin. Yeah, I'm not convinced. At least not by the current Boston skin. I find its code over-structured (subpackages just for the sake of subpackages, it seems). Also, it isn't as flexible as one would think it is. It claims it uses viewlets but it has lots of stuff still hammered into a huge template. I don't find it that much more flexible than Rotterdam. For the second edition of my book I have implemented a new skin from scratch, using a pure viewlet approach. It was surprisingly simple to do and didn't take a lot of code. The result is very modular. I think a new ZMI skin for Zope (e.g. Boston) should be more like that. All the bits and pieces it has could come from individual viewlets. In the end, the "main" template just decides where the bits and pieces are located. Custom skins can then simply reuse all the viewlets and just move them around in the template as they like. Either way, being skeptical of content providers and viewlets at first, I now think they're a great tool. And I've seen from practical experience that they solve lots of skinning problems. I know the Plone guys are rewriting their portlet machinery currently to take advantage of content providers. Very nice. I'm still not a big fan of the provider: expression type in TALES. I think it's a misuse of TALES expression types. TALES expression types aren't there to look up things. They are there to express different kinds of expressions: - python: foo.bar - path: foo/bar - string: foobar provider: doesn't fit into that category. In fact, I think it's the only TALES expression that looks up things. Looking up things is the duty of traversal. I really think we should have a provider namespace adapter: context/++provider++foo.Bar instead of provider:foo.Bar E.g. we we have context/++view++foo.html or context/@@foo.html but not view:foo.html Anyways, just a thought. Philipp ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
[Zope3-Users] Re: zalchemy integration
Hello Carlo.
The implementation of the container is more or less a demonstation on
how to use sqlalchemy object together with a zope container.
To request an object for a zope container a name is used. In the case of
sqlalchemy objects a generalization. This generalization make it
possible to use any database table for the container. To have a unique
name of the objects for the container I use the primary key.
This container implementation is (as you already noticed) not in use
because all use cases we had until now use more special integrations.
Regards
Jürgen
Carlo Cardelli wrote:
David Pratt wrote:
Hi Carlo.
As a workaround to get objects into the db you can comment out the
following lines in checkName like this:
def checkName(self, name, container):
if isinstance(name, str):
name = unicode(name)
elif not isinstance(name, unicode):
raise TypeError("Invalid name type", type(name))
#unproxied = removeSecurityProxy(container)
#if not name.startswith(unproxied._class.__name__+'.'):
# raise UserError("Invalid name for SQLAlchemy object")
return True
I actually worked around it as following:
unproxied = removeSecurityProxy(container)
-> if not ISQLAlchemyContainer.providedBy(unproxied):
-> return NameChooser.checkName(self, name, container)
if not name.startswith(unproxied._class.__name__ + '.'):
raise UserError("Invalid name for SQLAlchemy object")
even if the 'else' case seems unused: i.e., this method is not called
while adding a SQLAlchemyContainer.
Once skipped this, the process halted while adding the 'blank' object to
the db: in zope.app.container.browser.adding, in the method add(), the
following lines failed:
container[name] = content
... one ininfluent-for-this-problem line ...
return container[name]
Here, the last line failed because the SQLAlchemyContainer completely
disregards the "name" attribute (as specified in container.txt), so
retrieving data using the same name is not possible.
Maybe I could spend some time in it, but this "basic" problem leads me
to some doubt about the state of the zalchemy package and its
integration with Zope3.
In the mailing list archives I found some discussion about ORM problems
(2-phase commit, thread support and so on) but nothing specific about
zalchemy, and (as far as I can see) no "definite" solution on the
sqlalchemy integration.
Could someone tell the current state-of-the-art about this, or his/her
experience about integrating sqlalchemy in other ways?
Thank you in advance.
Carlo Cardelli.
___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users
