Tahoe wrap-up and next release

[Martin Aspeli]

Hi folks,

I've been looking at the commits and blog posts, and it seems a lot of really great work was done in Tahoe! I'm very excited that Dexterity has had its first dedicated sprint, even if I couldn't be there.

I hope we can use this momentum to drive towards a new release soon. Can people please outline what's left to do?

These are the things I know about:

 - I think the UI for plone.formwidget.contenttree has broken, though it may be a Plone 4/Sunburst issue. The functionality is probably still OK.

 - We need to release new versions of z3c.form, plone.z3cform, plone.app.z3cform, and plone.directives.forms. I can take care of those, although I don't know the status of the changes that went into these packages at the sprint.

 - If there are changes to APIs or new features, we need to update the manuals on plone.org. Everyone needs to help out here, and at least identify what needs to change, if not take responsibility for updating the relevant pages themselves.

 - plone.supermodel needs a new release

See also: http://code.google.com/p/dexterity/wiki/PackageMaintenance

Then, I'm assuming:

 - plone.schemaeditor and plone.app.dexterity will need new releases; are they ready?

 - There's still a test failure related to datetimes, DateTimes and timezones in plone.app.dexterity

 - Is the image scale stuff ready? It'll need to be added to the manual at the very least.

 - Is the new zc.relation-based field for Archetypes ready? Maybe not part of a Dexterity release per se, but it may be useful to put it into the KGS.

Martin

[Ross Patterson]

Martin Aspeli <opti...@gmail.com> writes:

>  - Is the new zc.relation-based field for Archetypes ready? Maybe not part of a
> Dexterity release per se, but it may be useful to put it into the KGS.

See my blog post for details of what was done:

http://rpatterson.net/blog/at-relation-field

I think the gist is not yet. If David finished the
ATReferenceBrowserWidget extension and it gets more test coverage, then
I'd say it's ready for a 0.1. What would your criterion be?

Ross

[David Glick]

On 3/19/10 9:15 PM, Martin Aspeli wrote:

Hi folks,

I've been looking at the commits and blog posts, and it seems a lot of really great work was done in Tahoe! I'm very excited that Dexterity has had its first dedicated sprint, even if I couldn't be there.

Hope to see you at the next one. ;)

I hope we can use this momentum to drive towards a new release soon. Can people please outline what's left to do?

I, at least, have a number of things I need to finish up...

These are the things I know about:

 - I think the UI for plone.formwidget.contenttree has broken, though it may be a Plone 4/Sunburst issue. The functionality is probably still OK.

Yes, I think this is probably related to Sunburst.

 - We need to release new versions of z3c.form, plone.z3cform, plone.app.z3cform, and plone.directives.forms. I can take care of those, although I don't know the status of the changes that went into these packages at the sprint.

There are a couple more adjustments I'd like to make to the slots, based on talking with Alex and Joel.

 - If there are changes to APIs or new features, we need to update the manuals on plone.org. Everyone needs to help out here, and at least identify what needs to change, if not take responsibility for updating the relevant pages themselves.

+1

 - plone.supermodel needs a new release

See also: http://code.google.com/p/dexterity/wiki/PackageMaintenance

Then, I'm assuming:

 - plone.schemaeditor and plone.app.dexterity will need new releases; are they ready?

The work Alex and I did on the UI is on a branch, and not quite done.  I hope to finish it up soon, but I think the work that's been done on trunk is also releasable as is.  I can take care of that when it's time.

 - There's still a test failure related to datetimes, DateTimes and timezones in plone.app.dexterity

Really? I haven't seen that one and it doesn't seem to be showing up in Hudson.

 - Is the image scale stuff ready? It'll need to be added to the manual at the very least.

No, not ready, although Andi has done a lot of the legwork this week in plone.app.imaging for Archetypes.  It should be hard to make a similar adapter for plone.namedfile.

 - Is the new zc.relation-based field for Archetypes ready? Maybe not part of a Dexterity release per se, but it may be useful to put it into the KGS.

I'll defer to Ross and David on this one. :)

David

[Alec Mitchell]

Is this an extension of Products.ATReferenceBrowserWidget (as
indicated in your blog), or archetypes.referencebrowserwidget, which
is what we're shipping with Plone 4? I think the latter would be
preferable for obvious reasons.

Alec

[Ross Patterson]

Alec Mitchell <ap...@columbia.edu> writes:

Definitely, I only meant to say "the reference browser widget once and
sometimes still known as ATReferenceBrowserWidget". :) Though Plone 3
and 4 compatibility would be great. Either way, it's not done yet.

Ross

[Martin Aspeli]

Hi David,

On 20 March 2010 12:56, David Glick <dgl...@gmail.com> wrote:

On 3/19/10 9:15 PM, Martin Aspeli wrote:

Hi folks,

I've been looking at the commits and blog posts, and it seems a lot of really great work was done in Tahoe! I'm very excited that Dexterity has had its first dedicated sprint, even if I couldn't be there.

Hope to see you at the next one. ;)

I hope we can use this momentum to drive towards a new release soon. Can people please outline what's left to do?

I, at least, have a number of things I need to finish up...

These are the things I know about:

 - I think the UI for plone.formwidget.contenttree has broken, though it may be a Plone 4/Sunburst issue. The functionality is probably still OK.

Yes, I think this is probably related to Sunburst.

Okay. We need to fix it at least so that it's on par with what we used to have.

 

 - We need to release new versions of z3c.form, plone.z3cform, plone.app.z3cform, and plone.directives.forms. I can take care of those, although I don't know the status of the changes that went into these packages at the sprint.

There are a couple more adjustments I'd like to make to the slots, based on talking with Alex and Joel.

Ok. Can you outline what you're proposing?

 - If there are changes to APIs or new features, we need to update the manuals on plone.org. Everyone needs to help out here, and at least identify what needs to change, if not take responsibility for updating the relevant pages themselves.

+1

 - plone.supermodel needs a new release

See also: http://code.google.com/p/dexterity/wiki/PackageMaintenance

Then, I'm assuming:

 - plone.schemaeditor and plone.app.dexterity will need new releases; are they ready?

The work Alex and I did on the UI is on a branch, and not quite done.  I hope to finish it up soon, but I think the work that's been done on trunk is also releasable as is.  I can take care of that when it's time.

Ok, so what's on trunk and not in the branch?

How far off is the branch? It does look much nicer in the tahoe-ui branch. ;-)

 

 - There's still a test failure related to datetimes, DateTimes and timezones in plone.app.dexterity

Really? I haven't seen that one and it doesn't seem to be showing up in Hudson.

Try to change your timezone and run the tests, maybe?

 

 - Is the image scale stuff ready? It'll need to be added to the manual at the very least.

No, not ready, although Andi has done a lot of the legwork this week in plone.app.imaging for Archetypes.  It should be hard to make a similar adapter for plone.namedfile.

You mean it should *not* be hard? Any pointers to what we'd need to replicate?

 - Is the new zc.relation-based field for Archetypes ready? Maybe not part of a Dexterity release per se, but it may be useful to put it into the KGS.

I'll defer to Ross and David on this one. :)

It's not crucial for a release. It'd be nice to get this into Plone 4.1, though. :-p

Martin 

[Ross Patterson]

Martin Aspeli <opti...@gmail.com> writes:

>  - Is the new zc.relation-based field for Archetypes ready? Maybe not part
> of a Dexterity release per se, but it may be useful to put it into the
> KGS.
>
> I'll defer to Ross and David on this one. :)
>
> It's not crucial for a release. It'd be nice to get this into Plone 4.1, though.
> :-p

What do you of the next steps/goals I laid out in my blog post? Which
do you think would be appropriate as a 4.1 PLIP?

"Next up is an extension of Products.ATReferenceBrowserWidget which
works with zc.relation. Once that is working, archetypes.schemaextender
can be used with one which uses zc.relation. Finally, a migration can be
to offer a ZCML file which would replace the ATCT relatedItems field
implemented to migrate existing AT references to the zc.relation
back-end."

Ross

[Martin Aspeli]

What you outlined makes a lot of sense. We could incorporate it without the schema extender if it were to go in as a PLIP, but we'd need it to live in a separate package (which means schema extender) for a while and be proven to work first.

The biggest headache is probably migration, if you got the widget to work.

Martin

[David Glick]

On 3/20/10 3:49 AM, Martin Aspeli wrote:

 - I think the UI for plone.formwidget.contenttree has broken, though it may be a Plone 4/Sunburst issue. The functionality is probably still OK.

Yes, I think this is probably related to Sunburst.

Okay. We need to fix it at least so that it's on par with what we used to have.

Any volunteers to look into this one?

 - We need to release new versions of z3c.form, plone.z3cform, plone.app.z3cform, and plone.directives.forms. I can take care of those, although I don't know the status of the changes that went into these packages at the sprint.

There are a couple more adjustments I'd like to make to the slots, based on talking with Alex and Joel.

Ok. Can you outline what you're proposing?

Here are some requests that came up this past week:
1. (from Alex) Make it possible to inject additional markup *outside* the <form> tag.
2. (from Joel) Make it possible to replace the form fields, but keep the header, form tag, and actions.
3. (from Joel) Make it possible to replace just the title or just the description.
4. (from Alex/me) Make it possible to inject markup into the HTML head.

In order to achieve these, I would like to:
1. Add a 'formwrapper' slot surrounding the <form> tag.
2. Add a 'fields' slot surrounding everything within the form tag *except* for the actions.
3. Add 'title' and 'description' slots (these can already be replaced via the form's 'label' and 'description' attributes, but those don'tallow inserting markup).
4. This one is easy for unwrapped forms, but trickier when there's a form wrapper.  We would need to make the form wrapper template check for some attribute on the wrapped form.  I think there's no reason not to complete the 3 above proposals, but this one I'm less convinced is the right solution.

The work Alex and I did on the UI is on a branch, and not quite done.  I hope to finish it up soon, but I think the work that's been done on trunk is also releasable as is.  I can take care of that when it's time.

Ok, so what's on trunk and not in the branch?

A few bugfixes, and Ross' work on supporting Choice fields.

How far off is the branch? It does look much nicer in the tahoe-ui branch. ;-)

I need to re-add support for setting field ids and for reordering fields, to achieve feature parity with the old UI.

 - There's still a test failure related to datetimes, DateTimes and timezones in plone.app.dexterity

Really? I haven't seen that one and it doesn't seem to be showing up in Hudson.

Try to change your timezone and run the tests, maybe?

Can you open a ticket with the test output?

There are also some trivial test failures on Plone 4.0b1 due to Acquisition wrappers repr-ing as <type 'Acquisition.ImplicitAcquisitionWrapper'> rather than <type 'ImplicitAcquirerWrapper'>

 - Is the image scale stuff ready? It'll need to be added to the manual at the very least.

No, not ready, although Andi has done a lot of the legwork this week in plone.app.imaging for Archetypes.  It should be hard to make a similar adapter for plone.namedfile.

You mean it should *not* be hard? Any pointers to what we'd need to replicate?

plone.scale provides a function for doing scaling, and a storage that can create and retrieve scales stored in annotations.  We need to create an adapter that exposes them to traversal and specifies policy about how the images are stored (e.g. in blobs, AT ImageScale instances, etc.) and named (e.g. via configuring scale name => size mappings in the imaging_properties sheet).  We can model this on the adapter Andi has created for AT content in plone.app.imaging.

Note that Andi and I are assuming we'll switch to the new improved approach to referencing scales from templates (see docs on plone.app.imaging's new-scales branch). So at some point the listing templates in Plone need to get updated to use that.  And until then, Dexterity content won't actually show with images in listings, unless we monkeypatch support for the tag method and /image_scalename traversal onto the DexterityContent base class.

 - Is the new zc.relation-based field for Archetypes ready? Maybe not part of a Dexterity release per se, but it may be useful to put it into the KGS.

I'll defer to Ross and David on this one. :)

It's not crucial for a release. It'd be nice to get this into Plone 4.1, though. :-p

We might be able to add it as an option in 4.1.  I doubt we can replace the AT reference implementation wholesale in the 4.x series, unless we also reimplement BBB replacements for the ReferenceEngine, Referenceable mixin, and Reference class (even then, there's probably too much third-party code out there that relies on the AT reference_catalog).

[Martin Aspeli]

Hi David,

On 21 March 2010 02:50, David Glick <dgl...@gmail.com> wrote:

On 3/20/10 3:49 AM, Martin Aspeli wrote:

 - I think the UI for plone.formwidget.contenttree has broken, though it may be a Plone 4/Sunburst issue. The functionality is probably still OK.

Yes, I think this is probably related to Sunburst.

Okay. We need to fix it at least so that it's on par with what we used to have.

Any volunteers to look into this one?

 - We need to release new versions of z3c.form, plone.z3cform, plone.app.z3cform, and plone.directives.forms. I can take care of those, although I don't know the status of the changes that went into these packages at the sprint.

There are a couple more adjustments I'd like to make to the slots, based on talking with Alex and Joel.

Ok. Can you outline what you're proposing?

Here are some requests that came up this past week:
1. (from Alex) Make it possible to inject additional markup *outside* the <form> tag.

To do any kind of custom markup, you need to associate a custom template. With a wrapper-less form, that means you either use plone.directives.form to associate a grokked template in the same way that five.grok does. With non-grokked forms, you can use the 'template' argument to the ZCML directive.

In both cases, markup outside the form is most easily done by just doing a standard template and then using the @@ploneform-macros titlelessform macro.

 

2. (from Joel) Make it possible to replace the form fields, but keep the header, form tag, and actions.

There should be a slot for this already, if not we should add one: just inside the <form> tag, but not including the actions div.

 

3. (from Joel) Make it possible to replace just the title or just the description.

Of a field or of a form? If of a field, that's tricky, in the sense that the standard macro by necessity loops over all fields and outputs the title, description, any error message, and the widget (normally just an <input /> tag). The only thing you can do is customise the as in #2, and output all fields. Unless we invent some new framework, of course.

If of a form, it's easiest to just do a custom template as in #1.

 

4. (from Alex/me) Make it possible to inject markup into the HTML head.

Same as #1

 

In order to achieve these, I would like to:
1. Add a 'formwrapper' slot surrounding the <form> tag.

+0 - I don't know if this is any easier than just customising the template and using the titlelessform macro.

 

2. Add a 'fields' slot surrounding everything within the form tag *except* for the actions.

+1

 

3. Add 'title' and 'description' slots (these can already be replaced via the form's 'label' and 'description' attributes, but those don'tallow inserting markup).

+0 - same reason as above

 

4. This one is easy for unwrapped forms, but trickier when there's a form wrapper.  We would need to make the form wrapper template check for some attribute on the wrapped form.  I think there's no reason not to complete the 3 above proposals, but this one I'm less convinced is the right solution.

I think we should assume forms are unwrapped going forward, and wrapped only for Plone 4 BBB.

 

The work Alex and I did on the UI is on a branch, and not quite done.  I hope to finish it up soon, but I think the work that's been done on trunk is also releasable as is.  I can take care of that when it's time.

Ok, so what's on trunk and not in the branch?

A few bugfixes, and Ross' work on supporting Choice fields.

Cool. Any ETA on when the new UI work may see the light of day? I'd hate for it to be one of those branches that ends up going stale.

 

How far off is the branch? It does look much nicer in the tahoe-ui branch. ;-)

I need to re-add support for setting field ids and for reordering fields, to achieve feature parity with the old UI.

Okay. That doesn't sound too bad. 

 - There's still a test failure related to datetimes, DateTimes and timezones in plone.app.dexterity

Really? I haven't seen that one and it doesn't seem to be showing up in Hudson.

Try to change your timezone and run the tests, maybe?

Can you open a ticket with the test output?

Sure. I'll re-test later, just to be sure.

 

There are also some trivial test failures on Plone 4.0b1 due to Acquisition wrappers repr-ing as <type 'Acquisition.ImplicitAcquisitionWrapper'> rather than <type 'ImplicitAcquirerWrapper'>

Ouch. ;) 

 - Is the image scale stuff ready? It'll need to be added to the manual at the very least.

No, not ready, although Andi has done a lot of the legwork this week in plone.app.imaging for Archetypes.  It should be hard to make a similar adapter for plone.namedfile.

You mean it should *not* be hard? Any pointers to what we'd need to replicate?

plone.scale provides a function for doing scaling, and a storage that can create and retrieve scales stored in annotations.  We need to create an adapter that exposes them to traversal and specifies policy about how the images are stored (e.g. in blobs, AT ImageScale instances, etc.) and named (e.g. via configuring scale name => size mappings in the imaging_properties sheet).  We can model this on the adapter Andi has created for AT content in plone.app.imaging.

Note that Andi and I are assuming we'll switch to the new improved approach to referencing scales from templates (see docs on plone.app.imaging's new-scales branch). So at some point the listing templates in Plone need to get updated to use that.  And until then, Dexterity content won't actually show with images in listings, unless we monkeypatch support for the tag method and /image_scalename traversal onto the DexterityContent base class.

Can we fix this for Plone 4.0b2? Or is that too radical?

 

 - Is the new zc.relation-based field for Archetypes ready? Maybe not part of a Dexterity release per se, but it may be useful to put it into the KGS.

I'll defer to Ross and David on this one. :)

It's not crucial for a release. It'd be nice to get this into Plone 4.1, though. :-p

We might be able to add it as an option in 4.1.  I doubt we can replace the AT reference implementation wholesale in the 4.x series, unless we also reimplement BBB replacements for the ReferenceEngine, Referenceable mixin, and Reference class (even then, there's probably too much third-party code out there that relies on the AT reference_catalog).

Well, I don't think we need to replace the reference implementation wholesale. We just need to replace the relatedItems field. OOTB, Plone doesn't use any other reference fields. In most cases where people use custom reference fields, the vocabulary or allowable reference targets is constrained by application logic, i.e. both ends of the relationship belong to a set of types developed together.

If others need reference fields that can reference arbitrary content and need it to work with non-AT content, they could use the new (once complete) field + widget.

Similarly, there's probably some code out there that assumes we have a UID() method. I'm half tempted to add one to Dexterity (or maybe monkey patch it in, with a view to removing that monkey patch) that returns a str of the intid. It won't collide since AT UIDs follow a different format.

Martin

[David Brenneman]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I'll be working on getting the archetypes.referencebrowserwidget
extension working over the next week, I hope to have it in a releasable
state soon. Is archetypes.referencebrowserwidget Plone 3 compatible?

David

- --

David Brenneman IT Consulting
San Francisco, California
http://davidbrenneman.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkulKvQACgkQJm2k8c05QH1bLQCgn6lUSYKceVE4yBDk05Uwsxwq
MtwAnj5cIYKtHk4iQJ30tYv+JwyOv2zi
=loN9
-----END PGP SIGNATURE-----

[David Glick]

On 3/20/10 7:43 PM, Martin Aspeli wrote:

1. (from Alex) Make it possible to inject additional markup *outside* the <form> tag.

To do any kind of custom markup, you need to associate a custom template. With a wrapper-less form, that means you either use plone.directives.form to associate a grokked template in the same way that five.grok does. With non-grokked forms, you can use the 'template' argument to the ZCML directive.

In both cases, markup outside the form is most easily done by just doing a standard template and then using the @@ploneform-macros titlelessform macro.

Okay, right. I think that works for our use case.

2. (from Joel) Make it possible to replace the form fields, but keep the header, form tag, and actions.

There should be a slot for this already, if not we should add one: just inside the <form> tag, but not including the actions div.

There isn't. I'll add it.

3. (from Joel) Make it possible to replace just the title or just the description.

Of a field or of a form? If of a field, that's tricky, in the sense that the standard macro by necessity loops over all fields and outputs the title, description, any error message, and the widget (normally just an <input /> tag). The only thing you can do is customise the as in #2, and output all fields. Unless we invent some new framework, of course.

If of a form, it's easiest to just do a custom template as in #1.

I meant of a form.  Doing a custom template using the titlelessform macro takes care of the use case for customizing the title.  It's currently harder to customize the description, because it's within titlelessform and after the status and error messages.  So you would end up having to include a lot of elements you're not modifying in your custom template (title, status and error messages, and the form tag).  So I still think a 'description' slot would be helpful.

Cool. Any ETA on when the new UI work may see the light of day? I'd hate for it to be one of those branches that ends up going stale.

It's one of my top priorities for spare-time projects.  So I can't give a date, but it shouldn't be long.

There are also some trivial test failures on Plone 4.0b1 due to Acquisition wrappers repr-ing as <type 'Acquisition.ImplicitAcquisitionWrapper'> rather than <type 'ImplicitAcquirerWrapper'>

Ouch. ;)

I fixed these in five.intid, which will need a new release.

 - Is the image scale stuff ready? It'll need to be added to the manual at the very least.

No, not ready, although Andi has done a lot of the legwork this week in plone.app.imaging for Archetypes.  It should be hard to make a similar adapter for plone.namedfile.

You mean it should *not* be hard? Any pointers to what we'd need to replicate?

plone.scale provides a function for doing scaling, and a storage that can create and retrieve scales stored in annotations.  We need to create an adapter that exposes them to traversal and specifies policy about how the images are stored (e.g. in blobs, AT ImageScale instances, etc.) and named (e.g. via configuring scale name => size mappings in the imaging_properties sheet).  We can model this on the adapter Andi has created for AT content in plone.app.imaging.

Note that Andi and I are assuming we'll switch to the new improved approach to referencing scales from templates (see docs on plone.app.imaging's new-scales branch). So at some point the listing templates in Plone need to get updated to use that.  And until then, Dexterity content won't actually show with images in listings, unless we monkeypatch support for the tag method and /image_scalename traversal onto the DexterityContent base class.

Can we fix this for Plone 4.0b2? Or is that too radical?

As long as we don't break the old scale API for AT content, I wouldn't be opposed to it.  Probably Eric's call.

 - Is the new zc.relation-based field for Archetypes ready? Maybe not part of a Dexterity release per se, but it may be useful to put it into the KGS.

I'll defer to Ross and David on this one. :)

It's not crucial for a release. It'd be nice to get this into Plone 4.1, though. :-p

We might be able to add it as an option in 4.1.  I doubt we can replace the AT reference implementation wholesale in the 4.x series, unless we also reimplement BBB replacements for the ReferenceEngine, Referenceable mixin, and Reference class (even then, there's probably too much third-party code out there that relies on the AT reference_catalog).

Well, I don't think we need to replace the reference implementation wholesale. We just need to replace the relatedItems field. OOTB, Plone doesn't use any other reference fields. In most cases where people use custom reference fields, the vocabulary or allowable reference targets is constrained by application logic, i.e. both ends of the relationship belong to a set of types developed together.

If others need reference fields that can reference arbitrary content and need it to work with non-AT content, they could use the new (once complete) field + widget.

Okay, right.

Similarly, there's probably some code out there that assumes we have a UID() method. I'm half tempted to add one to Dexterity (or maybe monkey patch it in, with a view to removing that monkey patch) that returns a str of the intid. It won't collide since AT UIDs follow a different format.

I need to catch up on the uuid thread. But I think having Dexterity content provide a UID method would make a number of things simpler.  Is there a good reason to use str(intid) rather than whatever algorithm AT content uses to generate a UID, or uuid.uuid4()? A UID is of more value if it's unlikely to collide with UIDs from another Plone site.

David

[Andreas Zeidler]

On 20.03.2010, at 19:50, David Glick wrote:
> We can model this on the adapter Andi has created for AT content in plone.app.imaging.

i think you can pretty much just copy it[1], except perhaps that you might want to use another class for the actual scale instances[2]. i'll wrap up the branch and make releases some time this week, btw.

> Note that Andi and I are assuming we'll switch to the new improved approach to referencing scales from templates (see docs on plone.app.imaging's new-scales branch). So at some point the listing templates in Plone need to get updated to use that.

that point will be plone 4.0, i suspect. i've discussed things with eric, and the old way of referencing image scales, i.e. `.../image_mini`, will remain working, but trigger a deprecation warning. he's even fine with starting to use the new scale urls/storage for old-style scales, so i might do that as well...

> And until then, Dexterity content won't actually show with images in listings, unless we monkeypatch support for the tag method and /image_scalename traversal onto the DexterityContent base class.

i think that's another good reason for doing it now. i'm not sure i will enough time to update and test all the templates, though, but i hope the deprecation warning will help with that… ;)

andi

[1] http://dev.plone.org/plone/browser/plone.app.imaging/branches/new-scales/src/plone/app/imaging/scaling.py?rev=35471
[2] http://dev.plone.org/plone/browser/plone.app.imaging/branches/new-scales/src/plone/app/imaging/scale.py?rev=35471

--
zeidler it consulting - http://zitc.de/ - in...@zitc.de
friedelstraße 31 - 12047 berlin - telefon +49 30 25563779
pgp key at http://zitc.de/pgp - http://wwwkeys.de.pgp.net/
plone 4.0 alpha released! -- http://plone.org/products/plone/

[Andreas Zeidler]

On 21.03.2010, at 22:16, David Glick wrote:
> On 3/20/10 7:43 PM, Martin Aspeli wrote:
>> Can we fix this for Plone 4.0b2? Or is that too radical?
> As long as we don't break the old scale API for AT content, I wouldn't be opposed to it. Probably Eric's call.

like already said in my previous mail, he already called. the new scaling code will be part of 4.0, and perhaps even be used for old-style scale invocations. the main advantages here are added flexibility and unique urls that change with the content and/or scale size definitions. this of course enables image scales to be cached in varnish etc without going back to plone.

andi

[Alexander Limi]

2010/3/20 David Brenneman <d...@davidbrenneman.com>

I'll be working on getting the archetypes.referencebrowserwidget
extension working over the next week, I hope to have it in a releasable
state soon.

We just have to make sure we either merge the UI improvements branch (which I sent the URL for earlier, I'm offline right now :P).

The improvements are quite substantial, and definitely have to make it into Plone 4 to make sure we work well with xdv etc.
 

Is archetypes.referencebrowserwidget Plone 3 compatible?

It should be, but I haven't done any specific styling for it yet in the updated version. It should be fully functional, though. :)

--
Alexander Limi · http://limi.net