Cristopher Ewing <[email protected]> writes: > On Jun 19, 2009, at 12:28, Rob Miller wrote: > > Cristopher Ewing wrote: > > On Jun 19, 2009, at 11:17, Rob Miller wrote: > > you'll definitely want the membrane trunk. > > I was afraid you'd say that. There seems to be a fairly large change > in > how membrane works. We'll probably need to spend a bit of time > re-adjusting, but it does look do-able. > > i don't think it's that big a change, actually. some stuff has been moved > around a bit. here's a brief overview: > > the core of what membrane provides is an adapter infrastructure. membrane > defines certain interfaces. if you create content types that either > provide > one of these interfaces or can be adapted to it, and you register that > type as > a "membrane type", then that content can be used by membrane to provide > user > properties, authentication, roles, groups, etc. > > membrane also provides some default implementations of these adapters. > these > default adapters make it very easy to use AT objects within membrane, > assuming > you want the behaviour that the default adatpers provide. in some cases, > membrane even provides multiple adapters. for instance, in > Products.membrane.factories.properties, there is a Properties adapter > which > will look through the schema for any fields marked w/ "user_property" as > True, > and will use those fields as user properties. but there is also a > SchemataProperties adapter, which instead will call > "getUserPropertySchemata" > on the content, expecting to get a list of schemata names in return. it > will > treat all of the fields in the returned schematas as user properties, > regardless of whether or not the "user_property" value is set for each > field. > > through lack of foresight on my part, all of the default adapters for > membrane > assume that the content in question is AT content. since this is no > longer a > safe assumption to make, membrane has been changed so this is not the > case. > the existing default adapters are still available, but they've been moved > into > an "at" package inside the membrane product. they're still available in > their > location, but you'll get a deprecation warning on import. > > if you want to use Dexterity content, then you'll have to write your own > adapters. maybe eventually some reference implementations will be > provided, > like they are currently for the AT objects. > > all in all, however, the workings of membrane are pretty much the same. > was > there something specific in the recent changes that is a concern? > > -r > > Well, FSD has for the last year or two had membrane support built in. We've > got a > person type that implements the IUserAuthProvider, IPropertiesProvider, > IGroupsProvider, IGroupAwareRolesProvider, and IUserChanger interfaces. > We've got > group types that implement the IPropertiesProvider interface and an adapter > for > them that provides IGroup. These have worked in the way that we use them > since a > pre-1.0 release of membrane way back when it was still an old-style product > rather > than an egg. However, replacing membrane 1.1b5 with membrane trunk and > re-naming > all our imports so that we are getting the interfaces from > Products.membrane.at.interfaces results in something on the order of 30 test > failures, all of them in the membership functions of our package. > > I'm not saying that this isn't our fault. It's possible that we simply need > to > move our own adapters out of the way to make room for the ones that come by > default in the new membrane package, but I am saying that the switch is not > quite > as simple as it reads in the info that Wichert put out about his changes. > This > may well be because we were 'doing it wrong' from the start, but it remains a > fact > that there are some relatively significant changes that we are going to have > to > make to get our product compatible with membrane trunk. > > It might help if you could take a look at the source of FacultyStaffDirectory > and > help us figure out what we're doing incorrectly that makes this switch so much > more difficult for us than for the 'typical' membrane-based package. I wrote > the > original membrane integration nearly two years ago when I was pretty new to > python > and plone and I readily admit it may be problematic. It'd be nice to know > where I > went wrong that lead to this point of difficulty. > > I'm sure that the changes to membrane are needed and good. I fully support > the > changes because they'll allow me to do a lot of things I've been unable to do > in > the past. I'm just a bit sad that such a break in functionality is happening > with > a minor release of Plone, rather than being worked to coincide with the plone > 4 > release. We've been working really hard to get a package out that is synced > to > provide support for the plone 3 branch, and that will not be possible because > of > this change.
I haven't been able to do the detailed review or packaging of wichert's changes yet, but my understanding is that we're thinking of it as membrane 2.0 in which case it seems to me that breaking backwards compatibility is entirely appropriate. This is also in alignment with the changes I proposed after surveying the list so I don't think I can see the FSD issues as being at all related to Wichert's work. I *can* understand your complaint on behalf of FSD as being related to the 1.1 release breaking against Plone 3.3. Even this, however, should be considered against the backdrop of the much older issue of the generally informal and somewhat haphazard testing and releasing of membrane/remember against the entire Plone 3 line. IOW, fixing this is even more unrelated to the recent changes by wichert, the direction of membrane 2.0, or Plone 3.3 specifically. I suggest you cut a branch, backport wichert's 3.3 compat related changes from trunk, and get it to the state you feel is appropriate. I'll then review it as a possible basis for a 1.1 maintenance branch. If we can get it to an acceptable state this would be a good basis for maintaining smoother Plone 3 compatibility. Ross -- Archive: http://www.coactivate.org/projects/remember/lists/remember/archive/2009/06/1245447884357 To unsubscribe send an email with subject "unsubscribe" to [email protected]. Please contact [email protected] for questions.
