Re: [Zope-dev] refactoring site functionality
Hi Martijn, Martijn Faassen wrote: > Hi there, > > Wichert Akkerman wrote: > [snip] >> For Plone we regret that we used persistent utilities to store >> configuration: they have made Plone instances much more fragile >> (removing a utiliy's implementation breaks the whole site) and forces >> you to write a UI for the stored configuration again and again. To move >> forwards we have come up with plone.registry (see >> http://pypi.python.org/pypi/plone.registry), which gives you a nice >> central storage system for configuration. > > That's very interesting! > > I can see the benefits of separating this out, though on the other hand > it does introduce more indirection, which is a cost as well. I'm not sure that it does, as such. It's more of a conceptual change. The plone.registry model is kind of like about:config in Firefox. You have a place to create configuration records (values with a schema) and a way to retrieve them. There's still only one level of indirection: find the thing that stores your values, and get them. It's just that instead of calling getUtility(IMyUtility) you call getUtility(IRegistry) and get the values from there. You can, if you want, build your records from a schema for convenience, and get back an object conforming to that schema backed by the registry. However, the registry does not contain any persistent references to your custom code, so it doesn't break if that symbol is no longer importable. plone.app.registry adds a GenericSetup synax + a generic config editor + a base class for building custom "control panel" forms based on the registry. > And the > configuration UI itself could become simpler or at least less scattered > around, so that's a win. At least you can generalise the things that you don't need to expose the user. Like Firefox, there's a control panel for the user-facing stuff, and about:config as a geeky fallback. > I can see how this cost is worth it in large apps like Plone. I'm not > sure about smaller apps, but could be a win too, as you could reuse the > configuration UI. The costs can also be minimized with the use of a > proxy (I saw you have one). Right. There's some value in standardising on a pattern, too. I think if you want some kind of persistent configuration, plone.registry or something like it adds useful consistency and safety. If you don't want persistent configuration, it's obviously moot. > It's definitely an interesting approach. I'll be keeping an eye on it... > > [it's licensed GPL at the moment the pypi page says. Is this going to > change?] Yes, as soon as the Plone Foundatino licensing changes are completed, this will be BSD licensed. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] refactoring site functionality
Hi there, Wichert Akkerman wrote: [snip] > For Plone we regret that we used persistent utilities to store > configuration: they have made Plone instances much more fragile > (removing a utiliy's implementation breaks the whole site) and forces > you to write a UI for the stored configuration again and again. To move > forwards we have come up with plone.registry (see > http://pypi.python.org/pypi/plone.registry), which gives you a nice > central storage system for configuration. That's very interesting! I can see the benefits of separating this out, though on the other hand it does introduce more indirection, which is a cost as well. And the configuration UI itself could become simpler or at least less scattered around, so that's a win. I can see how this cost is worth it in large apps like Plone. I'm not sure about smaller apps, but could be a win too, as you could reuse the configuration UI. The costs can also be minimized with the use of a proxy (I saw you have one). It's definitely an interesting approach. I'll be keeping an eye on it... [it's licensed GPL at the moment the pypi page says. Is this going to change?] Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] refactoring site functionality
Chris McDonough wrote: > On 6/4/09 11:59 AM, Martijn Faassen wrote: [snip] >> I don't think it's complicated. It's nice to install an object somewhere >> that stores data and has a UI and also be able to register it as a local >> utility. If you were to have mutable global configuration, you'd need >> some way to expose it to the UI and content-space too. > > This is true. OTOH, I've never really been keen on the idea that the CA API > should be bent around the idea that you're going to often want to find a > persistent registry. It seems just as reasonable to: > > - put a persistent object someplace (with its own UI) that isn't registered as >a CA utility. > > - find it via the location API when you need it in your code. By location API, you mean something like mycurrentapp()['foo']['bar']? > - *Pass* it to global utilities (or adapters) when you need to vary behavior >based on location. Doesn't this make you have to scatter a lot of location-getting and context-passing code throughout your codebase? I guess it depends on how your codebase is factored. But say you have a utility that sends email, and can be configured with the email address to send it to somewhere in a config screen, you could have 10 places in your code that need to get the configured email address and then pass it to the utility. Now that's probably easy enough to encapsulate in a function, but: * but if you have your configuration right there in the local utility it comes pre-encapsulated. Now you got two bits, one that knows how to send email and one that is being configured. This separation into bits may be right in some cases, but it seems overkill in many. * you're going to have to pass your current application context in each time you want to send email. That's avoided with a utility lookup (as this is implicit). So, I'm having trouble seeing the benefits to this alternative approach, could you explain? Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] refactoring site functionality
Previously Chris McDonough wrote: > On 6/4/09 11:59 AM, Martijn Faassen wrote: > > Wichert Akkerman wrote: > >> Previously Martijn Faassen wrote: > >>> * often it is nice to have application configuration to have a user > >>> interface, so that end users can configure aspects of the application. > >>> This may be filling in an email address or customizing a template or > >>> adding a user, etc. Local utilities are a nice solution for this, even > >>> if there is just a single application installed. > >> That sounds like a complicated workaround for not having a mutable > >> global configuration. > > > > I don't think it's complicated. It's nice to install an object somewhere > > that stores data and has a UI and also be able to register it as a local > > utility. If you were to have mutable global configuration, you'd need > > some way to expose it to the UI and content-space too. > > This is true. OTOH, I've never really been keen on the idea that the CA API > should be bent around the idea that you're going to often want to find a > persistent registry. It seems just as reasonable to: > > - put a persistent object someplace (with its own UI) that isn't registered as >a CA utility. > > - find it via the location API when you need it in your code. > > - *Pass* it to global utilities (or adapters) when you need to vary behavior >based on location. > > Maybe CMF tools weren't such a bad idea. For Plone we regret that we used persistent utilities to store configuration: they have made Plone instances much more fragile (removing a utiliy's implementation breaks the whole site) and forces you to write a UI for the stored configuration again and again. To move forwards we have come up with plone.registry (see http://pypi.python.org/pypi/plone.registry), which gives you a nice central storage system for configuration. Wichert. -- Wichert Akkerman It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] refactoring site functionality
On 6/4/09 11:59 AM, Martijn Faassen wrote: > Wichert Akkerman wrote: >> Previously Martijn Faassen wrote: >>> * often it is nice to have application configuration to have a user >>> interface, so that end users can configure aspects of the application. >>> This may be filling in an email address or customizing a template or >>> adding a user, etc. Local utilities are a nice solution for this, even >>> if there is just a single application installed. >> That sounds like a complicated workaround for not having a mutable >> global configuration. > > I don't think it's complicated. It's nice to install an object somewhere > that stores data and has a UI and also be able to register it as a local > utility. If you were to have mutable global configuration, you'd need > some way to expose it to the UI and content-space too. This is true. OTOH, I've never really been keen on the idea that the CA API should be bent around the idea that you're going to often want to find a persistent registry. It seems just as reasonable to: - put a persistent object someplace (with its own UI) that isn't registered as a CA utility. - find it via the location API when you need it in your code. - *Pass* it to global utilities (or adapters) when you need to vary behavior based on location. Maybe CMF tools weren't such a bad idea. - C ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] refactoring site functionality
Christian Theune wrote: [snip] > I find this pattern to be pretty neutral WRT the web or to locations (as > we know them from zope.location). I think you're describing the pattern of (contextual) acquisition? :) > Unfortunately, I do have to point to a naming thing: the component > lookup methods already support an argument to say where to look for > registries: it's called 'context'. Yes, that's a good point. 'context' is a rather broad term though, perhaps 'acquisition context' would work. :) Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] refactoring site functionality
Hi there, Jim Fulton wrote: [snip] > I think we're talking about 2 different things. > > There is the registry that is "local" to the root object and that is > stored in the database. Having registration data in the database > makes sense for a number of reasons and I don't consider this > advanced. This is effectively a global registry. It doesn't really > matter that it is attached to the root folder. > > Then there are registries sprinkled around the object tree below the > root. These are truly local, because they pertain to a subset of the > object tree. This is the usage that I think we should relegate to an > advanced feature and rethink the goals for. Most importantly, IMO, we > should avoid having this advanced usage complicate the lives of 98% of > developers who don't need it. So if I understand you correctly, when you say 'root' you're talking about the ZODB root, not a particular application's root? And you're suggesting there be only a single db-dependent registry in the ZODB as the basic use case, and that people can register object in the ZODB into that registry? I'm not sure how this simplifies matters very much compared to the current API, which isn't all that complicated in my experience. The one thing I can see is that 'setSite' and traversal hooks could potentially go away. Is that what you're thinking about? Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] refactoring site functionality
Wichert Akkerman wrote: > Previously Martijn Faassen wrote: >> * often it is nice to have application configuration to have a user >> interface, so that end users can configure aspects of the application. >> This may be filling in an email address or customizing a template or >> adding a user, etc. Local utilities are a nice solution for this, even >> if there is just a single application installed. > > That sounds like a complicated workaround for not having a mutable > global configuration. I don't think it's complicated. It's nice to install an object somewhere that stores data and has a UI and also be able to register it as a local utility. If you were to have mutable global configuration, you'd need some way to expose it to the UI and content-space too. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] refactoring site functionality
Hi, On Thu, 2009-05-28 at 17:00 +0200, Martijn Faassen wrote: > Hey, > > [...] > > P.S. As of this point I'm dropping my proposal to rename anything to > anything. Let's indeed focus on the wider discussion (as indicated by > Roger and Jim) (I'm not directly proposing a naming here, I'm just dumping my thoughts on how I think about 'sites' which happen to include a name.) I've been thinking about the concept of 'site' and 'locality' with the terms 'context' or 'focus' for a while to avoid CMSish jargon for my non-CMS applications. In my understanding a context provides deviating policies for the application based on the context's location in the object graph. Let me give you a short example how I use this: in one of our applications we have companies, facilities and people. The application itself provides some global (most times technical) policies, e.g. which views are attached where and what permissions are protecting what attributes. In addition to that when working in the context of companies we can access company-specific services like financial systems interfaces, company-specific statistical parameters, etc. On the level of facilities we still use the same financial system as the company does, but we allow to change statistical parameters for the facility. Person objects do not introduce policy changes but are located within a facility and will thus inherit the policy from them based on them being located within a facility, within a company within the application. I find this pattern to be pretty neutral WRT the web or to locations (as we know them from zope.location). This is basically my 0.02 EUR on the topic. Unfortunately, I do have to point to a naming thing: the component lookup methods already support an argument to say where to look for registries: it's called 'context'. Christian -- Christian Theune · c...@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 7 · fax +49 345 1229889 1 Zope and Plone consulting and development signature.asc Description: This is a digitally signed message part ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] refactoring site functionality
On Thursday 28 May 2009, Roger Ineichen wrote: > btw, you are pointing to a good direction. Didn't we talk > about reload global configuration during runtime years ago? BTW, plone.reload looks really promising. Regards, Stephan -- Entrepreneur and Software Geek Google me. "Zope Stephan Richter" ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] refactoring site functionality
On May 28, 2009, at 11:00 AM, Martijn Faassen wrote: > Hey, > > Jim Fulton wrote: >> 2. I think local configuration address use cases that most people >> don't have but introduce complexity that I bet a lot of developers >> trip over. > > I think there are two cases where people typically deal with local > configuration: > > * setting up local utilities (for authentication, the catalog, > application-specific configuration storage + UI) > > * writing tests that involve local utilities. (a more advanced case, > but > still quite common) > >> 3. I think the right word here is "local registry". I think the >> whole >> concept should be labeled as advanced and we should discourage people >> from even pondering it unless they have a strong use case, like >> wanting to host multiple web sites with different configs in the same >> application. :) > > I don't think "hosting multiple web sites with different configs in > the > same application" is the only use case. > > * the catalog. This can be done using a global component that somehow > stuffs information in the ZODB, but there are no common patterns for > this that people can follow, so local utilities are currently easier > to use. > > * often it is nice to have application configuration to have a user > interface, so that end users can configure aspects of the application. > This may be filling in an email address or customizing a template or > adding a user, etc. Local utilities are a nice solution for this, even > if there is just a single application installed. I think we're talking about 2 different things. There is the registry that is "local" to the root object and that is stored in the database. Having registration data in the database makes sense for a number of reasons and I don't consider this advanced. This is effectively a global registry. It doesn't really matter that it is attached to the root folder. Then there are registries sprinkled around the object tree below the root. These are truly local, because they pertain to a subset of the object tree. This is the usage that I think we should relegate to an advanced feature and rethink the goals for. Most importantly, IMO, we should avoid having this advanced usage complicate the lives of 98% of developers who don't need it. Jim -- Jim Fulton Zope Corporation ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] refactoring site functionality
On 5/28/09 11:00 AM, Martijn Faassen wrote: > Hey, > > Jim Fulton wrote: >> 2. I think local configuration address use cases that most people >> don't have but introduce complexity that I bet a lot of developers >> trip over. > > I think there are two cases where people typically deal with local > configuration: > > * setting up local utilities (for authentication, the catalog, > application-specific configuration storage + UI) I suppose the original reason authentication was made a local utility is for the management UI. I've never actually seen the Zope 3 management UI for authentication data. But FTR, as far as authentication goes, I very seldom require a context-sensitive "user folder" for an application, even if the "application" is actually several instances of the same application in multiple locations. It's pretty hard to create a generally useful management UI for arbitrary authentication sources anyway. They all have slightly different constraints: some are read/write, some are read-only, etc. So I usually end up writing my own anyway or I just rely on an existing UI (direct SQL, ldap browser, etc). It might be easier for developers to understand, at least if no management UI was required, if the authentication service was always just a global utility, and the utility accepted a context in each of its API definitions. Then people who really do need context-sensitive authentication can register a utility that adapted the passed in context as necessary, but a simpler utility would just use global data. The pattern is this: delegate the context adaptation to a global utility and let the developer do as he must in that global utility to return appropriate data based on the context. I suspect a similar pattern would be useful for cataloging, etc. - C ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] refactoring site functionality
Hi Wichert > -Ursprüngliche Nachricht- > Von: zope-dev-bounces+dev=projekt01...@zope.org > [mailto:zope-dev-bounces+dev=projekt01...@zope.org] Im > Auftrag von Wichert Akkerman > Gesendet: Donnerstag, 28. Mai 2009 17:21 > An: Martijn Faassen > Cc: zope-dev@zope.org > Betreff: Re: [Zope-dev] refactoring site functionality > > Previously Martijn Faassen wrote: > > * often it is nice to have application configuration to have a user > > interface, so that end users can configure aspects of the > application. > > This may be filling in an email address or customizing a > template or > > adding a user, etc. Local utilities are a nice solution for > this, even > > if there is just a single application installed. > > That sounds like a complicated workaround for not having a > mutable global configuration. Or the right concept if a Server restart is not an option ;-) btw, you are pointing to a good direction. Didn't we talk about reload global configuration during runtime years ago? Regards Roger Ineichen > Wichert. > > -- > Wichert Akkerman It is simple to make things. > http://www.wiggy.net/ It is hard to make > things simple. > ___ > Zope-Dev maillist - Zope-Dev@zope.org > http://mail.zope.org/mailman/listinfo/zope-dev > ** No cross posts or HTML encoding! ** (Related lists - > http://mail.zope.org/mailman/listinfo/zope-announce > http://mail.zope.org/mailman/listinfo/zope ) > ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] refactoring site functionality
Previously Martijn Faassen wrote: > * often it is nice to have application configuration to have a user > interface, so that end users can configure aspects of the application. > This may be filling in an email address or customizing a template or > adding a user, etc. Local utilities are a nice solution for this, even > if there is just a single application installed. That sounds like a complicated workaround for not having a mutable global configuration. Wichert. -- Wichert Akkerman It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] refactoring site functionality
Hey, Jim Fulton wrote: > 2. I think local configuration address use cases that most people > don't have but introduce complexity that I bet a lot of developers > trip over. I think there are two cases where people typically deal with local configuration: * setting up local utilities (for authentication, the catalog, application-specific configuration storage + UI) * writing tests that involve local utilities. (a more advanced case, but still quite common) > 3. I think the right word here is "local registry". I think the whole > concept should be labeled as advanced and we should discourage people > from even pondering it unless they have a strong use case, like > wanting to host multiple web sites with different configs in the same > application. :) I don't think "hosting multiple web sites with different configs in the same application" is the only use case. * the catalog. This can be done using a global component that somehow stuffs information in the ZODB, but there are no common patterns for this that people can follow, so local utilities are currently easier to use. * often it is nice to have application configuration to have a user interface, so that end users can configure aspects of the application. This may be filling in an email address or customizing a template or adding a user, etc. Local utilities are a nice solution for this, even if there is just a single application installed. > 4. I think we should step back (re)think how we handle the goals that > drive this. If we do, we might come up with something so different > that we'd make this discussion moot. My goals are: * I do care about local component configuration * I'm a simple person and want to make my life easier * I want to be able to write and test local utilities without having to depend on zope.site for my testing (right now I have a hacked up version that I just copy and paste). An example of the hacked up version of site management is here: http://svn.zope.org/hurry.custom/trunk/src/hurry/custom/testing.py?rev=99648&view=auto And I'd like to put that code somewhere proper. * I'd like to change the dependency structure so that a minor dependency on site management doesn't require a package to pull in zope.container (which pulls in quite a bit itself) Regards, Martijn P.S. As of this point I'm dropping my proposal to rename anything to anything. Let's indeed focus on the wider discussion (as indicated by Roger and Jim) ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
