Re: [Framework-Team] New Products.TinyMCE release
Any chance of another release? I've just made a number of changes to support Dexterity and also fixed a bug in setting the image description. Laurence 2011/2/10 Roel Bruggink : > Eric, all, > I've released Products.TinyMCE 1.2.1 and 1.1.7. I've also edited the Plone > 4.0 and 4.1 dev buildout. > > -- > Roel Bruggink > http://www.fourdigits.nl/mensen/roel-bruggink > > Four Digits BV > http://www.fourdigits.nl > Willemsplein 44, 6811 KD, Arnhem > tel: +31(0)26 4422700 fax: +31(0)26 7600012 > KVK 09162137 BTW 8161.22.234.B01 > > ___ > Framework-Team mailing list > Framework-Team@lists.plone.org > https://lists.plone.org/mailman/listinfo/framework-team > > ___ Framework-Team mailing list Framework-Team@lists.plone.org https://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Final decision on PLIP 9327 (Unified interface for lists of content)
On 4 February 2011 17:45, Geir Bækholt wrote: > On 20-01-2011 16:57, Eric Steele wrote: >> >> I'd like to get a final consensus on whether or not PLIP 9327 will be >> included in 4.1. From discussion last week, several of you wanted to hold >> out until we knew whether collections and search results would be in. At >> this point, it looks like those two will be pushed off for 4.2. > > Just for the record of this thread: I spoke to Eric and the final decision > is to postpone #9327 until we have code actually using it in Plone. > > I think this is fair and sensible. > > I will proceed with making a release on pypi. Then work it into a template > refactoring i am starting - hopefully for 4.2 Great, I'm hoping to use it as soon as possible. A couple of comments from looking at it: * The review_state() as a metho looks out of place. * We need some way to get the object. There is the realobject property/attribute, but that doesn't fit the pattern of the other methods. Maybe this should be getObject()? I've added plone.uuid support now. But we do have some failing tests. I'm assuming these are down to Hanno's ZCatalog changes: Error in test test_batching_folder_contents_2 (plone.app.contentlisting.tests.test_integration_unit.TestFolderContents) Traceback (most recent call last): File "/data/buildout/eggs/unittest2-0.5.1-py2.6.egg/unittest2/case.py", line 343, in run testMethod() File "/data/devel/soschildren/ourafrica/develop/plone.app.contentlisting/plone/app/contentlisting/tests/test_integration_unit.py", line 268, in test_batching_folder_contents_2 self.assertEqual(folderlisting[0].getId(), new_id2) File "/data/devel/soschildren/ourafrica/develop/plone.app.contentlisting/plone/app/contentlisting/contentlisting.py", line 19, in __getitem__ return IContentListingObject(self._basesequence[index]) File "/data/buildout/eggs/Zope2-2.13.2-py2.6.egg/ZTUtils/Batch.py", line 87, in __getitem__ return self._sequence[index+self.first] File "/data/devel/soschildren/ourafrica/develop/plone.app.contentlisting/plone/app/contentlisting/contentlisting.py", line 19, in __getitem__ return IContentListingObject(self._basesequence[index]) File "/data/devel/soschildren/ourafrica/develop/Products.ZCatalog/src/Products/ZCatalog/Lazy.py", line 187, in __getitem__ value = data[index] = self._func(self._seq[index]) File "/data/devel/soschildren/ourafrica/develop/Products.ZCatalog/src/Products/ZCatalog/Lazy.py", line 304, in __getitem__ return self._seq[index][1] IndexError: list index out of range Error in test test_search_with_batching_2 (plone.app.contentlisting.tests.test_integration_unit.TestSearch) Traceback (most recent call last): File "/data/buildout/eggs/unittest2-0.5.1-py2.6.egg/unittest2/case.py", line 343, in run testMethod() File "/data/devel/soschildren/ourafrica/develop/plone.app.contentlisting/plone/app/contentlisting/tests/test_integration_unit.py", line 312, in test_search_with_batching_2 firstbatchitem = searchresultslist[0].getId() File "/data/devel/soschildren/ourafrica/develop/plone.app.contentlisting/plone/app/contentlisting/contentlisting.py", line 19, in __getitem__ return IContentListingObject(self._basesequence[index]) File "/data/buildout/eggs/Zope2-2.13.2-py2.6.egg/ZTUtils/Batch.py", line 87, in __getitem__ return self._sequence[index+self.first] File "/data/devel/soschildren/ourafrica/develop/plone.app.contentlisting/plone/app/contentlisting/contentlisting.py", line 19, in __getitem__ return IContentListingObject(self._basesequence[index]) File "/data/devel/soschildren/ourafrica/develop/Products.ZCatalog/src/Products/ZCatalog/Lazy.py", line 187, in __getitem__ value = data[index] = self._func(self._seq[index]) IndexError: list index out of range Ran 47 tests with 0 failures and 2 errors in 11.990 seconds. Laurence ___ Framework-Team mailing list Framework-Team@lists.plone.org https://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Final decision on PLIP 9327 (Unified interface for lists of content)
On 21 January 2011 17:54, Ross Patterson wrote: > Alec Mitchell writes: > >> On Fri, Jan 21, 2011 at 6:52 AM, Geir Bækholt wrote: >>> On 20-01-2011 16:57, Eric Steele wrote: I'd like to get a final consensus on whether or not PLIP 9327 will be included in 4.1. From discussion last week, several of you wanted to hold out until we knew whether collections and search results would be in. At >> this point, it looks like those two will be pushed off for 4.2. With 5 of 8 votes in, it stands at a +4 for inclusion. Are there any objections to my considering it approved? >>> >>> >>> I was told to prioritise documentation, but i'll be happy to convert default >>> listing templates or portlets to use it. >>> >>> >>> One of the more important cases with contentlisting is to make it easier to >>> start using it as an integrator and that addons can depend on it. For that >>> is important that it is included, not an addon. >> >> That sounds like framework proliferation to me. If an addon wants to >> use this API then they can add it as a dependency; that's not a huge >> burden after all. If either the search improvements or the >> collections were ready, then we'd at least be providing some examples >> of how to use the library in Plone and some indication that it was a >> recommended API. As it is, it just seems to add further confusion to >> Plone's developer/integrator story. > > Agreed. > >> The PLIP had explicitly removed conversion of the templates as a goal. >> Also, it's not entirely clear whether such a conversion would be >> appropriate for a 4.x release, since such changes could break >> customizations which rely on the macros, etc. from the current >> implementation. > > Also, agreed. I agree with the first point (code should only declare a setup.py requirement when it actually uses it), but I would like to see folder_contents change to use this in a future 4.x release - It would be good to use it with an uncatalogued folderish object, e.g. a folder returning items from a database query. Laurence ___ Framework-Team mailing list Framework-Team@lists.plone.org https://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Final decision on PLIP 9327 (Unified interface for lists of content)
On 20 January 2011 19:07, Alec Mitchell wrote: > On Thu, Jan 20, 2011 at 10:52 AM, Ross Patterson wrote: >> Eric Steele writes: >> >>> I'd like to get a final consensus on whether or not PLIP 9327 will be >>> included in 4.1. From discussion last week, several of you wanted to >>> hold out until we knew whether collections and search results would be >>> in. At this point, it looks like those two will be pushed off for 4.2. >>> >>> With 5 of 8 votes in, it stands at a +4 for inclusion. Are there any >>> objections to my considering it approved? >> >> I'm a strong +1 for someone releasing this package to pypi so we can use >> it out in the world, but I'm -1 on including it with core Plone without >> those PLIPs that depend on it being included. I've updated my vote on >> the spreadsheet and that bring the total to +2. > > I feel identically. I've changed my vote on this. If we don't actually use the code there is no point in requiring it. Laurence ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Alec's review of PLIP 10877: Separate Products.CMFPlone from the Plone egg and its optional dependencies
https://svn.plone.org/svn/plone/buildouts/plone-coredev/branches/4.1/plips/plip10877-review-alecm.txt * The PLIP buildout config has an explicit PIL egg dependency, which doesn't appear to exist in the standard buildout. I find this curious. This is because Plone requires PIL but does not specify it as a dependency, and I use plipbase.cfg here as a hack around the buildout.cfg must be in buildout root limitation. I'm hopeful that this can change in the future - I got a positive response to http://mail.python.org/pipermail/image-sig/2010-August/006480.html by private email. Laurence ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Zope 2.13 PLIP ready for review
On 13 September 2010 06:51, Hanno Schlichting wrote: > On Mon, Sep 13, 2010 at 12:35 AM, Alexander Limi wrote: >> Do we expect Plone 4.1 / Zope 2.13 to be using Python 2.7 by default? (makes >> sense to me, but not sure if it has other implications that I'm unaware of) > > See > http://svn.plone.org/svn/plone/buildouts/plone-coredev/branches/4.1/plips/plip10776-zope213.txt > where it says: > > Not in scope > > > While Zope 2.13 supports both WSGI and Python 2.7 it is not part of this PLIP > to support either of them. Support for these might be added in Plone 4.2. > > > In order to support Python 2.7 properly, there's more work to be done > and this really needs more testing. I know of some buildout recipes > that aren't compatible yet and I expect other commonly used libraries > to need some minor updates. I'd rather see the community try it out > and fix the problems one by one before we claim official support for > it. While I would like to see Python 2.7 compatibility in a later Plone 4.x release, I would be uncomfortable requiring it during the 4.x line without very good reason - Python2.7 is still new and only just being picked up by distributions (Ubuntu 10.04 LTS does not include it for instance). Being able to run Plone with a vendor supplied python makes deployment much simpler. Laurence ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Plone roadmap
On 6 September 2010 03:01, Sidnei da Silva wrote: > If I'm allowed to get one suggestion in there: > > On Thu, Sep 2, 2010 at 3:39 PM, Laurence Rowe wrote: > >> WSGI >> >> >> Various components should be move out of Plone and into the WSGI >> pipeline. This should allow us to share code with other projects. >> Prime contenders would be: >> >> * Authentication >> * Resource registries > > One thing I would like to see, and would likely be a small (though > effective) improvement, specially for Plone would be: > > * Flushing the Document Early (as described by: > http://www.stevesouders.com/blog/2009/05/18/flushing-the-document-early/) > > I *think* we should be able to get the whole (or most of the) > tag flushed out to the browser (maybe with > Transfer-Encoding: chunked, by way of RESPONSE.write() or similar WSGI > majik). If you think about it, for the great majority of Plone sites > that part of the page is fairly static, except maybe for the > tag and some metadata. If we could get it far enough so that the > browser starts fetching the CSS and JS resources while Plone does it's > thing to render the rest of the page, it would be a great win already. I fear this would be difficult to implement. Before being able to flush we need to be sure of the HTTP status code and that no more headers need to be sent for example when would we know to send a 302 redirect to a login form. Does this work for traversal based systems? In the php example he cites, flushing before database calls is trivial to implement. By the point we were in a position to flush, would any time be saved or would most of the database loads (that cause the worst slowdowns) have occurred already? ZPT is slow, but Chameleon will bring significant improvements on template rendering time. Assuming we were able to flush, would it make any difference to rendering time if the resources were already cached on the browser? If resource parsing time is not significant here, ensuring landing pages are cached in a proxy seems a simpler solution. Laurence ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Plone roadmap
On 5 September 2010 20:01, Laurence Rowe wrote: > On 5 September 2010 19:17, Martin Aspeli wrote: >> On 5 September 2010 15:29, Hanno Schlichting wrote: >>> - Once we have intid's we can change the internal unique id of the >>> catalog from the physical path over to an intid. >> >> Perhaps we should consider using UUIDs instead of intids? > > We want to use intids because it is more efficient to intersect sets > of integers. They are only an implementation detail though, and it > should be possible to zap and rebuild your catalogue (assigning > different intids) without problems. > >>> >>> - Once we have parent pointers we can probably ditch storing metadata >>> in the catalog and load objects directly. >> >> Why do __parent__ pointers help here? > > With __parent__ pointers you can pull an object directly out of the > ZODB complete with it's location context. That means fetching the > title and description for an item is usually just an object load. > > What's not so clear about this is how we index an object's path and > it's allowed roles and users for the view permission. We should be > able to learn from Zope3 here though. > > Tthere are balances to be struck between read and write efficiency here. It's worth noting here that the overhead of constructing the full location chain from a content item to the application root is much cheaper following __parent__ pointers up than traversing down the hierarchy. At each level of traversing you load the content object itself and search the BTree for the child (loading several BTree objects). With __parent__ pointers you can directly load each parent. I think this means that we probably won't have to worry about providing a cached absolute url metadata lookup or even cached roles and users as metadata - as these will only be calculated for a page's worth of content items. We will of course need an index on allowed roles and users and probably a descendants index (which zc.relation might provide), though only for those particular 'sections' to which searches are restricted. Laurence ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Plone roadmap
On 5 September 2010 19:17, Martin Aspeli wrote: > On 5 September 2010 15:29, Hanno Schlichting wrote: >> - Once we have intid's we can change the internal unique id of the >> catalog from the physical path over to an intid. > > Perhaps we should consider using UUIDs instead of intids? We want to use intids because it is more efficient to intersect sets of integers. They are only an implementation detail though, and it should be possible to zap and rebuild your catalogue (assigning different intids) without problems. >> >> - Once we have parent pointers we can probably ditch storing metadata >> in the catalog and load objects directly. > > Why do __parent__ pointers help here? With __parent__ pointers you can pull an object directly out of the ZODB complete with it's location context. That means fetching the title and description for an item is usually just an object load. What's not so clear about this is how we index an object's path and it's allowed roles and users for the view permission. We should be able to learn from Zope3 here though. Tthere are balances to be struck between read and write efficiency here. Laurence ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Plone roadmap
On 5 September 2010 18:47, Chris McDonough wrote:
> On Sun, 2010-09-05 at 18:18 +0200, Hanno Schlichting wrote:
>> On Sun, Sep 5, 2010 at 5:46 PM, Wichert Akkerman wrote:
>> > On 2010-9-5 17:29, Hanno Schlichting wrote:
>> >> PluggableAuthService
>> >> --
>> >>
>> >> There's tons of code based on this. I imagine we can first move the
>> >> authentication API's into a WSGI middleware querying PAS as the
>> >> backend.
>> >
>> > This sounds like the mistake repoze.who 1 made. It turns out that for
>> > almost every use case you want more control over handling login
>> > behaviour than WSGI middleware can provide. It is much simpler to have a
>> > simple API to an AAA service and use that than to try pushing this into
>> > middleware.
>>
>> Right, I'm aware of the repoze.who lessons. Authorization is always
>> going to be a WSGI framework component ("endware") and not an isolated
>> middleware. But there should be some subpart of the API, which allows
>> you to share the same authorization information across multiple WSGI
>> applications. Or deal with some of the external authorization
>> handling, when you offload things to Apache or other SSO approaches.
>>
>> But I'm not familiar enough with this topic to know what exact subpart
>> this is. It might come down to just the userid.
>
> r.who 2 actually allows you to dial responsibilities up and down. You
> can use "full stack" middleware that lends it effectively the same
> responsibilities as r.who 1, or you can use only the r.who "API" portion
> in an app or you can combine the two approaches as necessary. See also
> http://docs.repoze.org/who/2.0/narr.html#using-repoze-who-without-wsgi-middleware
>
> The particular pain point you should never run into, because it is truly
> horrible: don't try to do any login form post handling in an
> "identifier". Just allow the application to render a self-posting login
> form and use "the API" to check credentials and set headers and so on,
> rather than putting the login form handling itself into middleware
> machinery. In particular, never do anything remotely like the
> "RedirectingForm" plugin within
> http://svn.repoze.org/repoze.who/trunk/repoze/who/plugins/form.py (it
> wants to be the target for a login form post).
>
> Aside from that (which is a problem for people of any competence level),
> most of the problems with the middleware approach stem from needing to
> explain how the middleware approach works to integrators of widely
> varying competence levels. Each has his own slightly varying
> requirements, and each needs the middleware approach to be explained to
> him within that context. This has been a truly painful task for me, but
> that's more an indictment of my level of patience than it is of r.who or
> things like it.
I'm tempted to say that the login form should be a separate
application end point to the CMS. Authentication is something that can
and should be shared across multiple applications - it's much easier
to maintain a number of smaller focussed applications than one large
monolithic one.
Laurence
___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Plone roadmap
A few more points: Security The current AccessControl security model has served us well. While some simplification may be possible by dropping unused legacy features, no major changes to functionality should be expected. Porting to Python 3 will be the obvious time to make any simplifications. The ZODB While it is unfamiliar to new developers, building on top of ZODB is hugely beneficial to Plone. Semi-structured content management data just doesn't map well to relational databases. That said, by reducing our expectations on content types, it should become easier for add ons to integrate relational database backed content into Plone. Portlets and Viewlets - Portlets and viewlets are powerful concepts but they have proved a difficult stumbling block for new developers. The Deco project is working increased layout flexibility for content editors. It also makes it much easier to create dynamic page fragments in the form of 'tiles'. These will replace portlets and most current uses of viewlets. Laurence ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Plone roadmap
On 2 September 2010 22:16, Martin Aspeli wrote: > Hi Laurence, > > +1 to everything here. > > Other big things for me: > > - I think we want Deco GUI + Blocks rendering as an optional add-on > for Plone 4.x at some point, to get this tested properly. We certainly want more people to start using it and use it for customer projects. It does represent an invasive and radical change from the status quo, so it is much more of a risk to include in 4.x as a supported add-on than Dexterity for instance. It's certainly something we need to talk about more. (And in response to Roel, I'll certainly be at the conference and keen to talk about it there.) > - I think we want WSGI as a supported deployment option in 4.x, 5.0 > at the latest, via the Zope 2.13 WSGI work WSGI capability will be in Zope 2.13 / Plone 4.1 and while it will certainly be considered experimental rather than supported at first, I expect people will start gaining experience with it. I'm hopeful that we might be able to *require* wsgi for 5.0, but that will depend on how things work out over the next year or so with 4.x. Laurence ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Plone roadmap
With the release of Plone 4.0, I thought it would be useful to set out my understanding of where we are headed with future releases. This draws heavily on conversations with Hanno and focuses on infrastructure rather than user visible changes. The intention is to spark a discussion from which I'll write up a roadmap on plone.org or dev.plone.org. All plans are of course subject to change - but it is useful to set out a direction. Over the years, Plone has accrued much code and added many concepts. In part this is a reflection of the vibrancy of the project, but it has come at a high cost in complexity. Hanno has been doing heroic work with Zope 2 and the ZTK recently, and we will soon be able to completely avoid the large chunks of old Zope 2 code we do not use at all. Acquisition --- Acquisition was introduced because the ZODB did not support reference cycles. As a programming paradigm though – at least in the implicit form used within Zope 2 – it has been a failure. It is strange and unfamiliar to new developers. It also prevents us from using some natural patterns: the catalogue indexes content by path rather than directly; references between content must be indirected through a path. Phillip and Hanno's work to enable Acquisition over __parent__ pointers (included in Zope 2.12 / Plone 4) has given us a path out of our current dependency on it. This has already simplified BrowserViews. The next step is to make sure all content has __parent__ pointers all the way to the application root. We should do this for Plone 5 and drop Acquisition entirely in a future version. http://wiki.zope.org/zope2/SetParentAndNameInOFS Catalogue and References Once all content has __parent__ pointers to the root, we will be able to use standard ZTK catalog components. Using zope.intid for the catalogue keys allows result sets to be merged across catalogues. We'll also be able to store relations as simple references on content - related items can be stored as a simple list of objects on a piece of content. These can then be indexed in zc.relation directly. Archetypes -- Plone 5 should be the last major release with Archetypes compatibility. For form based content types, Dexterity is the future. The Publisher - The Zope2 publisher has become incredibly complex, with numerous different hooks. In the long run (Plone 6?) we should replace it with our own simplified publisher which runs only in a WSGI pipeline. There will be a lot to learn from BFG here, though that is probably too simplistic for Plone. OFS and CMF --- Currently, all Zope2 content inherits OFS.SimpleItem. All Plone content also inherits from CMF. In the long run, content items should have simple classes with code in views. These are significant changes and are likely to be the most difficult. Restricted Python - This is another confusing hurdle for new developers and should be abandoned. Form Controller --- Other than the Archetypes edit forms, it would be best to remove all other uses. Tools - The various tools should become utilities and views. Most of them need not be persistent as settings can be stored with plone.registry. Skins - Old style templates should be replaced with views. CSS/JS/Images should all migrate to resource directories. Python 3 In three to five years time we will have to have moved to Python 3. It seems likely that there will be others to help the ZTK porting effort, but little interest in porting Zope2. For the time being then, our focus should be on progressively removing our Zope2 baggage. WSGI Various components should be move out of Plone and into the WSGI pipeline. This should allow us to share code with other projects. Prime contenders would be: * Authentication * Resource registries Laurence ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] PLIP #10778 (UUIDs) - ready for initial review
On 30 August 2010 12:46, Maurits van Rees wrote: > Op 29-08-10 07:24, Martin Aspeli schreef: >> plone.uuid provides a simple API for generating and accessing UUIDs. > > If we use this to create uuids for non-content items, that cannot be > traversed to, would that give any problems? > > For example, it might be nice to use this to create the secrets that the > password reset tool sends out, or secrets used in a newsletter product. > I had a few ideas some months back that may or may not ever get > implemented. ;-) > > I'd guess that, as long as such a non-content item with a uuid does not > end up in the portal_catalog, there is no way to accidentally try to > traverse to such non-content. There would be no need to involve plone.uuid here. Just use the uuid4 function from the standard library. Laurence ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] PLIP #10961 File uploads to folder_contents
On 24 August 2010 12:19, Hanno Schlichting wrote: > On Tue, Aug 24, 2010 at 12:16 AM, Laurence Rowe wrote: >> On 23 August 2010 18:18, Geir Bækholt · Jarn wrote: >>> On 23. aug. 2010, at 16:09, Laurence Rowe wrote: >>>> I've added downloading multiple files as a zip archive to the proposal. >>>> >>> Isn't that really something completely different than mass uploading? >>> Separate plip? >> >> I persuaded myself that I could lazily add it to the same PLIP as it >> could be thought of as part of the same 'story' - using Plone for >> basic document management if you could upload a bunch of attachments >> then you should be able to download them. That, and I stole both ideas >> from Gmail ;) > > We had this type of download functionality since Plone 3. The code in > ATConentTypes was unfinished though and we removed it for Plone 4. > > I haven't ever seen anyone interested in this type of feature and > never seen a user request it. > > I would recommend to leave this part out and concentrate on the upload > functionality. That's something a lot more people actually want. Ok, I've removed this for now. Laurence ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] PLIP #10961 File uploads to folder_contents
On 24 August 2010 13:05, Wichert Akkerman wrote: > On 8/24/10 13:55 , Martin Aspeli wrote: >> This is the kind of feature that's more fun to think of and implement >> than it is actually useful to anyone. Those who need archive download >> functionality usually have very specific reasons for wanting it, and >> typically do not want to allow people to arbitrarily pick files from >> the folder_contents listing. > > Isn't the FTP interface much easier for those people anyway? FTP / Webdav is always a pain to set up. You have to explain to someone both how to use an FTP/Webdav client and also why the folder structure is rooted differently to their website. Laurence ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] PLIP #10961 File uploads to folder_contents
On 23 August 2010 18:18, Geir Bækholt · Jarn wrote: > On 23. aug. 2010, at 16:09, Laurence Rowe wrote: >> I've added downloading multiple files as a zip archive to the proposal. >> >> Laurence > > Isn't that really something completely different than mass uploading? > Separate plip? I persuaded myself that I could lazily add it to the same PLIP as it could be thought of as part of the same 'story' - using Plone for basic document management if you could upload a bunch of attachments then you should be able to download them. That, and I stole both ideas from Gmail ;) Laurence ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] PLIP #10964 Asynchronously fetch suggestions for 404 Not Found page
https://dev.plone.org/plone/ticket/10964 Motivation: Search engines indexing your site and bots trawling for ASP/PHP security holes can add a significant load to your site. Plone's 404 Not Found page is slow to render as it performs a catalogue search, which exacerbates the problem. Proposal & Implementation: Change the not found template to fetch the suggestions asynchronously so only humans see the results. Laurence ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] PLIP #10961 File uploads to folder_contents
On 21 August 2010 19:10, Laurence Rowe wrote: > I've added a plip for file upload / multiple file upload / drag and > drop file upload functionality to folder_contents. > > https://dev.plone.org/plone/ticket/10961 I've added downloading multiple files as a zip archive to the proposal. Laurence ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] PLIP #10961 File uploads to folder_contents
I've added a plip for file upload / multiple file upload / drag and drop file upload functionality to folder_contents. https://dev.plone.org/plone/ticket/10961 ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] PLIP #10877 - Separate Products.CMFPlone from the Plone egg and its optional dependencies
On 9 August 2010 11:48, Laurence Rowe wrote: > I've added a PLIP for separating out the optional dependencies from > Products.CMFPlone: https://dev.plone.org/plone/ticket/10877 I've created branches and a PLIP buildout. For the time being the optional dependencies are still in the Products.CMFPlone egg. The process of moving and verifying exactly which packages are optional can take place over the 4.1 cycle. I've also created a forward compatibility shim for Plone 4.0/3.3 so that add-on packages can be created that work with 4.0 and 4.1 without pulling in all the optional packages. I think we should consider adding this to the 4.0 versions.cfg. Links at https://dev.plone.org/plone/ticket/10877 Laurence ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Merging strategy for many PLIPs
In the 4.0 cycle, PLIP branches were merged in one 'big bang' after our implementation review. It was a painful process last time, with 30 PLIPs I don't think it will realistically work this time. Instead of a single deadline, I propose that we ask PLIP implementors to submit their PLIP for implementation review and merging as soon as their PLIP is ready - many are already close to complete as they rolled over from 4.0. At an appropriate point we'll draw the line and the remaining PLIPs will be retargeted at 4.2 (with their in-principal approved status kept.) I think this could help better spread the load on us (and in particular on Eric.) Laurence ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] PLIP Dependencies
As an aid to our discussions, I've gone through the 4.1 Plips and documented the dependencies here: http://spreadsheets.google.com/ccc?key=0AiXg-nyMaQhedENVVllTbDhpb2p4ekU2aGZvd3FFVlE&hl=en&authkey=CNj4jckN Laurence ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Our next meeting – PLIP-a-tho n part 1
On 16 August 2010 10:08, Matthew Wilkes wrote: > > On 2010-08-12, at 2042, Eric Steele wrote: > >> We've got 30 PLIPs in for 4.1 already >> (http://dev.plone.org/plone/report/24), so it's time to get together and >> start talking. Can I assume that next Tuesday at 14:00 UTC will work, or >> should I set up another Doodle thing? > > That's going to be difficult for me this time (and very much sub-optimal in > general), but I can make it. Note the later email: >> Bah. You're right. I can't add properly. That'd be 18:00 UTC, the same time >> as our last meeting. >> >> Eric Laurence ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] PLIP #10877 - Separate Products.CMFPlone from the Plone egg and its optional dependencies
I've added a PLIP for separating out the optional dependencies from Products.CMFPlone: https://dev.plone.org/plone/ticket/10877 Laurence ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] z3c.form PLIP?
On 9 August 2010 01:52, Martin Aspeli wrote: > Hi, > > On 8 August 2010 20:33, Hanno Schlichting wrote: >> Hi. >> >> My controlpanel PLIP 10359 (http://dev.plone.org/plone/ticket/10359) >> depends on someone else doing the base work of getting z3c.form into >> 4.1. >> >> There's a PLIP at http://dev.plone.org/plone/ticket/9473 for this, but >> currently nobody stepped forward to actually own it for 4.1. >> >> Are there any volunteers? Otherwise I'll have to withdraw my own PLIP. >> I'm not familiar enough with z3c.form and its Plone integration layers >> to own this base part. > > I can own this, although I'm not quite sure what a PLIP should look > like? The actual work is in rewriting the control panel forms. The > only thing the PLIP would say is "ship with p.a.z3cform + dependencies > as a dependency of PLIP 10359". We already have: Include z3c.form - https://dev.plone.org/plone/ticket/9473 And also: Include plone.app.registry - https://dev.plone.org/plone/ticket/9472 I've assigned them over to you. Laurence ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] PlonePAS 3.x errors
http://dev.plone.org/collective/changeset/118407 – plone pas cookies
path set for /plone_site instead of always root - ticket #5665 –
introduced a couple of test failures in Plone:
* The first is just the change in policy:
$ bin/instance test -m Products.CMFPlone.tests.testCookieAuth
Failure in test testSetSessionCookie
(Products.CMFPlone.tests.testCookieAuth.TestCookieAuth)
Traceback (most recent call last):
File
"/data/buildout/zope/Zope-2.10.11-final-py2.4/lib/python/Testing/ZopeTestCase/profiler.py",
line 98, in __call__
testMethod()
File
"/data/devel/plone/3.3/src/Plone/Products/CMFPlone/tests/testCookieAuth.py",
line 54, in testSetSessionCookie
self.assertEqual(cookie.get('path'), '/')
File "/data/devel/collective/python/parts/opt/lib/python2.4/unittest.py",
line 333, in failUnlessEqual
raise self.failureException, \
AssertionError: '/plone' != '/'
* It is triggering an "Insufficient Privileges" page in this test,
maybe some incompatibility with testbrowser?
$ bin/instance test -s Products.CMFPlone -t LoginAndLogout
Failure in test
/data/devel/plone/3.3/src/Plone/Products/CMFPlone/tests/LoginAndLogout.txt
Failed doctest test for LoginAndLogout.txt
File
"/data/devel/plone/3.3/src/Plone/Products/CMFPlone/tests/LoginAndLogout.txt",
line 0
--
File
"/data/devel/plone/3.3/src/Plone/Products/CMFPlone/tests/LoginAndLogout.txt",
line 112, in LoginAndLogout.txt
Failed example:
browser.getControl('Login Name').value = 'test_user_1_'
Exception raised:
Traceback (most recent call last):
File
"/data/buildout/zope/Zope-2.10.11-final-py2.4/lib/python/zope/testing/doctest.py",
line 1348, in __run
compileflags, 1) in test.globs
File "", line 1, in ?
browser.getControl('Login Name').value = 'test_user_1_'
File
"/data/buildout/zope/Zope-2.10.11-final-py2.4/lib/python/zope/testbrowser/browser.py",
line 336, in getControl
control, form = disambiguate(intermediate, msg, index)
File
"/data/buildout/zope/Zope-2.10.11-final-py2.4/lib/python/zope/testbrowser/browser.py",
line 50, in disambiguate
raise LookupError(msg)
LookupError: label 'Login Name'
--
File
"/data/devel/plone/3.3/src/Plone/Products/CMFPlone/tests/LoginAndLogout.txt",
line 113, in LoginAndLogout.txt
Failed example:
browser.getControl('Password').value = 'secret'
Exception raised:
Traceback (most recent call last):
File
"/data/buildout/zope/Zope-2.10.11-final-py2.4/lib/python/zope/testing/doctest.py",
line 1348, in __run
compileflags, 1) in test.globs
File "", line 1, in ?
browser.getControl('Password').value = 'secret'
File
"/data/buildout/zope/Zope-2.10.11-final-py2.4/lib/python/zope/testbrowser/browser.py",
line 336, in getControl
control, form = disambiguate(intermediate, msg, index)
File
"/data/buildout/zope/Zope-2.10.11-final-py2.4/lib/python/zope/testbrowser/browser.py",
line 50, in disambiguate
raise LookupError(msg)
LookupError: label 'Password'
--
File
"/data/devel/plone/3.3/src/Plone/Products/CMFPlone/tests/LoginAndLogout.txt",
line 114, in LoginAndLogout.txt
Failed example:
browser.getControl('Log in').click()
Exception raised:
Traceback (most recent call last):
File
"/data/buildout/zope/Zope-2.10.11-final-py2.4/lib/python/zope/testing/doctest.py",
line 1348, in __run
compileflags, 1) in test.globs
File "", line 1, in ?
browser.getControl('Log in').click()
File
"/data/buildout/zope/Zope-2.10.11-final-py2.4/lib/python/zope/testbrowser/browser.py",
line 336, in getControl
control, form = disambiguate(intermediate, msg, index)
File
"/data/buildout/zope/Zope-2.10.11-final-py2.4/lib/python/zope/testbrowser/browser.py",
line 50, in disambiguate
raise LookupError(msg)
LookupError: label 'Log in'
--
File
"/data/devel/plone/3.3/src/Plone/Products/CMFPlone/tests/LoginAndLogout.txt",
line 115, in LoginAndLogout.txt
Failed example:
browser.url
Expected:
'http://nohost/plone/Members/test_user_1_/...edit'
Got:
'http://nohost/plone/acl_users/credentials_cookie_auth/require_login?came_from=http%3A//nohost/plone/Members/test_user_1_/edit'
Laurence
___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Time for a Plone 3.3.6 release?
There's quite a lot piling up in the changelog already, I think we're ready for a release. Tests pass, excepting the errors with PlonePAS (see other mail). Laurence 3.3.6 - Unreleased -- - Fix FactoryTool to mangle REQUEST.BASEn correctly. (Merged [36902]). [elro] - Fixed wrong condition and double definition on join_form where allowEnterPassword meant you were actually *not* allowed to enter a password. It worked fine but was confusingly stated the wrong way around. [maurits] - MembershipTool.setPassword unnecessarily called the role assigner plugins through acl_users.doChangeUser. Now use acl_users.userSetPassword directly. [vincentfretin] - "(Requires Javascript)" is now translatable in accessibility-info.pt. This closes http://dev.plone.org/plone/ticket/10475 [vincentfretin] - Explicitly check that a searchterm was provided before adding it to the query string. This closes http://dev.plone.org/plone/ticket/9025 [blueaidan] - Fixed for state changed message is wroning for pending item. This closes http://dev.plone.org/plone/ticket/10245 [terapyon] - Altered table of contents javascript so that comments are not displayed. [dbfrombrc] - "Event when" improved for better i18n. This closes http://dev.plone.org/plone/ticket/10196 [gotcha] - Nested groups appear again in prefs_group_members. This was broken since Plone 3.3.2. This closes http://dev.plone.org/plone/ticket/10075 [vincentfretin] - Fixed getIcon. 'Find and Catalog' works again. This closes http://dev.plone.org/plone/ticket/8235 [amleczko] - Added missing event parameter to inputlabel's blur handler. This closes http://dev.plone.org/plone/ticket/10369 [mj] ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: Plone 5 - rough roadmap
I guess I'm -0 on renaming. If someone comes up with a great new name then fine, but given it's one of the two hard problems in computer science, I'm not holding my breath ;) Laurence ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Plone 5 - rough roadmap
On 16 March 2010 23:37, Alexander Limi wrote: > On Tue, Mar 16, 2010 at 4:27 PM, Laurence Rowe wrote: >> >> Unfortunately it's not possible to generate that from an xslt >> processor / libxml2 / lxml, and in order to trigger the xhtml output >> mode (so you get with the space) you need to specify an xhtml >> 1.0 doctype to be output. It seems quite likely with deco / blocks / >> xdv that we will have an lxml based output chain, so we will be >> restricted in what's possible. This has been brought up previously on >> the libxml2 list, though without resolution (I can't find the >> reference to that right now). > > I'm thinking it will be easier to get libxml2/lxml to add this than to > change the HTML5 spec. I don't think we'll persuade libxml2 to implement it the as xhtml output until the standard is finalised, it's already been changed from in the last few months. More on this here. http://www.contentwithstyle.co.uk/content/xslt-and-html-5-problems >> Also here http://www.w3.org/2008/08/cleantheweb/libxml and here >> http://wiki.whatwg.org/wiki/FAQ#What_MIME_type_does_HTML5_use.3F it >> states the Content-Type should be application/xhtml+xml for the xml >> serialization, so I guess absolute conformity may be impossible, >> though self-closing tags seem to be allowed for the html serialization >> too so maybe we're ok there. > > Yes, that's what I meant. HTML serialization, but self-closing tags. This is the polyglot / overlap language from http://wiki.whatwg.org/wiki/HTML_vs._XHTML Laurence ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Plone 5 - rough roadmap
Unfortunately it's not possible to generate that from an xslt processor / libxml2 / lxml, and in order to trigger the xhtml output mode (so you get with the space) you need to specify an xhtml 1.0 doctype to be output. It seems quite likely with deco / blocks / xdv that we will have an lxml based output chain, so we will be restricted in what's possible. This has been brought up previously on the libxml2 list, though without resolution (I can't find the reference to that right now). We might want to start campaigning now for (and indeed -//W3C//DTD XHTML 1.1//EN) to be added to the doctypes that trigger xhtml compatible output in libxml2's xmlsave.c Also here http://www.w3.org/2008/08/cleantheweb/libxml and here http://wiki.whatwg.org/wiki/FAQ#What_MIME_type_does_HTML5_use.3F it states the Content-Type should be application/xhtml+xml for the xml serialization, so I guess absolute conformity may be impossible, though self-closing tags seem to be allowed for the html serialization too so maybe we're ok there. Laurence On 16 March 2010 22:50, Alexander Limi wrote: > Right, I don't see a reason to do that, though — it doesn't buy us anything. > > The reason the HTML5 doctype is simply: > > > > …is that it's the shortest possible string that will trigger > strict/standards parsing (ie. not quirks mode) in all browsers, including > IE6. > > > On Tue, Mar 16, 2010 at 3:34 PM, Laurence Rowe wrote: >> >> It is listed as an "obsolete permitted doctype string" >> >> http://dev.w3.org/html5/spec/Overview.html#obsolete-permitted-doctype-string >> - i.e. we can lie about the doctype. I'm not sure why xhtml 1.0 >> transitional is not allowed. >> >> Laurence >> >> On 16 March 2010 22:18, Alexander Limi wrote: >> > The way it works is that you can use the XHTML "spelling" (ie. closing >> > your >> > tags), but you serve it up as normal HTML. >> > >> > >> > http://wiki.whatwg.org/wiki/FAQ#Should_I_close_empty_elements_with_.2F.3E_or_.3E.3F >> > >> > There's no Strict or similar thing in HTML5, AFAIK. >> > >> > (There is also something informally referred to as "XHTML5" which is >> > serving >> > it as XML, which isn't what we want to do) >> > >> > On Tue, Mar 16, 2010 at 3:06 PM, Laurence Rowe wrote: >> >> >> >> By my reading of the html 5 draft, it would seem conformant with the >> >> (html5) spec to serve a document with a text/html Content-Type but an >> >> XHTML Strict doctype. >> >> >> >> On 16 March 2010 20:14, Alexander Limi wrote: >> >> > What does transitional doctype have to do with geolocation? >> >> > >> >> > (and XHTML STRICT is a problem, since it implies serving with XML >> >> > MIME >> >> > type, >> >> > which IE doesn't handle, so that's unlikely to happen) >> >> > >> >> > >> >> > On Tue, Mar 16, 2010 at 12:48 PM, Veda Williams >> >> > wrote: >> >> >> >> >> >> This brings up the question of when we're moving away from >> >> >> Transitional >> >> >> DOCTYPE. Do we have a sense of when this will happen? I'm >> >> >> particularly >> >> >> keen >> >> >> on knowing, as it opens up the door for us in terms of geolocation >> >> >> in >> >> >> the >> >> >> next year or so. >> >> >> Thanks, >> >> >> - Veda >> >> >> >> >> >> >> >> >> On Mar 16, 2010, at 12:40 PM, Alexander Limi wrote: >> >> >> >> >> >> On Tue, Mar 16, 2010 at 4:45 AM, Wichert Akkerman >> >> >> >> >> >> wrote: >> >> >>> >> >> >>> I'ld like to see a list of pros and cons of using HTML 5 as well. I >> >> >>> am >> >> >>> quite worried by the lack of proper support in existing browsers. >> >> >>> None >> >> >>> of >> >> >>> them implement any of the existing HTML standards properly, and I >> >> >>> fear >> >> >>> that >> >> >>> switching to the still unfinished HTML5 would be a several steps >> >> >>> too >> >> >>> far at >> >> >>> this point in time. >> >> >> &g
Re: [Framework-Team] Plone 5 - rough roadmap
It is listed as an "obsolete permitted doctype string" http://dev.w3.org/html5/spec/Overview.html#obsolete-permitted-doctype-string - i.e. we can lie about the doctype. I'm not sure why xhtml 1.0 transitional is not allowed. Laurence On 16 March 2010 22:18, Alexander Limi wrote: > The way it works is that you can use the XHTML "spelling" (ie. closing your > tags), but you serve it up as normal HTML. > > http://wiki.whatwg.org/wiki/FAQ#Should_I_close_empty_elements_with_.2F.3E_or_.3E.3F > > There's no Strict or similar thing in HTML5, AFAIK. > > (There is also something informally referred to as "XHTML5" which is serving > it as XML, which isn't what we want to do) > > On Tue, Mar 16, 2010 at 3:06 PM, Laurence Rowe wrote: >> >> By my reading of the html 5 draft, it would seem conformant with the >> (html5) spec to serve a document with a text/html Content-Type but an >> XHTML Strict doctype. >> >> On 16 March 2010 20:14, Alexander Limi wrote: >> > What does transitional doctype have to do with geolocation? >> > >> > (and XHTML STRICT is a problem, since it implies serving with XML MIME >> > type, >> > which IE doesn't handle, so that's unlikely to happen) >> > >> > >> > On Tue, Mar 16, 2010 at 12:48 PM, Veda Williams >> > wrote: >> >> >> >> This brings up the question of when we're moving away from Transitional >> >> DOCTYPE. Do we have a sense of when this will happen? I'm particularly >> >> keen >> >> on knowing, as it opens up the door for us in terms of geolocation in >> >> the >> >> next year or so. >> >> Thanks, >> >> - Veda >> >> >> >> >> >> On Mar 16, 2010, at 12:40 PM, Alexander Limi wrote: >> >> >> >> On Tue, Mar 16, 2010 at 4:45 AM, Wichert Akkerman >> >> wrote: >> >>> >> >>> I'ld like to see a list of pros and cons of using HTML 5 as well. I am >> >>> quite worried by the lack of proper support in existing browsers. None >> >>> of >> >>> them implement any of the existing HTML standards properly, and I fear >> >>> that >> >>> switching to the still unfinished HTML5 would be a several steps too >> >>> far at >> >>> this point in time. >> >> >> >> What parts in particular do you find are not working? Browsers that >> >> don't >> >> have dedicated support for HTML5 will just treat those tags similar to >> >> div >> >> elements (given an HTML5 shiv for styling to apply in IE), and most of >> >> the >> >> new form-related enhancements are additive in nature. >> >> >> >> In general, HTML5 renders even on IE6, there isn't much magic here (but >> >> of >> >> course it doesn't get any of the advantages either). HTML5 is mostly >> >> about >> >> standardizing edge case behaviors and adding new abilities that will >> >> gracefully degrade in older browsers — and then a few new tags like >> >> video/audio (that are also relatively easy to make degrade) and >> >> structural >> >> elements like article/footer, etc. >> >> >> >> -- >> >> Alexander Limi · http://limi.net >> >> ___ >> >> Framework-Team mailing list >> >> Framework-Team@lists.plone.org >> >> http://lists.plone.org/mailman/listinfo/framework-team >> >> >> >> >> >> Veda Williams >> >> Web Developer >> >> Groundwire >> >> 206.286.1235x23 >> >> v...@groundwire.org >> >> >> >> ONE/Northwest is now Groundwire! Read all about our new name. >> > >> > >> > >> > -- >> > Alexander Limi · http://limi.net >> > >> > ___ >> > Framework-Team mailing list >> > Framework-Team@lists.plone.org >> > http://lists.plone.org/mailman/listinfo/framework-team >> > >> > > > > > -- > Alexander Limi · http://limi.net > ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Plone 5 - rough roadmap
By my reading of the html 5 draft, it would seem conformant with the (html5) spec to serve a document with a text/html Content-Type but an XHTML Strict doctype. On 16 March 2010 20:14, Alexander Limi wrote: > What does transitional doctype have to do with geolocation? > > (and XHTML STRICT is a problem, since it implies serving with XML MIME type, > which IE doesn't handle, so that's unlikely to happen) > > > On Tue, Mar 16, 2010 at 12:48 PM, Veda Williams wrote: >> >> This brings up the question of when we're moving away from Transitional >> DOCTYPE. Do we have a sense of when this will happen? I'm particularly keen >> on knowing, as it opens up the door for us in terms of geolocation in the >> next year or so. >> Thanks, >> - Veda >> >> >> On Mar 16, 2010, at 12:40 PM, Alexander Limi wrote: >> >> On Tue, Mar 16, 2010 at 4:45 AM, Wichert Akkerman >> wrote: >>> >>> I'ld like to see a list of pros and cons of using HTML 5 as well. I am >>> quite worried by the lack of proper support in existing browsers. None of >>> them implement any of the existing HTML standards properly, and I fear that >>> switching to the still unfinished HTML5 would be a several steps too far at >>> this point in time. >> >> What parts in particular do you find are not working? Browsers that don't >> have dedicated support for HTML5 will just treat those tags similar to div >> elements (given an HTML5 shiv for styling to apply in IE), and most of the >> new form-related enhancements are additive in nature. >> >> In general, HTML5 renders even on IE6, there isn't much magic here (but of >> course it doesn't get any of the advantages either). HTML5 is mostly about >> standardizing edge case behaviors and adding new abilities that will >> gracefully degrade in older browsers — and then a few new tags like >> video/audio (that are also relatively easy to make degrade) and structural >> elements like article/footer, etc. >> >> -- >> Alexander Limi · http://limi.net >> ___ >> Framework-Team mailing list >> Framework-Team@lists.plone.org >> http://lists.plone.org/mailman/listinfo/framework-team >> >> >> Veda Williams >> Web Developer >> Groundwire >> 206.286.1235x23 >> v...@groundwire.org >> >> ONE/Northwest is now Groundwire! Read all about our new name. > > > > -- > Alexander Limi · http://limi.net > > ___ > Framework-Team mailing list > Framework-Team@lists.plone.org > http://lists.plone.org/mailman/listinfo/framework-team > > ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Plone 5 - rough roadmap
On 15 March 2010 09:13, Alexander Limi wrote: > 2010/3/12 Hanno Schlichting >> >> On Fri, Mar 12, 2010 at 5:39 PM, Laurence Rowe wrote: >> > On 12 March 2010 15:07, Hanno Schlichting wrote: >> >> Currently listed for Plone 4.x are things like: >> > ... >> >> - Well formed, valid XHTML (as a foundation for easier theming via xdv) >> >> That's really good to hear. Though I think "semantic HTML" or >> "sensible ids/classes" to identify elements in pages is what I had in >> mind with this point. Well besides the valid XHTML which is a >> requirement for Chameleon as well. > > It's also likely that we'll transition to using HTML5 (the XHTML-compatible > "phrasing", ie. HTML5, but close your tags), and Deco as a layout engine > will be much happier if we do a revamp of the existing HTML structure. It's > quite messy in parts from the 8+ years in production, and while it has held > up well, it's time to adjust to how the web has evolved since then, > especially with focus on our upcoming theming capabilities. We will almost certainly have to use an "obsolete permitted doctype string" to get lxml / libxml2 to output xhtml correctly. This means the intersection of the lists in http://svn.gnome.org/svn/libxml2/trunk/xmlsave.c and http://dev.w3.org/html5/spec/Overview.html#obsolete-permitted-doctype-string - xhtml 1.0 strict. Laurence ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Plone 5 - rough roadmap
On 12 March 2010 15:07, Hanno Schlichting wrote: > Currently listed for Plone 4.x are things like: ... > - Well formed, valid XHTML (as a foundation for easier theming via xdv) Just to note that xdv uses the HTMLParser which is really very tolerant of badly formed markup (an earlier problem with the Nginx implementation running plone.org is now fixed). The output is wellformed and forced into the xhtml namespace, though no validation is performed. The only downside to the HTMLParser is that inline elements in other namespace (e.g. esi, svg) are not allowed in the content or template, though they may be included in the rules. Laurence ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Beta 1 is (essentially) out! FWT, your job is done.
On 12 March 2010 01:24, Matthew Wilkes wrote: > > On 2010-03-09, at 0250, Eric Steele wrote: > >> So... now that those bums are out the door, how do we go about appointing >> a 4.x team for me to abuse? > > Well, on a more general note, I think we need a bit better separation > between the 4.x and 5.x teams to avoid conflicts between the needs of 4.x > and 5.0. > > I'm not sure the best way to do that, however, as I'm excited by both > releases. I honestly couldn't say if I'd prefer to be part of the 4.x team > or the 5.0 team if I could only pick one. How do they conflict? I don't want to hold back changes for 5.0, but equally I don't want anything too major in 4.x. My main aim over the 4.x series would be to see the z3cform packages become part of the distribution so we can get p.a.discussion and p.a.registry in. It's also a stepping stone to 5.0. What happened in the 3.x series, I thought the 3.0 team stayed on. Laurence ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: Plone 4 - holidays are over :)
2010/1/6 Alex Clark : > On 2010-01-05, Martin Aspeli wrote: >> Hanno Schlichting wrote: A quick poll in #plone-framework showed that myself and Messrs. Glick and Clark had never heard of bin/instance console. We need to document the crap out of that. >>> >>> Eh, how do you guys start an instance without the forced debug mode of >>> "fg"? You don't use "start" for that, do you? >> >> I guess I never do that. :) >> Since when have we had that? >>> >>> Since we use buildout or to be more precise, April 2008. Let me quote >>> the PyPi page: >>> >>> 1.8 (2008-04-05) >>> >>> Added console command to the instance script, which is equivalent to >>> fg but does not implicitly turn on debug mode but respects the >>> zope.conf setting. [hannosch] >>> >>> One month later we changed it not to fork a process internally, so >>> this is what we've been using for supervisord configurations for >>> years. >> >> Heh, good. :) I've been using a lower level script (run.py or something, >> deep inside Zope) in supervisord that I guess does the same thing. > > So are they the same or not? If so, then we can stop feeling like > idiots for missing 'bin/instance console' and continuing to use runzope ;-) > I'm getting the impression 'bin/instance console' is just a convenience. Since plone.recipe.zope2instance puts the egg paths in the instance zope.conf, parts/instance/bin/runzope should be equivalent I think. Laurence ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] PLIP 9315 — New Theme, review feedback
The default portlet assignments should be thought through with respect to the new theme. To my eyes the new portal tabs style along with portlets in the left hand column, makes the page seem unbalanced. Placing those portlets on the right made it all look a lot better to me. Laurence ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: [Plone-developers] Adding dependency on plone.registry
I'm +1 on including plone.registry. I'm also +1 on including a z3c.form as a dependency - with Zope 2.12 we won't need the whole pinning pain required for use with. Zope 2.10. Laurence 2009/8/14 Eric Steele : > > On Aug 14, 2009, at 8:14 AM, Geir Bækholt wrote: > >> >> In our work on the collections-PLIPs: #9283 and #9295 >> https://dev.plone.org/plone/ticket/9283 >> https://dev.plone.org/plone/ticket/9295 >> >> …we have found a need to persistently store configuration data. Our >> options are: >> 1) either to write a new persistent utility/tool that keeps this data, >> then adding new genericsetup handlers for it and all the work that comes >> along with this >> or >> 2)Use the shiny new plone.(app.)registry that Hanno has built for this >> exact purpose (for Plone 5) >> While this is a rather large dependency (it depends on z3c.form), we >> believe the advantages outweigh the drawbacks. As this will probably be >> the de-facto standard of storing configuration data in the near future >> anyway, it seems silly to spend big lots of work creating something that >> will be redundant in the near future. >> The fourdigits-team also wants to use the registry for the TinyMCE-plip: >> https://dev.plone.org/plone/ticket/9249 >> >> We'll add the dependency now — and hope that the framework team will >> signal us as soon as possible if this change should be reverted. >> >> >> -- >> Geir Bækholt >> >> in collaboration with >> Hanno Schlichting >> Ralph Jacobs >> Rob Gietema >> Roel Bruggink >> > > I'm generally in favor, with the stipulation that somebody takes ownership > of getting it ready for real world use and it goes through its own FWT > review process (to make sure it's "right", rather than for inclusion). > > CC'ing the FWT*, in the hopes that we can get some solid discussion on this > now instead of waiting until next Wednesday's phone call. > > Eric > > * Though I'm sure all are subscribed to Plone-dev, I just want to push it > somewhere they're more likely to notice it. > ___ > Framework-Team mailing list > Framework-Team@lists.plone.org > http://lists.plone.org/mailman/listinfo/framework-team > ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: update on supporting Python 2.6 / Zope 2.12 / CMF 2.2
Ross Patterson wrote: I think it's important that Plone has at least a welcome page when you install it. Staring at a blank folder_listing is going to put off new users. We can probably bet rid of the News and Events collections, though. I think I'd be opposed to removing the initial content, including the news and events collections, from the Plone installer. I think the batteries included story is very valuable and I love being able to tell prospective clients to just download the installer and start playing. Part of that is being able to add an event to their home folder, publish it, and see it in the listing. OTOH, I'd love to be able to write an client app package where I don't have to start my GS profile by *removing* that content. So I'm +1 for moving the initial content into a separate profile that is only installed by the installer and isn't installed by "Add Plone Site". I'm -10 for removing the initial content if it isn't preserved in the installer. +1 discoverability is important, putting it in a separate (but default) profile sounds sensible. Laurence ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: PLIP deadline overly aggressive?
Matthew Wilkes wrote: On 20 Jun 2009, at 20:54, Laurence Rowe wrote: So if your PLIP isn't ready now, don't worry. There'll be another chance to get it in with 4.1 With the usual caveat that 4.x releases are as ambitious as 3.x releases. The reason we need a 4.0 release is so we can put the things Laurence mentions through. The place for ambitious changes is still trunk and PLIPs against 5. I want to avoid a mad dash for getting features included with 4.0, so I'd like us to say that any PLIP we would consider for 4.0 we would also consider for subsequent 4.x releases. 4.0 is far less radical than 3.0, so I think we can safely spread out features throughout the 4.x line and not be quite as conservative as the 3.x changes have been. Laurence ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: PLIP deadline overly aggressive?
Hanno Schlichting wrote: Personally I'd be in favor of extending the scope of Plone 4.0 to some degree and making a clear commitment to allow quite a number of the suggested features to be done in the scope of Plone 4.1, 4.2, ... releases. Much of the work that makes up Plone trunk (5.0?) today is going to take even more time than we had planned for and is all pretty invasive changes. If our developer community is still so much alive based on our current set of technologies, we can allow ourselves to take some more time to refurbish our backend. I think it's important to get 4.0 out the door quickly so we can start enjoying the benefits of Python 2.6, Zope 2.12 and CMF 2.2. With that in place we will be in a good position to add features in subsequent 4.x releases. So if your PLIP isn't ready now, don't worry. There'll be another chance to get it in with 4.1, you don't have to wait until 5.0. Laurence ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: Plone 2009: Going from here
Jon Stahl wrote: Eric Steele wrote: Folks, A gentle prod since Steve wants to have something to vote on by Friday There seems to be general agreement on the hybrid team idea. Can we pare this down to a list of 7 people? We currently have responses of: available: Raphael (3), Ross (4), Matt (4) unavailable: Andi (3) I'd like to gently encourage Hanno to play a formal role on this new FWT. As the "Plone trunk/future" release manager and our most prolific contributor, I think it will be important for him to provide continuity between the Plone 4 release and Plone Future. I would also personally love to see Martin Aspeli and Laurence Rowe in the mix as well, since they have such deep understandings of our stack and are helping architect large chunks of the future. I'm happy to be a part of this team too, presuming that most of the work will be later in the summer. Laurence ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: [Plone-developers] The new Plone 4.0
Martin Aspeli wrote: Alexander Limi wrote: On Tue, 05 May 2009 15:56:36 -0700, Ricardo Alves wrote: Steve McMahon wrote: My only concern about calling Hanno's incremental change list 4.0 is that we don't suffer from big-number expectation syndrome. This is the biggest risk I guess, a major release with just a minor set of visible (UI) improvements, will bring bad publicity. I agree — this is the biggest risk in terms of calling it 4.0 instead of 3.5. The consensus to call the 2009 release 4.0 makes sense to me — so +1 on that decision. One way to mitigate this — and make Plone seem a bit more modern along the way — could be to apply the new typography/theme that I'm currently applying to trunk. This is essentially the typography from the plone.org redesign along with a color-neutral design for the navigation and other UI elements. The goal is to make something that you can put the company logo on, and it looks relatively decent, no matter what your company colors are. This would make 4.0 seem "fresh" out of the box, make it look like an application from 2009, and let us ship with considerably more efficient/smaller CSS files. The risk would be that we need to do some IE6 testing on it, but that might not be a bad thing, since we know much more about IE6 workarounds at this point than we did when the original CSS was written. I'd support this, *if* it follows the usual PLIP process and we actively encourage outside review from the get-go. That process may mean the theme change gets a thumbs-down. Personally, I think it's a good idea, but in the past, we've had a lack of commitment/follow-up with CSS/theme stuff, and a last-minute rush to put in dozens of template and CSS changes which then cause breakage in release candidates. We'd also need to find a way to not break all existing themes. A small visual refresh would be welcome, though. Plone is looking a bit last millenium. :-/ +1 Laurence ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: The new Plone 4.0, was Re: Plone 3.5
Ross Patterson wrote: Andreas Zeidler writes: On May 5, 2009, at 10:05 PM, Ross Patterson wrote: BLOBs: Has the backups/repozo story been sufficiently worked out? this will need a good backup story, but it won't be via repozo. repozo was meant to backup a single data.fs, but not your entire zodb. the blob storage will tend to be big and might live on some media with other backup strategies (think SAN or S3). there should be some recipe or something that provides a single script to backup both for the standard use-case of having the blob storage live on the same filesystem, but that shouldn't be repozo. I should clarify my question here. Is there an issue with making sure that the backed up BLOB directory is consistent with a particular backed up state of the Data.fs via repozo. IOW, can we say something like "so long as you restore your BLOB directory to a state as it was in the same moment or after the repozo process started then it is guataneed to be consistent"? I'm not saying that the above statement is correct cause I don't know. :) I'm just saying we'd need to be able to make some promise about repozo backups of Data.fs and backups of BLOB directory being consistent. No problem here, you just take the copy of your BLOB directory after you take the copy of your Data.fs. The dangling blobs in the backup (those created since your backup of the Data.fs) are not an issue. Creating a consistent backup of two filestorages (e.g. Catalog.fs and Data.fs) is more tricky. Laurence ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Multiple workflows (Was: PLIP lifecycle)
2009/1/2 Martin Aspeli : > Tres Seaver wrote: > >> You can actually have multiple workflows for a given type. I may be the >> only person who has ever actually used the feature, but it is truly >> helpful at times. > > I'd be interested to hear what kind of situations it's useful for? Modelling complex workflows such as a securities trading settlement process - multiple workflows allowed different parts of the process to run in parallel. Laurence ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Plone 4 framework team
I'd like to nominate myself for the Plone 4 framework team. My goal is to ensure that we improve persistency design in Plone and accepted PLIP's code, with the aim of a better scaling Plone. I have good knowledge of Plone, Zope and the ZODB from working with them for several years now. Laurence ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: More worfklow adapters, status and history
Alec Mitchell wrote: On Dec 19, 2007 1:07 PM, Martijn Pieters <[EMAIL PROTECTED]> wrote: On Dec 17, 2007 1:36 AM, Laurence Rowe <[EMAIL PROTECTED]> wrote: Inspired by Alec's plip #217, I'd like to propose making workflow history/status storage fully pluggable. http://plone.org/products/roadmap/221 Though it is now perhaps a little late for 3.1, completing the componentization of the workflow tool in one shot has its advantages. I must say I'd rather have this one go into the CMF directly. We have the people with the access, and I think your proposal should have no trouble being accepted for a future CMF version. In the same vein I'd rather see PLIP #217 go directly into the CMF, if it were not for the fact I'd like to see the CMFPlacefulWorkflow monkey patch disappear ASAP. Perhaps we should ensure that we port both PLIPs to the CMF ASAP. That's the plan. My understanding is that we're not likely to have a new major release of the CMF for Plone 3.1. So if we want these changes, then it makes sense to drop them into Plone and then merge it into CMF for the next major release. If the CMF situation changes, then these should certainly go into CMF ASAP. In fact I'd suggest merging this stuff into CMF trunk as soon as the implementation in Plone is done and reasonably tested. Alec Given that the need is less pressing than for #217, I'm happy to defer #221 to 3.2 and work directly into CMF. I've started a discussion on cmf-devel. Laurence ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] More worfklow adapters, status and history
Inspired by Alec's plip #217, I'd like to propose making workflow history/status storage fully pluggable. http://plone.org/products/roadmap/221 Though it is now perhaps a little late for 3.1, completing the componentization of the workflow tool in one shot has its advantages. Laurence ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: Two more PLIPs
Andreas Zeidler wrote: as said above, i'm fine with doing things step by step as well, but every step covered would be a bonus, of course. Will have to be, I have quite limited time at the moment. as for the risks, in what possible ways could the changes break existing customizations? laurence, could you elaborate a little bit here, please? and can't we provide sensible defaults, so that potential problems are kept to a minimum? The only things I am proposing to change are: * content_status_modify.cpy - current parameters are: ##parameters=workflow_action=None, comment='', effective_date=None, expiration_date=None, *args I need to add a workflow_id=None parameter. The current *args argument is completely ignored, so I will remove it and replace it with a **kw parameter to pass through to the workflow action. I'll only pass the workflow_id parameter when the workflow chain is more than one workflow - so existing customisations to this script will continue to work with existing workflows. * plone.app.contentmenu.menu and plone.app.kss.content_replacer.ContentMenuView Pass in the workflow_id parameter where necessary as part of the url. No risk. * plone.app.layout.viewlets.WorkflowHistoryViewlet and its template review_history.pt Because I need to pass in multiple review histories, any customisations to this viewlet will break. I don't think I can avoid this without spaghetti code. Risk: existing viewlet customisations will break Laurence ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: Two more PLIPs
Danny Bloemendaal wrote: On 13 dec 2007, at 08:41, Raphael Ritz wrote: Tom Lazar wrote: On 11.12.2007, at 13:35, Laurence Rowe wrote: I'd like to see the following for 3.1: #210: Improve UI support for objects on multiple workflows DCWorkflow allows for a chain of workflows to be specified for a type. please explain. does chaining mean, that an object/type can have multiple workflows associated sequentially? or does each given state have the sum of all of the workflows transitions available? More the latter than the former. Objects can be subject to several workflows at once. This implies multiple state variables of course. Indeed you get a sum of all possible transitions offered. I used to use this feature to provide locking functionality before Plone itself did it (but in a different way now). If you want to see an example in action check out my LockingWorkflow product in a Plone 2.5 site. And to drive home the point here: the CMF workflow tool and DCWorkflow have supported this from the onset. It is only Plone's UI that's kind of hiding this from you. and BTW: +1 from me on the issue I truely think that this isn't as trivial as it may seem. Is it only a UI issue? I know plone relies on several locations for the review_state attribute. What if an object has several states (which is possible if you have multiple workflows assigned)? Aren't there configlets that allow you to do things with this attribute like the navtree? What about worklists? I think that when we agree that an object can have more than one states, we have to support it everywhere in a concise way. I want to see a list of all the locations and situations where this may be an issue. Is the code truely multiple-state/transition aware? It's not only changing content_status_modify in my opinion. The state change drop-down should also show that there are more workflows and perhaps group the transitions per-state. So, my point is: we either do it right or we don't do it at all :) And for now: +0 Danny. We already do it, just not very well ;-) In 3.0 it works so long as you keep your transition ids unique across workflows. Catalogued workflow variables are calculated so that the first in the chain takes precedence, so nothing breaks here. Are worklists still used in Plone? They are a per workflow feature of DCWorkflow anyway, so are not affected. Workflow actions are already grouped as the actions are calculated sequentially from workflows. It would be nice to have a separator and a workflow title shown too, but I'm not sure what this should look like UI wise. How about this? --- Workflow 1 Submit Approve --- Workflow 2 Confirm Reject --- Advanced... Laurence ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Two more PLIPs
I'd like to see the following for 3.1: #210: Improve UI support for objects on multiple workflows DCWorkflow allows for a chain of workflows to be specified for a type. This mostly works with Plone, but there are a few (mostly UI) warts to be fixed. http://plone.org/products/plone/roadmap/210 #211: Enable dashboard to be locked down Portlets may be registered to the dashboard for groups, this makes the dashboard useful even when users should not be able to modify their own dashboard. http://plone.org/products/plone/roadmap/211 Laurence ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: The big 3.0 ;)
Raphael Ritz wrote: On a related note: let's not forget that one of the strong points of Zope/Plone has always been the possibility to do many things TTW from a browser. In many real life situations, site admins don't have file system access to the server deploying their site which defeats in my view the current tendency to simply move everything to the file system and then saying: "Oh, well, just provide your own view class/whatever and override the default in your config.zcml." For those site admins this is simply not an option. (And note that I am not talking about TTW *development*, I'm talking about *site configuration*.) That's what Clouseau is for, now you can edit your filesystem code TTW with standard python semantics ;-) Laurence ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: Base tag
Martin Aspeli wrote: Geir Bækholt · Plone Solutions wrote: On 9. mar. 2007, at 17.22, Laurence Rowe wrote: I would vote for keeping the base tag anyway, as it would make the site not break if someone makes a wrong link somewhere. Another possibility to help this would be to make all folderish content redirect to get the trailing slash, like Apache does. +1 on redirecting Historically the Zope mantra has been to return data rather than redirect to save the overhead of processing an extra request. Plone is a complex application and I suspect this overhead is negligible compared to rendering a page. Matching Apache's behaviour would make things conceptually simpler. INonStructuralFolders should probably not have a trailing slash appended. If INonStructuralFolders don't redirect and don't have base tags, relative links to the objects contained in them may easily break. They exhibit the exact same behavior as normal folders… Yes. An INonStructuralFolder should be treated exactly the same as a real folder; the interface pertains to the Plone UI only. isPrincipiaFolderish should be the only thing we check. Martin Hmm, I'm not convinced by this. Take a RichDocument for instance. The rich text field is on the RichDocument object itself. So we're either going to end up with: a) treating it like a document: Relative links in the rich text field to external/sibling images work like other documents. Relative links to contained images don't work b) treating it like a folder: Relative links in the rich text field end up with an acquired image (multiple copies get cached) or lead to a page outside the normal containment hierarchy. Relative links to contained images and files work fine. So either way some things don't work as expected. I think this is a UI question, should URLs to RichDocuments end with a trailing slash? In my view no as for a RichDocument "It has every method and attribute of the standard Page/Document type. That is, it can be used as a drop-in replacement wherever a Page is expected." Having said that it would seem easier to change the way Zope handles this and catch it during traversal, where checking isPrincipiaFolderish would seem the correct thing to do. Laurence ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: Base tag
Geir Bækholt · Plone Solutions wrote: On 6. mar. 2007, at 01.23, Martin Aspeli wrote: My point in the bug thread is that I *think* the solution is to make sure slashing of links is always consistent: if it's folderish, put / at the end, if not, don't. I can confirm that the solution is to always have a trailing slash for folderish content. That way we can : 1) keep the base tag if we want, with no harm 2) remove the base tag if we want, with no harm 3) never get anchor problems I would vote for keeping the base tag anyway, as it would make the site not break if someone makes a wrong link somewhere. Another possibility to help this would be to make all folderish content redirect to get the trailing slash, like Apache does. +1 on redirecting Historically the Zope mantra has been to return data rather than redirect to save the overhead of processing an extra request. Plone is a complex application and I suspect this overhead is negligible compared to rendering a page. Matching Apache's behaviour would make things conceptually simpler. INonStructuralFolders should probably not have a trailing slash appended. Laurence ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: content tab switching
This seems reasonable. After Plone 3 is released KSS will have much greater exposure and more people looking at it. The fewer challenges that need to be solved before 3.0.0 the earlier KSS will benefit from more eyes. Plone will be with us for many years to come, lets not get stuck fixing everything at once! Laurence Wichert Akkerman wrote: As you're all probably aware there has been some discussion recently about the kss based content tab switching feature in Plone 3. I have tried to get a good grasp on the situations and this is what I came up with. This discussions revolves around the implementation of PLIP 121 http://plone.org/products/plone/roadmap/121 . This PLIP documents a single reason for doing in-place replacement of the content view: performance. Only reloading the content view but keeping the rest of the page in place should be a lot faster. Looking at the current situations there are a few problems: - the in-place loading behaviour breaks the back button. This breaks user expectations and leads to frustration. - one of the risks mentioned in the PLIP mentions is that the tabs are no longer bookmarkable but says that we are willing to sacrifice this for the speed benefits. Later user testing has revealed that this might not be acceptable. - at this moment the in-place reloading is not faster. The AT edit forms are too heavy, so loading the edit tabs takes long enough to negate any benefits from not reloading the whole page. - javascript triggers do not work correctly when replacing the content (autofocus, form unload protection) This makes me think that at this moment we should not ship with the in-place content tab replacement functionality enabled. The concept is still good, but in order to realize the desired benefits we need more extensive work: the edit forms have to become a lot simpler and cleaner and we need to find a way to keep the browser history updated so the back button keeps working. We might be able to take some inspiration from what gmail does. It is definitely a direction in which we should be going. Opinions? Thoughts? Wichert. ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
