Re: [Framework-Team] Re: Re: PLIP 212 ready for review
On Feb 14, 2008, at 1:57 PM, Florian Schulze wrote:
On Wed, 13 Feb 2008 20:20:40 +0100, Tom Lazar [EMAIL PROTECTED]
wrote:
On 12.02.2008, at 23:41, Florian Schulze wrote:
instead i got the following error in jquery.js (via firebug)
a is not a function
[Break on this error] eval(function(p,a,c,k,e,r){e=function(c)
{return(ca?'':e(parseInt(c/a)))+((c=c%a...
Note: this error remained, even after replacing the shipping
jquery version 1.2.2 with the meanwhile current version 1.2.3
This looks like a syntax error in that file. I will look into it.
well, since it's the jquery.js file itself, i kind of doubt it
(which also prompted me to try out the 1.2.3 version) but hey!
you're the expert ;-)
This is either another syntax error, or some issue with the KSS
interaction.
you tell me ;-)
I can't reproduce any of these issues. I tried my exisiting buildout
and I made a fresh co of the buildout and ran buildout with the
option to get the newest version of everything.
well, given the fact that i indeed *can* reproduce these, chances are,
others will, too.
watching the process of publishing or retracting a page shows clearly,
that the entire page is reloaded. i can see for an instance that a
ressource named content_status_modify is called but immediately after
that the whole page is reloaded.
as for item actions, for instance using the copy command indeed does
*not* reload the entire page and works as advertised (not sure why i
didn't catch that the first time round, i could have sworn it reloaded
the page, too), but upon execution i get the following two JS errors:
Unhandled error during command execution: ReferenceError:
initializeMenus is not defined++resource++kukit... (line 144)
initializeMenus is not defined
(no name)(Object node=ul#contentActionMenus parms=Object)++resource+
+kukit... (line 7793)
executeClientAction(bindActionMenus)++resource++kukit... (line 866)
execute(Object node=ul#contentActionMenus parms=Object)++resource+
+kukit... (line 2568)
execute(Object node=ul#contentActionMenus parms=Object)++resource+
+kukit... (line 2389)
EventBinder_triggerEvent(load, Object node=ul#contentActionMenus
parms=Object)++resource++kukit... (line 3897)
func_to_bind(undefined)++resource++kukit... (line 981)
execute()++resource++kukit... (line 516)
addPre(function(), Setup of events for nodes subtrees [ul], [dt],
[dd])++resource++kukit... (line 497)
doSetupEvents([\n, ul#contentActionMenus, dt, 1 more...])++resource+
+kukit... (line 1271)
finishSetupEventsCollection()++resource++kukit... (line 1241)
executeCommands(Object node=a#copy.actionicon-object_buttons-copy)+
+resource++kukit... (line 5833)
processResult(XMLHttpRequest channel=[xpconnect wrapped nsIChannel])+
+resource++kukit... (line 5306)
notifyServer_done(XMLHttpRequest channel=[xpconnect wrapped
nsIChannel])++resource++kukit... (line 5217)
notifyServer_done()++resource++kukit... (line 5172)
[Break on this error] initializeMenus();
i'd still like to see this fixed before giving my thumbs up... (and
i'd really love to see 3.1 to ship with jquery... if there's anything
else i can do to help get this baby on the road, let me know!)
cheers,
tom
The only thing I could reproduce was the searchterm highlight thing
which I will look into.
Regards,
Florian Schulze
___
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] PLIP 213 ready for review
On Jan 19, 2008, at 6:48 PM, Florian Schulze wrote: Hi! The buildout is at https://svn.plone.org/svn/plone/review/plip213-syndication-preps Notes are in the buildout. I guess this is the smallest PLIP of all :) yay, a nice small plip. it certainly works nicely during my clicktests. however, i have one problem, which is more svn-kungfoo related than to this plip. given the branch you've cut of CMFPlone https://dev.plone.org/plone/browser/CMFPlone/branches/plip213-syndication-preps how can i single out the changeset that you have done? i'd like to review the diffs that you made, i.e what seperates this branch from the revision that you cut it from. i must admit that i'm a bit overwhelmed here with that large listing. any pointers? other than that +1 from me on the plip. Regards, Florian Schulze ___ 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] PLIP 213 ready for review
Previously Tom Lazar wrote: however, i have one problem, which is more svn-kungfoo related than to this plip. given the branch you've cut of CMFPlone https://dev.plone.org/plone/browser/CMFPlone/branches/plip213-syndication-preps how can i single out the changeset that you have done? i'd like to review the diffs that you made, i.e what seperates this branch from the revision that you cut it from. trac makes this trivial. If you go to http://dev.plone.org/plone/log/CMFPlone/branches/plip213-syndication-preps you will immediately see the only change: http://dev.plone.org/plone/changeset/18960 Wichert. -- Wichert Akkerman [EMAIL PROTECTED]It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] PLIP 213 ready for review
On 15.02.2008, at 11:34, Wichert Akkerman wrote: Previously Tom Lazar wrote: however, i have one problem, which is more svn-kungfoo related than to this plip. given the branch you've cut of CMFPlone https://dev.plone.org/plone/browser/CMFPlone/branches/plip213-syndication-preps how can i single out the changeset that you have done? i'd like to review the diffs that you made, i.e what seperates this branch from the revision that you cut it from. trac makes this trivial. If you go to http://dev.plone.org/plone/log/CMFPlone/branches/plip213-syndication-preps you will immediately see the only change: http://dev.plone.org/plone/changeset/18960 ah, perfect, thanks! i must have been blind. all i would have had to do is to click on the 'revision log' link. i'll try to remember that ;-) cheers, tom Wichert. -- Wichert Akkerman [EMAIL PROTECTED]It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: Re: Re: PLIP 212 ready for review
On Fri, 15 Feb 2008 11:10:42 +0100, Tom Lazar [EMAIL PROTECTED] wrote: Unhandled error during command execution: ReferenceError: initializeMenus is not defined++resource++kukit... (line 144) initializeMenus is not defined (no name)(Object node=ul#contentActionMenus parms=Object)++resource+ +kukit... (line 7793) executeClientAction(bindActionMenus)++resource++kukit... (line 866) execute(Object node=ul#contentActionMenus parms=Object)++resource+ +kukit... (line 2568) execute(Object node=ul#contentActionMenus parms=Object)++resource+ +kukit... (line 2389) EventBinder_triggerEvent(load, Object node=ul#contentActionMenus parms=Object)++resource++kukit... (line 3897) func_to_bind(undefined)++resource++kukit... (line 981) execute()++resource++kukit... (line 516) addPre(function(), Setup of events for nodes subtrees [ul], [dt], [dd])++resource++kukit... (line 497) doSetupEvents([\n, ul#contentActionMenus, dt, 1 more...])++resource+ +kukit... (line 1271) finishSetupEventsCollection()++resource++kukit... (line 1241) executeCommands(Object node=a#copy.actionicon-object_buttons-copy)+ +resource++kukit... (line 5833) processResult(XMLHttpRequest channel=[xpconnect wrapped nsIChannel])+ +resource++kukit... (line 5306) notifyServer_done(XMLHttpRequest channel=[xpconnect wrapped nsIChannel])++resource++kukit... (line 5217) notifyServer_done()++resource++kukit... (line 5172) [Break on this error] initializeMenus(); i'd still like to see this fixed before giving my thumbs up... (and i'd really love to see 3.1 to ship with jquery... if there's anything else i can do to help get this baby on the road, let me know!) I fixed these now, please check whether there are any more problems. All these problems have been exactly the ones describe in risks. They can only be catched by TTW testing or selenium tests. But I don't know the state of KSS selenium tests or how to run them if there are any. But on the other side all these problems are simple to fix once you know how to reproduce them. Regards, Florian Schulze ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: Re: PLIP 212 ready for review
i'm happy to report that all remaining issues have been fixed by florian today. the reason that my findings were not immediately reproducible, turned out to be because they were triggered by KSS interactions, i.e. only if you previously had, for instance, performed a copy operation andthen a workflow step. once fschulze found that out he claims to have fixed several other issues of the same nature. i've assigned the ticket to witsch, for lack of knowing anything better. given that raphael has also looked at the plip i'd like to suggest to 'officially' include 212 for 3.1: how are we going to go about this? will we collect explicit votes from andi, martijn and danny? On 15.02.2008, at 13:41, Raphael Ritz wrote: Wichert Akkerman wrote: Previously Tom Lazar wrote: On Feb 14, 2008, at 1:57 PM, Florian Schulze wrote: I can't reproduce any of these issues. I tried my exisiting buildout and I made a fresh co of the buildout and ran buildout with the option to get the newest version of everything. well, given the fact that i indeed *can* reproduce these, chances are, others will, too. That's worrying. I would like to seem some succes/failure stories from others - FWIW: I just did a fresh buildout for 212 and tested a few things in firefox (inline editing, calendar pagination, display changes, workflow transitions, folder reordering, and running the tests from test_ecmascripts ). The only issue I've encountered is this one: opera_is_broken is not defined KupuSelectionTestCase()test_kupuhelpers (line 265) registerTestCase(KupuSelectionTestCase(), kupu)unittestUtilities... (line 9) opera_is_broken(this, 'testParentElementImg'); which Tom reported already. Raphael at the moment this feels like a big risk to me. Tom, can you write a short step-by-step guide for reproducing the problems you are seeing? Wichert. ___ 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] PLIP 213 ready for review
after looking at the diffs -- :-) -- i'd hereby like to cast my approval of this plip, as well. On 19.01.2008, at 18:48, Florian Schulze wrote: Hi! The buildout is at https://svn.plone.org/svn/plone/review/plip213-syndication-preps Notes are in the buildout. I guess this is the smallest PLIP of all :) Regards, Florian Schulze ___ 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] Re: Re: PLIP 212 ready for review
On 15.02.2008, at 11:56, Wichert Akkerman wrote: Previously Tom Lazar wrote: On Feb 14, 2008, at 1:57 PM, Florian Schulze wrote: I can't reproduce any of these issues. I tried my exisiting buildout and I made a fresh co of the buildout and ran buildout with the option to get the newest version of everything. well, given the fact that i indeed *can* reproduce these, chances are, others will, too. That's worrying. I would like to seem some succes/failure stories from others - at the moment this feels like a big risk to me. Tom, can you write a short step-by-step guide for reproducing the problems you are seeing? for the record: florian has been able to reproduce the issues, fixed them and i was able to confirm it. Wichert. -- Wichert Akkerman [EMAIL PROTECTED]It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: buildout error for plip215
Tom Lazar, on 2008-02-15: hi ree, thanks for the quick reply! it turns out, that my ~/.buildout/default.cfg was the culprit, where i had activated the new ppix index on advice from reinout[1]: index = http://download.zope.org/ppix after removing that the buildout works fine, sorry for the confusion. i'm reclaiming the ticket and will continue with my review. thanks, tom [1] http://vanrees.org/weblog/archive/2008/01/09/ppix-instead-of-pypi-from-now-on It works fine with that index when I try it. The last item in the index page for this package does look strange though: http://download.zope.org/ppix/infrae.subversion/ pa href=https://svn.infrae.com/buildout/infrae.subversion/trunk#egg=infrae.subversion-dev`_.https://svn.infrae.com/buildout/infrae.subversion/trunk#egg=infrae.subversion-dev`_./a/p I wonder if that somehow borks things, at least for some people. -- Maurits van Rees | http://maurits.vanrees.org/ Work | http://zestsoftware.nl/ This is your day, don't let them take it away. [Barlow Girl] ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] My conclusion regarding 201 (USW)
Today Florian made some changes to überselectionwidget to use the same pattern as Mac OS Finder's column view and it rocks and I really think that this is the way how it should work. Add search, good mouse/ keyboard navigation, object details etc to it and you have a very powerful and easy to use widget. However, it needs a bit more designing, twaeking and getting it just right (tm) so I think that that will not make it into 3.1 but surely 3.2. Florian thinks that it can put some parts of this plip in 3.1 though so that it is even better that was is now in 3.0 (backend, js and js-less search) so I think that that part could land in 3.1. Next week I will work with Florian on some more designs, mockups and specs. So.. stay tuned :) Oh, when this widget is going to work as planned.. we could use that same pattern for navigating the portal as an alternative to the navtree ;-). Now.. that would be interesting to explore as well someday. It is so fast... Ah well.../me is dreaming away. (which reminds me... Wichert have you added my kss stuff for expandable/ collapsible navtree folders?.. ok ok.. that's off topic.. let's not discuss it here ;-)) but oh my do I love that in our intranet.. don't want to miss that navtree feature anymore). Danny. ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] PLIP 224: CSRF protection framework
On Jan 31, 2008, at 10:15 PM, Andreas Zeidler wrote: in contrary to my statement regarding the other reviews, i.e. that two review ought to do (considering how late we are already), in this case it should be: the more, the merrier. hence, i'd offer to do a review as well and i'd suggest that martijn has a look at this, too. fyi, i've finished the review on the plane home and added my notes to https://dev.plone.org/plone/ticket/7783 cheers, andi -- zeidler it consulting - http://zitc.de/ - [EMAIL PROTECTED] friedelstraße 31 - 12047 berlin - telefon +49 30 25563779 pgp key at http://zitc.de/pgp - http://wwwkeys.de.pgp.net/ plone 3.0.5 released! -- http://plone.org/products/plone PGP.sig Description: This is a digitally signed message part ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: Updated PLIP review deadline
On Feb 14, 2008, at 12:05 PM, Martin Aspeli wrote: I still don't think this makes any sense. hi martin, since you've sent that mail to: me and i'm also the spokesperson of the framework team, i'll try to respond to a few bits. i don't really want to repeat everything i've said before, though, except for one point: i've merely _assumed_ the schedule would be shifted by two weeks, i.e. the time the bundle reviews were late (or, are going to be, hopefully...). that less than one week time span between the end of the reviews and the tagging of the first alpha has been like this from the start, and ultimately people seemed fine with it. i know there's also been a discussion back then, and i do agree with you that it leaves only very little time for you (PLIP authors), but blaming the framework team for this doesn't seem right imo. the team surely is to blame for other things, but it didn't set or change the schedule, except for prolonging the review period, of course. If you want to have everything *merged* by Friday the 22nd, then you (Wichert) will have to start doing those merges way before then. this is just a minor detail (and not to suggest there is enough time), but i'd like to add that the code was supposed to be tagged next friday, and the actual release was planned for monday. so the merging wouldn't have to take place before then. i've translated pre-release tagged into alpha freeze when putting up the calendar, which might be misleading. sorry about that. For the record, no-one's told me anything about my five bundles.There's been no centralised, proper communication with PLIP authors. Unless they are vigilant and watch Subversion and Trac for notes the trickle in at a random intervals, they are unlikely to have realised if they need to react. well, i guess the attempt to centralise things using trac tickets was maybe not such a good idea after all. the idea was in fact to make it easier for authors to keep track of things, but that was assuming everybody had filled in their email address to receive trac notifications (or was using rss), of course. i had tried to make sure all authors were cc'ed on the tickets, which is likely to be the reason why they were cc'ed way too little on the mails sent to the list. so yes, you're right about a lack of direct communication with the authors, and i apologize for being too ignorant about people like you, who wouldn't want to receive tons of trac mails. The Framework Team needs to bear some responsibility for the quality of the release, and that includes setting realistic expectations of PLIP authors. It also includes giving clear communication about what those expecations are, and taking into account that people will be doing this work in their spare time, with other time pressures. i agree, except that i didn't think this also includes changing the schedule. i was under the impression his was the job of the release manager, but maybe there's been some misunderstanding here. For example, if you'd met you original deadline, I would've had more time, since that deadline was set at a more advantageous date. Right now, I'm exhausted and fed up. i'm sorry about that, but i guess taking all author's personal schedules into account isn't really possible either. like i said, the time span between reviews and tagging is still the same, and the original schedule might also have worked worse (or better) for some of you. btw, i'm not particularly happy about the delay and the amount of additional work it creates... It leaves a really bad taste in my mouth that we have these discussions at nearly every single deadline we set. same here, except i wasn't involved in as many as you, of course. but may i point out that i think the problem in this particular case was probably that the initial discussion about the timeline imo never really reached a consensus? so, with the ambitious timeline set, it was more or less bound to resurface again, no? not to complain, though, just another thing we should try to do better next time... What if I'm busy this Sunday - potentially the *one* non-work day you give authors to react to the final reviews? It's the first weekend since the PSPS. The deadline recently slipped with lacklustre communication as to why, when the new deadline was, whether it was being adhered to and what would happen next. You are expecting PLIP implementers to be just sitting by ready to jump when you manage to get the reviews done. That's in no way fair. yes, our deadline slipped and communication bad, to say the least, but again, i don't think this really changed things for the PLIP authors. the problem lies in the original schedule, and the team didn't set that. however, this is not to blame wichert, though. we were all aiming for a very short cycle, and i think he just tried to make it as short as possible. as it seems we
[Framework-Team] Re: [Plone-developers] scope of reviews was: Re: Updated PLIP review deadline
On Fri, 15 Feb 2008 15:57:54 -0800, Andreas Zeidler [EMAIL PROTECTED] wrote: that stuff can amount to some serious time, i can tell you. indeed, mine took me something between two and four or maybe even five hours each. That would be a great things to have written down and communicated to the next Framework Team. Setting expectations is important. :) -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
