Re: [Framework-Team] Current PLIP status
Alec, Thanks for the great review. I would like to make a couple points about stuff where I'm directly/indirectly involved. For PLIP 106, the 'RootNavigation' thing is for making it easy to root the navigation items to a different place than the 'Plone Site' by setting a marker interface. It needs tests, I should be able to provide those on time. The rest of the stuff is in good shape. I think it makes sense to use the Physical variant of the breadcrumbs code. PLIP 112 is somewhat related to Marshall, because Kapil has been developing the 'pluggable xmlns stuff' as a branch of Marshall. However, Marshall is also a important part of fixing the problems with WebDAV in Plone in my opinion. I've chatted with Kapil and he has agreed to split the xml marshaller stuff out of the Marshall product. The idea is that instead of hardcoding to a single marshaller on all AT schemas, we would have a default marshaller, and some policy to delegating to different marshallers depending on the incoming content type, etc. It is lacking a simplified predicate that matches on the incoming request content-type + portal_type and a Plone UI. In a perfect world, I would be able to land this in time for Plone 2.1.2 to fix the last 3 issues related to WebDAV, but I would be happy enough to land it into 2.5. -- Sidnei da Silva Enfold Systems, LLC. http://enfoldsystems.com ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: PLIP wishlists towards 3.0
On Mon, Mar 13, 2006 at 02:35:27PM -0600, whit wrote: | was there a non-marshall based IO piece suggested? iirc, everything | talked about so far is based on marshall. There's a product for CSV import or something like that somewhere in the collective that doesn't use Marshall. Not sure what XMLForest is, does it use Marshall? -- Sidnei da Silva Enfold Systems, Inc. http://enfoldsystems.com ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: PLIP wishlists towards 3.0
On Mon, Mar 13, 2006 at 12:03:52PM -0800, Rob Miller wrote: | hmm... not sure i can, actually. i'm very interested in getting this | working, and i'll provide guidance and help, of course, but i expect | i'll be pretty busy focusing on member management and general cmf 2.X | related stuff, this may be more than i can commit to. | | sashav tried to get kapil's GenericSetup-based ContentSetup product | working at the snow sprint, but failed, and ended up having better | success w/ jens's XMLForest product. maybe we can get more help from | him. and maybe i'll have more time than i think, who knows, but i | would recommend against counting on me for this. The advice I can provide here is that any framework that doesn't use Archetypes marshallers is a waste of effort. 'Marshall' the product just enables to multiplex Archetypes 'marshall' by moving policy about what marshaller to use outside the schema. It is *not* a/the solution itself, it just allows different solutions to be implemented on top of it. The reason for using Archetypes marshaller infrastructure instead of '' is that: 1. It plays well with WebDAV and FTP 2. WebDAV and FTP are best ways to import and export content from Plone, if not because they are born to the task because using a browser just won't scale. 3. We at Enfold Systems are committed to make sure Zope 2 and Zope 3 have efficient, memory-savy, speedy and featureful WebDAV and FTP experience, because It's Our Core Business (TM). -- Sidnei da Silva Enfold Systems, Inc. http://enfoldsystems.com ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: r10902 - review/plip48-bundle
On Tue, Sep 12, 2006 at 08:19:21PM -0700, Alexander Limi wrote: | On Tue, 12 Sep 2006 13:15:08 -0700, wichert | wrote: | | >+Using sessions means that ZEO clusters will not work out of the box: the | >+session storage is not shared between ZEO clients. This needs to be | >explicitly | >+documented in release notes. | | Not only documented, it's a showstopper IMO - most professional sites run | a couple of ZEO clients at the very least. Hell, I run ZEO locally, and | I'm just designing UIs. :] | | Is there a way to make sessions shared between ZEO clients? If we're going | to ship Plone with this configuration as standard, it has to work with ZEO | out of the box too. You can mount /temp_folder using tempstorage. Enfold Server 3.0 comes with that configured OOTB. -- Sidnei da Silva Enfold Systemshttp://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] PLIP145 Locking - Review
On Tue, Sep 26, 2006 at 02:40:20PM +0100, Martin Aspeli wrote: | Well, the way the PLIP145 bundle works, you get a warning message when | you go to the edit tab, but with an option of stealing the lock. If | there is no lock, when you go the edit tab, a lock is automatically | obtained. Meaning, you need some "about to edit" event and base_edit | needs to know there is a lock that may be stealable. However, some | generic marker interfaces and events should make that possible without | the exact locking implementation being tied to AT. I still disagree with that. base_edit shouldn't have to know about anything like that. If some sort of notification needs to be available, it needs to be available globally and that means it should be in plone. -- Sidnei da Silva Enfold Systemshttp://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] PLIP145 Locking - Review
On Tue, Sep 26, 2006 at 02:17:56PM +0100, Martin Aspeli wrote: | - If we can make AT fire generic events then maybe the locking can | live outside AT? That would be great. | The hard part is obviously the UI, since base_edit | would probably have to be aware of it. That's not true. If you re-use the 'document actions' (which PloneLockManager did), then you need an ActionProvider where you can specify conditions based on interfaces. It could even just proxy the ActionProvider API to browser:menu thingies. -- Sidnei da Silva Enfold Systemshttp://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: Some preliminary Plone 3.0 profiling results
One thing that might help is the work I'm putting in the Fate project. The goal there is to cleanup the way Widgets are handled in Archetypes to do the minimal amount of work possible and avoid calling the 'accessors' nedlessly. To do so, I'm adapting the Archetypes Widget/Field combo into Zope 3's IWidget interface. That was the first step. The next step is to re-write the Page Templates used for the AT Widgets to make use of the same interface. In doing so, some of the flexibility will have to go. For example, there are a thousand of ways to override macros in AT Widgets that no-one uses. I believe it would be worth to drop all of this and re-think it from scratch how you override parts or all of a widget's display. -- Sidnei da Silva Enfold Systemshttp://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: Some preliminary Plone 3.0 profiling results
You mentioned the thread local idea. That might work. I think we should also investigate memcached. See Tres's mcdutils package, for example: http://agendaless.com/Members/tseaver/software/mcdutils. It's important to note that this cache is absolutely request-specific. It must be invalidated after every request. If it needs to be invalidated after every request then the overhead of using something like memcached cannot be justified. There are ways of associating request-specific information with a Request object in Zope 2, which will clear the information when the request is finished. Look for request._hold() example in CMFCore/MemberDataTool.py. -- Sidnei da Silva Enfold Systemshttp://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: Some preliminary Plone 3.0 profiling results
On 11/15/06, Philipp von Weitershausen <[EMAIL PROTECTED]> wrote: Cool. I have two problems with this, though: * the underscore clearly indicates the "privateness" of the _hold method. In fact, _hold isn't part of the official Request API, I guess (if there even is such a thing...) * this doesn't seem to exist in Zope 3 (at least not in IRequest ;)). BP! Wrong answer! This is turned out to be public API but wasn't officialy named so for backward compatibility I guess. Someone should really have deprecated that in Zope 2 by adding an alias. In my local checkout of Zope 2.9, in lib/python/zope/publisher/base.py: def hold(self, object): 'See IPublicationRequest' self._held = self._held + (object,) Essentially, _hold() just adds properties to the request object. Why not use attribute annotations? I think that makes for a bit cleaner approach while still being flexible enough to make it work in both Zope 2 and 3... I don't see why since Zope 3 seems to have inherited hold(). -- Sidnei da Silva Enfold Systemshttp://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Fwd: [Framework-Team] Re: Some preliminary Plone 3.0 profiling results
(Just so it's recorded on the list) -- Forwarded message -- From: Philipp von Weitershausen <[EMAIL PROTECTED]> Date: Nov 15, 2006 1:15 PM Subject: Re: [Framework-Team] Re: Some preliminary Plone 3.0 profiling results To: Sidnei da Silva <[EMAIL PROTECTED]> Sidnei da Silva wrote: On 11/15/06, Philipp von Weitershausen <[EMAIL PROTECTED]> wrote: Cool. I have two problems with this, though: * the underscore clearly indicates the "privateness" of the _hold method. In fact, _hold isn't part of the official Request API, I guess (if there even is such a thing...) * this doesn't seem to exist in Zope 3 (at least not in IRequest ;)). BP! Wrong answer! This is turned out to be public API but wasn't officialy named so for backward compatibility I guess. Someone should really have deprecated that in Zope 2 by adding an alias. In my local checkout of Zope 2.9, in lib/python/zope/publisher/base.py: def hold(self, object): 'See IPublicationRequest' self._held = self._held + (object,) D'oh. It's in IPublicationRequest. Never mind then :). Essentially, _hold() just adds properties to the request object. Why not use attribute annotations? I think that makes for a bit cleaner approach while still being flexible enough to make it work in both Zope 2 and 3... I don't see why since Zope 3 seems to have inherited hold(). Yep. +1 to request.hold(). -- http://worldcookery.com -- Professional Zope documentation and training -- Sidnei da Silva Enfold Systemshttp://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] 3.0-alpha1 is out.. and now
On 11/24/06, Wichert Akkerman <[EMAIL PROTECTED]> wrote: I just released 3.0-alpha1 unto the world. There are a number of known problems with this release: besides the bugs in the issue tracker there are a lot of failing unittests. As far as I can see the majority are due to changes in the CMF and PloneTestCase testinfrastructures and not real bugs in the products themselves. Since I did not want to delay alpha1 any further I decided to release it as-is; we'll need to fix those test problems for alpha2 though. I would like us to re-review the pending bundles and see if there is more that can be merged in the next 1-2 weeks and do a second alpha after that. I can probably fire up a installer. Would that be any help? -- Sidnei da Silva Enfold Systemshttp://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Zope 3 widgets in Plone [was: Re: 3.0-alpha1 is out.. and now]
On 12/1/06, Rocky Burt <[EMAIL PROTECTED]> wrote: An awesome secondary goal would then be to create archetype-style wrapper widgets so that we could stop having to maintain two sets of widgets (one for achetypes, another for formlib). The archetype widget would simply be a wrapper for the formlib widget which would make BBB much easier. Well, I'm going the other way around. I've wrote an adapter for AT Widgets so that they implement IWidget. A secondary goal of mine was to write an adapter to AT Fields to implement IField. And then we could use AT stuff unmodified with formlib. With not too much effort I still believe that's doable. -- Sidnei da Silva Enfold Systemshttp://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: Zope 3 widgets in Plone [was: Re: 3.0-alpha1 is out.. and now]
On 12/1/06, Rocky Burt <[EMAIL PROTECTED]> wrote: > Well, I'm going the other way around. I've wrote an adapter for AT > Widgets so that they implement IWidget. A secondary goal of mine was > to write an adapter to AT Fields to implement IField. And then we > could use AT stuff unmodified with formlib. With not too much effort I > still believe that's doable. I was avoiding that direction on purpose. Building widgets in a nice clean zope3 way and then writing an archetypes compatiblity layer would help BBB. Building widgets in AT style and providing a formlib compatiblity layer means people will continue writing archetypes widgets :( I'm sorry but I disagree. We would have to stop and put a big amount of effort up to getting all the widgets ported to Z3. We can't afford that time and effort. If we do bridge the AT Widgets to Z3 we can start using formlib right away. And then we can re-write the widgets, one at a time, correctly and avoiding previous mistakes *and* keeping backward compatibility with existing tools (AGX) and documentation (including books). If we just rush ahead and try to do it all at once we risk ending up with a similar mess to what we have today, only with a nicer name. -- Sidnei da Silva Enfold Systemshttp://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: Re: Zope 3 widgets in Plone [was: Re: 3.0-alpha1 is out.. and now]
On 12/1/06, Rocky Burt <[EMAIL PROTECTED]> wrote: I disagree and I'm not even sorry! :) I have an up-until-now silent use case I want to be fulfilled, I want to use magnificent (functionality-wise) Archetypes widgets in my pure zope 3 applications (zope3.2, whatever). But besides that, I still think the Plone add-on community should start building formlib based widgets and not Archetypes widgets. Your method continues to facilitate writing Archetypes widgets. But this starts coming down simply to differing opinions. I, too, believe the Plone commnunity should be building formlib-based widgets. But we have to be careful on our steps. Just saying that we won't support Archetypes widgets 'because people might keep building them' is shooting ourselves in the foot. In the long term, if we do provide clear documentation about building formlib widgets people *will* do that. If not for the future-proofness, because building formlib widgets is easier and less magical (it is easier right? :). It's not a matter of differing opinions here. We both want to reach the same goal! The only difference is that you want the 'revolutionary' approach. I want the 'evolutionary' approach. People are afraid of big changes. If we change too fast we will give people the impression that Plone is not a stable platform, no matter how cool it is to use formlib or whatnot. Even if we did manage to rewrite all the widgets using formlib we would still have to provide the compatibility for applications until everyone updates their products. And that's not one or two, the list of products in the Collective is enormous. There are existing ways for prodding people into using the cool latest technology and we've been achieving that by the use of 'deprecation' mechanisms. There's no reason why widgets should be treated differently. In the end I believe our two approaches can and *need* to cohexist safely. We need to get traction on getting formlib widgets and at the same time we need to provide a compatibility layer to give everyone a chance to reach the 'next level'. -- Sidnei da Silva Enfold Systemshttp://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: Some preliminary Plone 3.0 profiling results
On 12/11/06, Alexander Limi <[EMAIL PROTECTED]> wrote: Any progress on the following, Sidnei? (I have seen checkins on the branch, but it's hard for me to figure out what state it is in :) I haven't gotten to the page templates yet. The reason is that I'm using this to generate XML descriptions of both a schema and a form. But I hope to get there when I have 'free time'. -- Sidnei da Silva Enfold Systemshttp://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Fwd: [Framework-Team] Re: PLIP 177 - Content indexing
Ops, sent only to Rocky. -- Forwarded message -- From: Sidnei da Silva <[EMAIL PROTECTED]> Date: Dec 11, 2006 11:58 AM Subject: Re: [Framework-Team] Re: PLIP 177 - Content indexing To: Rocky Burt <[EMAIL PROTECTED]> Personally I think this plip would be awesome to get in place. But with one small stipulation. I would adding a configlet someplace or some config option somewhere that lets you toggle this behaviour on/off (on a functional level) and have it off by default. That way we don't have to worry about the performance implications by default. Then for Plone 3.5 we could consider having it activated by default. I am seriously concerned about the str(content) part. We have improved a lot the situation in other places in AT and it should not do that anywere else anymore (except in the transforms maybe). We need to fight that will all our forces. :) -- Sidnei da Silva Enfold Systemshttp://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 -- Sidnei da Silva Enfold Systemshttp://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: Fwd: [Framework-Team] Re: PLIP 177 - Content indexing
On 12/11/06, Kapil Thangavelu <[EMAIL PROTECTED]> wrote: > I am seriously concerned about the str(content) part. We have improved > a lot the situation in other places in AT and it should not do that > anywere else anymore (except in the transforms maybe). We need to > fight that will all our forces. :) the str(content) is basically arg marshalling for transforms, if you know a way to pass a stream to the transform api... do tell. afaicr, internally evening passing in an idatastream object using portaltranforms interfaces, still assumes an accessor to a string blob. So we need to fix that. We can surely provide a 'stream' adapter for FileField. We should be able to change the transform API to make use of streams. -- Sidnei da Silva Enfold Systemshttp://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: Fwd: [Framework-Team] Re: PLIP 177 - Content indexing
On 12/11/06, Wichert Akkerman <[EMAIL PROTECTED]> wrote: Previously Sidnei da Silva wrote: > So we need to fix that. We can surely provide a 'stream' adapter for > FileField. We should be able to change the transform API to make use > of streams. For 3.5 I'ld love to see a whole new transform infrastructure :) I would be happy enough just to see something that works. New not always equates to better. Old and beaten tends to be more robust. -- Sidnei da Silva Enfold Systemshttp://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: Login redirect in 3.0?
On 12/27/06, Martin Aspeli <[EMAIL PROTECTED]> wrote:
We could make a nicer implementation, by having a view with name @@login
registered for the portal root. /login (or /@@login, to disambiguate)
would then only be available on the site root. I suggest we still
redirect to /login_form e.g. with
self.request.response.redirect('login_form').
I can whip this up if people agree.
The portal root is not guaranteed to be the site root. It's common
practice to serve a sub folder of the portal root as the site root.
--
Sidnei da Silva
Enfold Systemshttp://enfoldsystems.com
Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214
___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: Login redirect in 3.0?
On 12/28/06, Florian Schulze <[EMAIL PROTECTED]> wrote: Dang! I knew this was coming. I thought about this for some time now and didn't find a good solution to add a tab here which is not Schema based. There was a thread on archetypes-devel about making interfaces and adapters for Schema and Field stuff, so you could add stuff here, but I don't know the state of it. The problem is, that this is one big form and currently only archetypes handles everything on save, ideally it would delegate the validation and mutation etc, so one could add custom fields here. We also would need to see how this works together with KSS inline validation, but if AT delegates, then it shouldn't be a problem. Something just occurred me. If you get the 'Fate' product running, it has an 'addform' directive, that creates a form for adding a AT object. Until the validation succeeds it won't create the object. What could be done is to provide a mixin class that overrides 'createAndAdd'. Then, instead of creating and adding an object, it would call your 'createAndAdd', where you could do whatever you wanted. I'm planning to do something like this for a project I'm working on. -- Sidnei da Silva Enfold Systemshttp://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: wicked - lxml dependency?
On 2/13/07, Hanno Schlichting <[EMAIL PROTECTED]> wrote: Ah ok, great. I got lxml running on Windows (as there's a pre-built binary release) and all tests did indeed pass. Glad to see that my binaries are helping someone. :) -- Sidnei da Silva Enfold Systemshttp://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Inline editing
It should be possible to differentiate a 'click-and-drag' from a simple 'click' right? I'm sure someone thought about this. :) -- Sidnei da Silva Enfold Systemshttp://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: Inline editing
On 3/3/07, Philipp von Weitershausen <[EMAIL PROTECTED]> wrote: Alec Mitchell wrote: > As one who compulsively clicks and highlights things while reading > them, I'm very much against single click edit. :-) And I thought I was the only one doing that... :) That's not enough of an argument against single click. Flickr does handle selecting without toggling an edit, so that means we can do the same. Heck with a timer before triggering we could even handle double and triple clicks. For example, if a second click happens less than 500ms after the first click then it's a double click. Of course if javascript can't give us 500ms granularity then that wouldn't be doable. Who hasn't configured the double-click threshold on their Windows raise your hand :) -- Sidnei da Silva Enfold Systemshttp://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Timezone PLIP anyone? (was: Re: [Framework-Team] Deadline today, but what timezone?)
On Dec 14, 2007 6:23 PM, Martijn Pieters <[EMAIL PROTECTED]> wrote: > I can't seem to find what the exact deadline is for PLIPs; midnight is > mentioned, but in what timezone would that be? :-) Speaking of Timezone, did anyone write a PLIP about user-configurable timezones? I've been meaning to write this for a while... The only information I could find was this page: http://plone.org/events/sprints/past-sprints/snow-sprint2/IntlFormattingPlan -- Sidnei da Silva Enfold Systemshttp://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] PLIP #187 for Plone 3.1
Sorry all, With all the cool new stuff going around, I completely forgot to propose my own PLIP for 3.1 inclusion. PLIP #187 is already implemented and can be merged with some small polishing. This is the result of my GSoC work. If it's too late for 3.1, well, too bad. :( -- Sidnei da Silva Enfold Systemshttp://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: preliminary results for PLIP selection & call for votes!
> To be clear, I believe the only -1 vote on #187 was primarily due to > some concerns about the shortage of detail in the PLIP text. A > concern I share. I'm hoping Sidnei fleshes out the details soon. :-) I would gladly answer any questions. The PLIP doesn't have much detail because there ain't much to be detailed. The branch achieves the first bullet under 'Proposal', and the third bullet was addressed and released in a Zope release. The second bullet has resulted in some research and I'm waiting for confirmation from Nate Aune that the proposed fix for it works. I have not addressed versioning because I didn't know there was any concern about it. I saw the comment #3 but my assumption was that whoever implemented versioning did it in such a way that it would interact correctly with WebDAV, but did not have the time to verify such assumption. Feel free to ask more questions... -- Sidnei da Silva Enfold Systemshttp://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: PLIP #187 for Plone 3.1
I've created a buildout for evaluating PLIP #187 at: http://svn.plone.org/svn/plone/review/dreamcatcher-plip187/ More information on the status over here: http://awkly.org/2007/12/24/preparing-plip-187-for-review/ Summary: At this point, it should be possible to checkout the buildout, build it and run the tests, which currently gives me 3 failures for CMFPlone, two of them apparently unrelated and one related but which apparently did not happen at the time I've branched. The next step is to update my CMFPlone and Marshall branches to trunk, and possibly getting rid of the PloneTestCase I had initially created. -- Sidnei da Silva Enfold Systemshttp://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: preliminary results for PLIP selection & call for votes!
On Dec 24, 2007 1:15 PM, Ricardo Newbery <[EMAIL PROTECTED]> wrote:
> What is the proposed (unconfirmed) fix for the second bullet (the OS
> X resource fork issue)?
Here it is, I would be glad if someone can test and confirm this works:
"""
I've found an article describing a hack using Apache rewrite rules,
but I believe we can get something going in pure Zope if you can give
this a try and it works fine.
The example setup is here, however the guy mentions that using
'forbidden' prevents creation of new files *at all*:
http://www.netmojo.ca/blog/2007/05/03/subversion-webdav-osx/#solution
I found mention in other WebDAV server implementations that returning
a 404 might please Finder just fine, though it would be better to use
that Finder configuration as even if the server rejects those files,
Finder still tries to send it, so configuring Finder properly will
make it faster.
So, from that guy's example, it looks like the correct configuration
would be to remove this part:
# Deny OSX dot files
RewriteEngine On
RewriteCond %{REQUEST_METHOD} ^PUT$
RewriteRule .DS_Store - [F]
RewriteRule .Trashes - [F]
RewriteRule .TemporaryItems - [F]
RewriteRule ._.* - [F]
And instead list those filenames in the RedirectMatch directive below:
# Fix broken Windows XP
RedirectMatch 404 ^/(MSOffice/|_vti_bin/|_vti_inf.html$)
So the final configuration would look somewhat like:
RedirectMatch 404
^/(MSOffice/|_vti_bin/|_vti_inf.html$|.DS_Store|.Trashes|.TemporaryItems|._.*)
If you can give that a try, and it works for you, then we can look at
implementing this in Zope, with a configuration directive to
selectively disabling it in zope.conf.
"""
--
Sidnei da Silva
Enfold Systemshttp://enfoldsystems.com
Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214
___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: preliminary results for PLIP selection & call for votes!
On Dec 24, 2007 6:36 PM, Ricardo Newbery <[EMAIL PROTECTED]> wrote: > Thanks again Sidnei, > > [note to framework list: let me know if I should take this > discussion off list] > > Maybe I'm missing something but there doesn't seem to be any reason > to return a 404 (Not Found) or 403 (Forbidding) response. Why not > just silently discard the offending files, along with the > configuration directive option? Should be simpler to code. I have tried that approach and it failed in the past. If we behave like the file has been succesfully created but just plain discard it, Finder will expect it to be there, and if it get a 404 for a file that was just created and it really expected to exist, it fails miserably. Of course that could have changed in later versions of Finder. Sending the 404/403 upfront is a saner and simpler approach which doesn't break expectations on either side, IMO, and is more likely to work. -- Sidnei da Silva Enfold Systemshttp://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] PLIP #217 & #221 Comments
Please check the comments on PLIP #217: http://plone.org/products/plone/roadmap/217/#1197635650 Apparently Kapil has a working implementation that can be used by the person implementing those PLIPs. -- Sidnei da Silva Enfold Systemshttp://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: Testing for PLIP 209: Unified Installer Plus Buildout
On Thu, Feb 14, 2008 at 1:23 PM, Raphael Ritz <[EMAIL PROTECTED]> wrote: > > On Thu, 14 Feb 2008 13:38:56 +0100, Raphael Ritz > > <[EMAIL PROTECTED]> wrote: > > > >> (i) when describing start/stop/status we might want to add > >> 'fg' (foreground) as a simple means to start in debug mode > >> without changing the configuration > > > > AFAIK this doesn't work for some reason in buildouts. It has bitten me > > many times now, but I didn't get to look into it yet. > > > > It works for me on Linux at least > (use it all the time including in buildouts). > No idea about Windows though. It works on Windows, but when you hit CTRL-C you get into a weird state where you're asked if you want to exit the batch file or some such, and then you have to hit 'y' once or twice. Pretty odd as if the output or the input was in a separate thread. Example: """ KeyboardInterrupt Terminate batch job (Y/N)? y 'y' is not recognized as an internal or external command, operable program or batch file. C:\src\server\4.0> Terminate batch job (Y/N)? y 'y' is not recognized as an internal or external command, operable program or batch file. C:\src\server\4.0>y """ The workaround is to run it like 'yes | bin\instance fg', then when you hit CTRL-C it exits immediately. -- Sidnei da Silva Enfold Systems http://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: comments on plip187: WebDAV
Hi Raphael, While the points you raised are valid, I don't see anything that disqualifies this PLIP. More below. Your points will certainly be considered for possible improvements after the PLIP is merged. In fact, some of them are already on my TODO. On Feb 18, 2008 5:09 AM, Raphael Ritz <[EMAIL PROTECTED]> wrote: > Hi, > > here my current take on this PLIP: > > tested on Linux/Ubuntu 7.10 with Nautilus and Cadaver as WebDAV clients. > > First, my overall impression: I'm somewhat at a loss here as I don't know > what to expect and therefore I don't know what to recommend. :-( > > While all changes introduced are worthwhile improvements (and could go into > Plone core as far as I can see) I'm hesitant calling this > > Working Out-of-the-box WebDAV > > I think my problem is: what does "working WebDAV" mean? > Examples: > > (i) Binary fields: when editing a News Item via webdav I don't see how > I could manage the image that can be included with an item (nor its > caption) That wasn't a stated goal of this PLIP. > (ii) Folders: When copying over (downloading) the default news folder I > get a series of error messages from the aggregator topic's criteria > (not too surprising) but no news items at all (and of course I've created > a few in there before). > More generally, folderish items seem to be problematic still. The 'news folder' is not a folder, is a 'smart folder'. It does (should?) not contain files, but basically presents a search result. As such, it is hard to decide what should happen there, and I'm open for suggestions. We could either: - Display the 'contents' of a 'smart folder' and allow for downloading them. The problem might be that since they are not directly contained inside that 'smart folder', maybe some WebDAV clients will complain that the URLs for those items are not 'contained in' the parent. - Serialize the criteria for the 'smart folder', and display it as non-folderish. Another issue is, when you upload a file to a 'smart folder', where should this file end up? > (iii) Extensibility: all marshallers don't seem to delegate the > serialization > of field values to the fields but rather apply some heuristics to the value. > While the current implementations work for field types shipped with AT it > is limiting when it comes to supporting custom field/data types. > (e.g., my Record- and RecordsField (dict and list of dict types) are not > treated correctly neither can I easily hook in my own serializations. > I guess other complex field types like the ArrayField, the DataGridField, > the CompoundField, etc. might have the same problem.) I did not design the marshalling layer on AT, though I contributed many improvements to it. It is completely possible to create a marshaller that delegates to each field. I don't see how your comment qualifies here though, as we don't ship Plone with any of those different kinds of fields. Moreover, my view (and certainly Alex's) on Working out-of-the-box WebDAV is: you drag a file in, and you get a file (preferably the same file) out. The previous status-quo, which *tried* to serialize each field individually could be interesting to geeky types who know what they are doing, but is totally useless as there are no known editors (other than text editors) that could edit those files. > Recommendation: as I think any improvements on the WebDAV side are worth > it I'm generally positive but I would be hesitant advertising it too boldly > (WebDAV is maybe just too broken in general?). It is certainly not too broken, and it's a great improvement over what we had before. We can incrementally improve on what we have on this PLIP. Going from 100% broken to 100% working is not a trivial task that can be achieved in one release cycle. -- Sidnei da Silva Enfold Systemshttp://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: comments on plip187: WebDAV
On Feb 18, 2008 11:27 AM, Raphael Ritz <[EMAIL PROTECTED]> wrote: > Hi Sidnei, > > first of all thanks for your prompt reply! Thank you for reviewing! > >> (ii) Folders: When copying over (downloading) the default news folder I > >> get a series of error messages from the aggregator topic's criteria > >> (not too surprising) but no news items at all (and of course I've created > >> a few in there before). > >> More generally, folderish items seem to be problematic still. > > > > The 'news folder' is not a folder, is a 'smart folder'. It does > > (should?) not contain files, but basically presents a search result. > > As such, it is hard to decide what should happen there, and I'm open > > for suggestions. > > No, it's a bit trickier than that: In current Plone 3 the news folder > is an ATBTreeFolder which contains a topic as default view. > It is perfectly fine (and actually supported through the default > Plone UI) to add news items to this folder. > > The problem I was having is that when trying to download the > *folder* I didn't get the news items contained in there probably > because of the errors triggered by the contained topic. > See what mean now? I see. I am aware of that issue and intend to fix it very soon. > > We could either: > > > > - Display the 'contents' of a 'smart folder' and allow for > > downloading them. The problem might be that since they are not > > directly contained inside that 'smart folder', maybe some WebDAV > > clients will complain that the URLs for those items are not 'contained > > in' the parent. > > - Serialize the criteria for the 'smart folder', and display it as > > non-folderish. > > > that seems to make most sense to me at the moment That == ? > > Another issue is, when you upload a file to a 'smart folder', where > > should this file end up? > > I'm not sure we should even try this. Why not? > >> (iii) Extensibility: all marshallers don't seem to delegate the > >> serialization > >> of field values to the fields but rather apply some heuristics to the > >> value. > >> While the current implementations work for field types shipped with AT it > >> is limiting when it comes to supporting custom field/data types. > >> (e.g., my Record- and RecordsField (dict and list of dict types) are not > >> treated correctly neither can I easily hook in my own serializations. > >> I guess other complex field types like the ArrayField, the DataGridField, > >> the CompoundField, etc. might have the same problem. > > > > I did not design the marshalling layer on AT, though I contributed > > many improvements to it. It is completely possible to create a > > marshaller that delegates to each field. > > That's kind of the point I was trying to make: it would > certainly be possible (and not that hard even). But would it be desirable to have this as default, since there is no known editor that could edit whatever comes out of this? I don't think so. I also think that's not what you're advocating, but it's better to clarify. > > I don't see how your comment qualifies here though, as we don't ship > > Plone with any of those different kinds of fields. > > While you are right in the strict sense I do propose > to take a broader look at this. And from my perspective > things could be better here. People often don't draw the > fine line between Plone the product (as it comes OOTB) > and Plone the platform/framework/whatever you call it. My experience is that people do not care about WebDAV in general, and once they care they can easily create such a marshaller if they want to. The goal I have though is to have what ships with Plone be in a working state, no more no less. > > Moreover, my view (and certainly Alex's) on Working out-of-the-box > > WebDAV > > I guess this is what I'm most worried about: Calling this > > Working out-of-the-box WebDAV > > Maybe I'm the only one who has these "strange" expectations > but for issues like the ones mentioned above I feel uncomfortable > with advertising it as such. I understand your concern, and I hope to be able to address the issue with smart folders before the final 3.1 comes out, but after the PLIP has been merged. > > We can incrementally improve on what we have on this > > PLIP. Going from 100% broken to 100% working is not a trivial task > > that can be achieved in one release cycle. > > Absolutely, and again I'm mostly worried about rai
[Framework-Team] Re: WebDAV changes
On Sun, Feb 24, 2008 at 1:04 PM, Wichert Akkerman <[EMAIL PROTECTED]> wrote: > > I've just reverted the WebDAV changes from Sidnei after playing a bit with > them. What?!? > I did this for two reasons: > > Hanno had some very good remarks that need to be addressed And there's nothing that prevents them from being addressed other than time? > I tested the 3.1 tree with just Calendaring removed. Some testing there > quickly revealed that there are other things broken: the default frontpage > for a Plone site is no longer created properly this made me feel that at > this moment the implementation of this PLIP is note quite mature enough. How does that relate to the changes I made? Please provide more details. > We > have too much happening in the 3.1 tree at the moment to work on it there, > so this should mature a bit more before we merge it again. I find that completely unfair. You have not provided any clear reason why it should be reverted. I can't see from your email how the frontpage is related to WebDAV changes. I am quickly losing any interest I had in getting those changes merged. At best, you should have asked *me* to revert the changes. -- Sidnei da Silva Enfold Systemshttp://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: WebDAV changes
On Sun, Feb 24, 2008 at 4:56 PM, Wichert Akkerman <[EMAIL PROTECTED]> wrote: > The frontpage issue I found is very simple to reproduce: if you create a > new Plone site the text of the default frontpage is empty. After > reverting the changes to CMFPlone frontpage creation worked again. If that's deemed important (which it obviously is), a test should exist that does make sure this keeps working. Why did the test infrastructure not catch it (ie, all the existing tests pass)? Maybe there *is* a test, and a browser rendering issue made the text invisible instead? -- Sidnei da Silva Enfold Systemshttp://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: WebDAV changes
On Tue, Feb 26, 2008 at 9:13 PM, Andreas Zeidler <[EMAIL PROTECTED]> wrote: > On Feb 24, 2008, at 5:30 PM, George Lee wrote: > imho, yes. the fact that two additional packages are introduced by > the PLIP should have been pointed out, along with additional review > notes about them, or at least a note whether they have been reviewed > or not... It should have been pretty obvious, the review buildout had a 'parts/review' part with the changed or new products inside it, and only them. -- Sidnei da Silva Enfold Systemshttp://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: Resource Registries improvements PLIP
Since Limi mentioned in a comment on the PLIP that loading CSS and JS from different hosts can help speeding up the page load, I was reminded of an idea I had myself: - Why doesn't the CSS and JS registries allow for specifying alternative hostnames for the CSS and JS resources? So for example, one configures a few hostnames on CSS and JS registries: - r1, r2, r3, r4 Assuming that the current hostname is 'www.plone.org' or 'plone.org', then CSS and JS are generated as: http://r1.plone.org/portal_css/Plone%20Default/ploneStyles4308.css http://r2.plone.org/portal_css/Plone%20Default/ploneStyles6933.css http://r3.plone.org/portal_javascripts/Plone%20Default/ploneScripts4221.css http://r4.plone.org/portal_javascripts/Plone%20Default/ploneScripts5923.css BTW, while writing this I've just noticed that the CSS's for Plone.org are being re-validated and getting 304. Supposedly, if you are using the CSS/JS registries those resources need *NEVER* to be re-validated because when the resources change, the filename changes too. I believe you can do that by tweaking CacheFu to not set the Last-Modified header. -- Sidnei da Silva Enfold Systems http://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: Resource Registries improvements PLIP
I disagree. While WSGI is certainly interesting for the future, it makes deployment more complex by introducing more software. We must still support non-WSGI scenarios with the same level of functionality at least for a few more releases. So my vote is -1 on having this functionality on WSGI middleware only. On Fri, Aug 15, 2008 at 11:10 AM, Tom Lazar <[EMAIL PROTECTED]> wrote: > On 14.08.2008, at 13:52, Malthe Borch wrote: > >> Plone should probably only name the resources that the browser needs to >> render the HTML document and leave it to WSGI middleware to optimize that, >> e.g. >> >> * Rebase to other hostnames >> * Concatenate >> * File-size reduction > > that sounds really good to me. > > i take it, though, that it's understood that this doesn't affect the > acceptance of plip 232 but simply that it means we shouldn't invest too much > into 'pimping' the registries themselves but rather put future efforts into > middle ware. > > right? > > cheers, > > tom > >> >> >> \malthe >> >> >> ___ >> 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 > -- Sidnei da Silva Enfold Systems http://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] PLIP #187: Working out-of-the-box WebDAV
I would like to propose PLIP #187 for Plone 3.3. I already have pretty much all the work done, in a branch. It just needs polishing and merging. -- Sidnei da Silva Enfold Systemshttp://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: A roadmap in a Trac
On Fri, Dec 26, 2008 at 7:48 PM, David Glick wrote: > Have we considered how we're going to handle the search function once > plone.org and trac look the same visually? If we just use the separate > search features of each product it's a bit non-ideal: Maybe something based on collective.solr? -- Sidnei da Silva Enfold Systems http://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 Skype zopedc ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] PLIP review deadline has passed - time to review!
On Mon, Jan 19, 2009 at 10:43 AM, Andreas Zeidler wrote: > #187: "Working Out-of-the-box WebDAV" — as this PLIP was already submitted > for inclusion in Plone 3.1, i suppose it's not quite clear if it should be > considered for review now (without another announcement of the bundle's > availability to the list). i haven't checked if there have been any updates > to the code, or if a review bundle has been created without notification, > though. perhaps sidnei can provide us with a quick status update here? I suspect the code just needs some polishing, if any. There's two new eggs to be included and other than that it's just configuration. I don't have any time to look at this at the moment, swamped in first weeks of new job. -- Sidnei da Silva Canonical Ltd. T. +1 713 568 5638 (main) Landscape - Changing the way you manage your systems http://landscape.canonical.com ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] PLIP review deadline has passed - time to review!
On Mon, Jan 19, 2009 at 1:32 PM, Andreas Zeidler wrote: > i'm sorry to say, but i think you'd at least need to make sure the review > bundle is up-to-date and post a few review notes along with it. otherwise i > don't think we can consider a review (simply because we cannot hunt down the > pieces ourselves as we cannot be sure to have the latest version that way). I'm sorry to say too, but the review date has passed as you guys said. I don't expect being treated differently than others, so don't consider #187 as up for review. -- Sidnei da Silva Canonical Ltd. T. +1 713 568 5638 (main) Landscape - Changing the way you manage your systems http://landscape.canonical.com ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] "Unladen Swallow" -- possibly worth keeping an eye on
On Fri, Mar 27, 2009 at 6:21 PM, Jon Stahl wrote: > Google's Python folks have started an effort to significantly speed up > Python. > http://code.google.com/p/unladen-swallow/ > > Should be interesting to keep an eye on. For the record, if they speed up cPickle, that will contribute a lot to ZODB. Another thing that might be worth looking at, to make Chameleon even faster, is to use Cython to generate some type annotations. -- Sidnei da Silva Canonical Ltd. Landscape · Changing the way you manage your systems http://landscape.canonical.com ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] PLIP process in Trac for Plone 4 onwards
On Thu, Apr 2, 2009 at 10:49 AM, Alexander Limi wrote: > Hi all, > > Just wanted to summarize how I think we'll using Trac for the PLIPs for > Plone 4 onwards: > > - PLIPs are added as tickets with the "PLIP" type. > > - PLIPs show up in http://dev.plone.org/plone/report/24 > > - If you propose for a particular release, you assign it to that release's > milestone. > > - "Idea" PLIPs are put in the "Future" milestone. > > - That the ticket is "accepted" reflects FWT vote > > - When the ticket is "resolved", it means that it has been merged. > > I have added this to the description on the Trac report, let me know if > anything should be added or changed. > > We probably want to add the state of the ticket to that report, so we can > keep track of the resolved/accepted states. That sounds a lot like Blueprints in Launchpad. Just sayin! :) -- Sidnei da Silva Canonical Ltd. Landscape · Changing the way you manage your systems http://landscape.canonical.com ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: [Plone-installers] Plone 3.3rc2 tagged and uploaded
Hello all, It's my pleasure to announce that the installers for both 3.2.2 and 3.3rc2 are now available: http://launchpad.net/plone/3.2/3.2.2/+download/Plone-3.2.2-buildout.exe http://launchpad.net/plone/3.3/3.3rc2/+download/Plone-3.3.0rc2-buildout.exe Many thanks to: - Alexander Limi, for incredible feedback about the overall installation experience - Steve McMahon, for rolling out an all-new controller which is a much solid base to build on - Darci Hanning, for testing and reporting multiple problems! I would also like to thank everyone for their patience with waiting for the installers. As you might or not know, I am since April 1st working full-time for Canonical, and the little free time that remains is being sucked up by Enfold. Finding the time to put together those installers and do QA for them is far from trivial. Hopefully we can find a way together to share this responsibility in the future. Cheers! -- Sidnei da Silva ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Plone 4.1 Framework Team Meetin g Minutes– 17 August, 2010
On Wed, Aug 18, 2010 at 2:14 PM, Dorneles Treméa wrote: > from his recent work on Canonical, I'm sure Sidnei has some great > insights to share here, don't you Sidnei? :-) We've been using YUI, so Y.Test as the test framework. We run tests manually in the browser when debugging, but for automated unit tests we use JsTestDriver from Google to drive the tests, save output to XML then report failure/success back to Python's unittest by parsing the XML. There's a little bridging needed to get the tests registered with JsTestDriver, but not terrible. JsTestDriver ships with a version of jQuery, but might not be the same you guys are using. There's another test runner coming up, YETI, but it might be YUI-specific. For functional tests, we're using Selenium2, which is alpha-something IIRC. It's *way* better than Selenium1. We're using the webdriver API (remote webdriver and Firefox, on local machine), and it's Good Enough, just forget about recording tests in the browser and saving them - at least for now. One way or another, writing tests manually isn't that hard once you get the idea, and produces better, more concise tests, specially if you have to match elements with CSS classes or XPath. The Launchpad team is using Windmill. From the amount of groaning I hear over there, I would avoid it at all costs. It is possible to run headless tests with both Selenium2 and Windmill, under xvfb-run. Pretty trivial actually. Forget about writing a ton of tiny tests though. I would say functional Selenium tests should be end-to-end, massive use case tests. Because they take a long time to run. If you think Plone tests take a long time, think again. ;) -- Sidnei ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Plone 4.1 Framework Team Meetin g Minutes– 17 August, 2010
On Thu, Aug 19, 2010 at 11:37 AM, Martin Aspeli wrote: > On 19 August 2010 23:24, Godefroid Chapelle wrote: > >> First time I hear bad sound about Windmill. Happy that I am no the only >> one not convinced. > > I hear "bad sounds" too from time to time, but no-one has yet been > able to tell me what the real problem is. I'd be quite interested in > any specifics. Put simply: Both Selenium1 and Windmill use Javascript to control the browser, which isn't great because it has to compete with Javascript executing in the browser. Selenium2 uses WebDriver, which controls the browser by way of browser-specific extensions (it takes care of setting up a profile with the extension installed for you), so it has full control over the browser, even allowing interaction with browser dialogs and taking screenshots. -- Sidnei ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Plone 4.1 Framework Team Meetin g Minutes– 17 August, 2010
On Thu, Aug 19, 2010 at 11:24 AM, Godefroid Chapelle wrote: > Le 19/08/10 12:29, Sidnei da Silva a écrit : > Is JsTestDriver qUnit compatible ? http://code.google.com/p/js-test-driver/wiki/QUnitAdapter > Do you test multiple browsers or only Firefox ? Only Firefox at the moment (Firefox accounts for 69% of the visitors to Landscape, with Chrome at about 20%). > Do you use Selenium IDE or write from scratch ? From scratch, the IDE didn't support the WebDriver API when I started. It might support it now. -- Sidnei ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Plone roadmap
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. -- Sidnei ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
