[Framework-Team] Re: The new Plone 4.0, was Re: Plone 3.5
On Tue, 05 May 2009 16:57:21 +0200, Hanno Schlichting wrote: Hi. To summarize the feedback from the European time zone, I think that the proposal in general meets the favor of everyone. The controversial issue is the exact version number to use for the release. There seems to be broad support for freeing the current Plone trunk from a version designator and release a 4.0 release with the envisioned scope of this proposal instead. If I do not get a strong signal or message otherwise, consider this proposal changed in this regard. Since I finally found out about this and catched up on this thread, I wanted to give my +1 to a Plone 4 with a reduced scope from the current trunk. Regards, Florian Schulze ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: PLIP review deadline has passed - time to review!
On Mon, 19 Jan 2009 13:43:47 +0100, Andreas Zeidler wrote: #232: "Resource Registries Improvements" — i've included the authors of these PLIPs via cc: hoping they might be able to clarify here. otherwise we'll have to skip reviewing them, which means they can't be considered for inclusion into Plone 3.3 either. I just realized that my mails never made it to this list. I worked on this PLIP last week and forgot about the review bundle. I did the review bundle on the same day I was informed by Andi about this and replied to Andis mail, but my mails to this list have been rejected without me noticing. The bundle is available at https://svn.plone.org/svn/plone/review/plip232-resourceregistries-improvements Do whatever you feel is right considering that I missed the deadline. Regards, Florian Schulze ___ 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
[Framework-Team] Re: Re: Testing for PLIP 209: Unified Installer Plus Buildout
On Thu, 14 Feb 2008 16:23:41 +0100, Wichert Akkerman <[EMAIL PROTECTED]> wrote: Previously Florian Schulze 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. I use 'bin/instance fg' a lot. In fact I use it 99% of the time when doing development. So I'm quite sure it works fine in buildouts. It runs, yes, but it doesn't switch to debug mode. Regards, Florian Schulze ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: Re: PLIP 212 ready for review
On Thu, 14 Feb 2008 13:57:42 +0100, Florian Schulze <[EMAIL PROTECTED]> wrote: The only thing I could reproduce was the searchterm highlight thing which I will look into. I fixed this. I should also make everyone aware that there is a test_ecmascripts template since Plone 2.1 :) It showed this error. Be aware that the Kupu tests fail in Safari until it's fully supported. Regards, Florian Schulze ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: Testing for PLIP 209: Unified Installer Plus Buildout
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. Regards, Florian Schulze ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: Re: PLIP 212 ready for review
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(c
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.
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] Re: PLIP 212 ready for review
On Tue, 12 Feb 2008 22:36:11 +0100, Tom Lazar
<[EMAIL PROTECTED]> wrote:
hi florian, hello fellow framework team members,
i started reviewing plip 212 on the plane back to berlin and got most
covered. i committed my initial review and post a copy of it here, for
your convenience. i still need to repeat the click tests i've done with
IE 6 and IE 7, as i haven't got Parallels installed on my macbook (yet).
also, i intend to look at the js code changes and migration stuff, but
judging from my previous experiences with florian's code i don't expect
any snags there. however, i did run into a few problems with this
buildout and currently don't think it's ready for merging, see my notes
below. i will continue the review tomorrow evening, along with my other
outstanding reviews.
Hi!
Thanks for the review. I just wanted to make clear that I didn't write any
of this code, I only wrote the PLIP, did the review buildout and foxed
some small things. All the heavy lifting was done by Martijn Pieters. I
will give some comments below.
--snip--
Note, all tests have been conducted with jquery 1.2.2 which is part of
the bundle, as well as with version 1.2.3 which is currently the latest
revision of jquery.
= manual click tests
performed with fresh checkout, new instance with Plone Default skin.
Using Firefox 2.0.0.12 and Safari Version 3.0.4 (5523.15), Win IE 6 + 7
tbd. Features and areas covered:
* livesearch, portal calendar pagination, external links, inline
editing, folder_contents reordering:
no problems encountered, everything worked as expected.
* highlighting of search results
This didn't work on any browser. Calling a url such as
http://localhost:8080/jquery/front-page?searchterm=comfortable would
not actually highlight the word (eventhough it exists in the default
front page)
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(c
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.
Additional errors:
the display menu wasn't working as expected, i.e. the click action on
the display menu was not caught but instead resulted in a page load of
the `select_default_view`, however, this only occurred with jquery
1.2.3, 1.2.2 worked fine.
workflow actions however didn't work in neither 1.2.2 nor 1.2.3, i.e.
publishing resulted in a page load instead of just a viewlet refresh.
This is either another syntax error, or some issue with the KSS
interaction.
= running unit tests =
running all tests (./bin/instance/test -v -v -s plone) produced the
following result:
Tests with failures:
test_published_news_items
(plone.app.portlets.tests.test_events_portlet.TestRenderer)
test_published_news_items
(plone.app.portlets.tests.test_news_portlet.TestRenderer)
/opt/zope/buildout/eggs/plone.app.workflow-1.0.1.1-py2.4.egg/plone/
app/workflow/tests/onestateworkflow.txt
Total: 1079 tests, 3 failures, 0 errors
I didn't look into this at all, because we didn't change anything besides
JS code and some registrations in JS registry. I will look into upgrading
the buildout to the latest Plone version if it isn't already.
= code review =
to be done (check migration, look into the js code changes)
Regards,
Florian Schulze
___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: Updated PLIP review deadline
On Thu, 07 Feb 2008 10:01:30 +0100, Martin Aspeli <[EMAIL PROTECTED]> wrote: Once you post your reviews (here?) what happens? How does the team arrive at a final yes/no vote? How long does that take? For 3.0, each reviewer posted a thread here with the necessary comments, including good points, bad points and recommendations. Discussion then ensued if necessary, with each member casting a +1 or -1 (or abstain). I then counted the votes, though in almost all cases there was consensus. We then reported back to the author (usually by just CC'ing them on the framework team list threads) and they were told either that it was rejected, or to make the necessary changes (if any) and prepare for merge. Wichert took the final decision on whether to merge or not. I think the process Andi started is good. The review notes go to svn and the tickets in trac get updated with a link and the author is CCed on the ticket. The relevant information is all in one place (svn) and the notifications are done through trac. This way it's easy to follow the review process even for outsiders, just by looking at the tickets they are interested in and checking the notes in svn. Regards, Florian Schulze ps: Lots of redundancy in the above sentences, but whatever :) ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: pyflakes? (was: Re: Translation effort for Plone 3.1)
On Fri, 01 Feb 2008 14:34:01 +0100, Andreas Zeidler <[EMAIL PROTECTED]> wrote: On Feb 1, 2008, at 2:24 PM, Wichert Akkerman wrote: Previously Tom Lazar wrote: given the aforementioned possibility of 3rd party breakage i think it's plain that 'pyflakes sanity' is a no-go for 3.1 but perhaps for 4.0? since that will necessitate 3rd party rewrites/adaptions anyway, might as well throw in pyflakes sanity, as well. You may need to properly deprecate things before removing them. hmm, unused imports? that might be a bit too much, no? i mean, i'd go ahead and remove any import statements i'm not using anymore in my packages, and that should be okay. imho, the only trouble are interface packages, otherwise people shouldn't import package a from package b anyway, but import it from a directly. so, how about this? deprecating imports in interface packages, which are not used in plone core, is okay as well as removing unused import from any other package? that's talking 4.0, of course... hmm, or maybe this could be a 3.2 PLIP, too, so we can deprecate things earlier. i mean, this policy shouldn't break anything provided all tests are passing. thoughts? I would deprecate ones which may be used in other packages for one major release and two major releases for the ones which affect persistent objects, because otherwise it's a pain to migrate. Regards, Florian Schulze ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: Re: PLIPs 208 and 217 Ready for Review
On Fri, 01 Feb 2008 13:41:40 +0100, Andreas Zeidler <[EMAIL PROTECTED]> wrote: On Feb 1, 2008, at 12:31 PM, Martin Aspeli wrote: -1 to renaming everthing plone.*. When things begin outside Plone (which we should encourage), then we can't necessarily insist that they are called plone.* (in fact, we'd probably discourage it if it wasn't intended to be eventually destined for the core). i completely agree. furthermore, i think using non plone.* packages in plone emphasizes one of the points made in the whole wsgi/repoze approach and the plone. (as opposed to plone.app.) namespace, which is that re-usability is a good thing and we'd like other people outside the plone/zope universe to start looking and potentially using our stuff as well. in that sense i think we should actually make a statement by integrating packages from the "outside world". and yes, that's not particularly true in this case, but at least it looks this way... ;) I'm also +1 on cooperation instead of assimilation (small pun on borg :P). Regards, Florian Schulze ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: PLIP 201 ready for review
On Mon, 21 Jan 2008 17:54:37 +0100, Andreas Zeidler <[EMAIL PROTECTED]> wrote: On Jan 20, 2008, at 12:35 AM, Florian Schulze wrote: Hi! hiya, PLIP 201 the mysterious ÜberSelectionWidget is ready for review! https://svn.plone.org/svn/plone/review/plip201-usw Review notes included in buildout. cool, thanks flo for making it — and sorry for being lame and not able to help out... :( family demanded some attention. Family and health is always first! If you wonder about the submission deadline, it's optiludes PLIP, so his time zone applies :P hmm, being in taiwan the deadline should have been even earlier for him, no? ;) Hmm, and his birth time zone is most likely norway, so there I would have been late as well :P But I meant his current living time zone which is the UK to my knowledge :) Regards, Florian Schulze ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] PLIP 201 ready for review
Hi! PLIP 201 the mysterious ÜberSelectionWidget is ready for review! https://svn.plone.org/svn/plone/review/plip201-usw Review notes included in buildout. If you wonder about the submission deadline, it's optiludes PLIP, so his time zone applies :P Regards, Florian Schulze ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] PLIP 212 ready for review
Hi! The buildout is at https://svn.plone.org/svn/plone/review/plip212-jquery Notes are in the buildout. This PLIP needs to most QA I guess. Especially the folder_contents stuff should be tested, as I found some typos in there and I don't know the full functionality set of it to test it. It's part of the kss plugins. Regards, Florian Schulze ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] PLIP 213 ready for review
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] Re: Re: PLIP #212: Use jQuery Javascript Library
On Fri, 14 Dec 2007 19:00:43 +0100, Alec Mitchell <[EMAIL PROTECTED]> wrote: On Dec 14, 2007 5:36 AM, Florian Schulze <[EMAIL PROTECTED]> wrote: On Fri, 14 Dec 2007 07:37:14 +0100, Alec Mitchell <[EMAIL PROTECTED]> wrote: > On Dec 12, 2007 9:27 AM, Florian Schulze > <[EMAIL PROTECTED]> wrote: >> Hi Framework Team! >> >> >> This is the other PLIP I want to propose besides #213. Martijn did all >> the >> hard work for it already. >> >> http://plone.org/products/plone/roadmap/212 > > Just a comment from a non-FT member. I think the work done for this > PLIP is great, and the simplification of the js code (less to > maintain) is very important. However, I'm a bit disappointed that > it's not using KSS stylesheets to do the bindings, but instead using > jQuery directly. Another IMO big reason is that KSS bindings only work if the Browser supports AJAX and some things should still work without that IMO. Also some things can't be expressed as CSS selectors easily, so the only possible binding would be the onload handler. BTW, I'm not sure there is an ondomload in KSS, so for some things like the focus on first input element we should stick to the current way, because the latency is important in this specific case. I'm pretty sure the KSS load event is actually implemented as ondomload, though it would be nice if it made a normal onload possible as well. Any event besides load is also easily bound using KSS. Though I'm sure there exist a few things which aren't easily expressed using KSS's declarative syntax, I'd be surprised if it were more than a few corner cases. Regarding AJAX requirements, I don't think this is true at all. KSS stylesheets simply provide a mechanism for binding actions, when those actions are js actions on the client no AJAX is needed at all (though AJAX can be used to trigger those actions, which is an added bonus, a necessity even when you start reloading significant portions of the page using ajax requests). I'm pretty sure the kss js still loads and operated for client actions even on those clients that don't support xml requests. The KSS files are loaded by XMLHTTPRequest, so only browsers supporting this will get the bindings. And because it's a separate request, there is some slight latency involved. As with any additional requests, this highly depends on caching and how the browsers implement the various parts involved with this. I can't comment on any further details, because the exact implementation in current KSS is unknown to me. As you said this only affects some corner cases. One IMO is the autofocus, the other are the dropdowns, everything else shouldn't be critical and can be moved to use KSS binding at some point, though not for 3.1, as the implications aren't yet known (besides needing KSS in the first place). Regards, Florian Schulze ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: PLIP #212: Use jQuery Javascript Library
On Fri, 14 Dec 2007 07:37:14 +0100, Alec Mitchell <[EMAIL PROTECTED]> wrote: On Dec 12, 2007 9:27 AM, Florian Schulze <[EMAIL PROTECTED]> wrote: Hi Framework Team! This is the other PLIP I want to propose besides #213. Martijn did all the hard work for it already. http://plone.org/products/plone/roadmap/212 Just a comment from a non-FT member. I think the work done for this PLIP is great, and the simplification of the js code (less to maintain) is very important. However, I'm a bit disappointed that it's not using KSS stylesheets to do the bindings, but instead using jQuery directly. Another IMO big reason is that KSS bindings only work if the Browser supports AJAX and some things should still work without that IMO. Also some things can't be expressed as CSS selectors easily, so the only possible binding would be the onload handler. BTW, I'm not sure there is an ondomload in KSS, so for some things like the focus on first input element we should stick to the current way, because the latency is important in this specific case. I agree that we should revisit all Javascripts (for 4.0?) and decide which can be bound by KSS or even replaced by it. Some key functionality should be done the old way though. Regards, Florian Schulze ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: new KSS versions
On Thu, 13 Dec 2007 11:44:34 +0100, Godefroid Chapelle <[EMAIL PROTECTED]> wrote: Florian Schulze wrote: ... checking which one is loaded. One thing just occured to me. I think jQuery tends to use XPath like selector syntax instead of CSS3 in some special cases, for kss files it would be desireable to be as CSS3 like as possible, so this should also be a consideration. If this last sentence mean that jQuery selector function mixes XPATH syntax with CSS syntax, I think we should keep base2 inside KSS, in order to keep K stylesheets coherent. Which is what you are meaning, right ? I just checked to be sure and I got it the other way around. They *removed* the XPath parts which slipped in and are now compatible with CSS. The only exception (which shouldn't be a problem) is for attribute selectors like a[href] which can also be written as in XPath as [EMAIL PROTECTED] So there should be no problem with using jQuery. Regards, Florian Schulze ps: I got this from the announcements in their blog (on 1.1.4 and 1.2 releases) ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: new KSS versions
On Thu, 13 Dec 2007 10:03:03 +0100, Balazs Ree <[EMAIL PROTECTED]> wrote: Dear Framework Team, we submitted the following plip: http://plone.org/products/plone/roadmap/215 We suggest to use the following new kss package versions for Plone 3.1: kss.core New kss.core version 1.4, currently on trunk, will be ready to be released in January. At the moment the code is testable on trunk. Key improvements that come with the new version are: * faster page load with base2 * syntax improvements, eg. recursive value providers, comma separated selectors The last one "comma separated selectors" is important IMO and makes for smaller and more readable kss files. As already pointed out in this thread, base2 and jQuery are almost interchangeable for their selector capability. AFAIK both are really fast and especially error free. I also heard jQuery is beginniung to incorporate speed improvements from base2. Anyway, in KSS it's just a few lines of code to switch and it can be done automatically by checking which one is loaded. One thing just occured to me. I think jQuery tends to use XPath like selector syntax instead of CSS3 in some special cases, for kss files it would be desireable to be as CSS3 like as possible, so this should also be a consideration. Regards, Florian Schulze ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] PLIP #212: Use jQuery Javascript Library
Hi Framework Team! This is the other PLIP I want to propose besides #213. Martijn did all the hard work for it already. http://plone.org/products/plone/roadmap/212 Regards, Florian Schulze ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] PLIP #213: Prepare for better Syndication
Hi! I propose the following PLIP: http://plone.org/products/plone/roadmap/213 It's a very small one, but with a small risk, so I think this should go the proper PLIP way. The implementation just needs to be backported, which means removing a few lines and using the newer version of plone.app.layout from trunk. Regards, Florian Schulze ps: I started a draft for another, bigger one, which will probably be expanded by MJ tomorrow, but I provide the link for anyone interested: http://plone.org/products/plone/roadmap/212 ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: Re: Re: Move footer.pt and colophon.pt to viewlets?
On Fri, 08 Jun 2007 11:13:35 +0200, Martin Aspeli <[EMAIL PROTECTED]> wrote: I would agree. With the benefit of hindsight, I think (almost) anywhere in main_template that we use a metal:use-macro should be a viewlet, because it makes it much easier to re-order, hide and move elements. For example, I need to put something abovethe content views (green tabs) inside the main column, which I can't do without touching main_template. More or less anything else I've wanted to do, I've been able to do with viewlets.xml and a couple of viewlet re-registrations, which feels a lot more future-proof. +1, especially for the before green tab one, I need that as well. Regards, Florian Schulze ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: Refreshing templates / CSS no longer works?
On Sat, 07 Apr 2007 10:11:17 +0200, Balazs Ree <[EMAIL PROTECTED]> wrote: The other morale of the story is that I reacted to Florian a little angry when he said straight "you are obviously doing something wrong there" before he knew what actually happens, and although I was not aware of the real case either I apologize for my misreaction openly and thank to Florian for spending his valuable time on this. I didn't point to you, but to the change which caused the problems. It just happens that you added that line and I found it by binary searching for breakage by date. That the line itself was innocent was another thing. I just wanted to give a fix for people so they can work normally on template improvements. I'm sorry if it sounded like I blame you specifically. That wasn't the intention. The mail I got from you sounded more frustrated than angry and you made that clear at the top, so you just vented a bit :) Now to point 1. Why do we need this service view at all? On some hand it is true that this is kind of testing -but it is not analogue to our unittests. We have no way of activating this code from the tests and let it disactivated by production run, because at the moment the selenium tests are manual and the site for them must be created manually too. If we leave the config uncommented, it will be troublesome for (some) people to comment it back, there will be a constant danger of an accidental commit back, plus really at this moment we only use 3.0 for development/ testing and not production. So imo a "sevice view" that will not be accidentally invoked, can only run by the admin by url, but that yet is widely available, is an acceptable solution for this. However Wiggy suggested that we take this out from being a view and make it as a GS extension profile. This is something I like better then the view. However in this case some people may complain that every time you create a plone site, you will see "create selenium testsite" in the list of extensions. If this is acceptable I'd go for it but it would be good to discuss this in advance. In any case I believe it is important that before we find a way to hide this functionality from production (well, the view is kind of hidden now) we leave it on by default, because we must encourage people to run selenium tests and make it as easy as possible to start. The view is actually ok IMO based on the need you outlined. It's only available to site managers and not publically visible. I think it's similar to the test_ecmascripts.pt, no one in the public knows it, so no one takes offence :) I'm +1 on keeping the view to make it easy to run the tests in browsers. That's important IMO. We need to be able to tell people "go to this url and see if you get any failures". Regards, Florian Schulze ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: The big 3.0 ;)
On Tue, 03 Apr 2007 21:59:05 +0200, Jeroen Vloothuis <[EMAIL PROTECTED]> wrote: Wichert Akkerman wrote: - Get a basic UI on ÜberSelectionWidget It has a basic UI, just no ajax interface. Nobody appears to be doing that either, so we're going to have to postpone that until 3.5. I was looking into this. Then I ran into a problem with z3c.widget because it was not a proper name space package. I offered to change it and received positive feedback. Today I got Zope commit access so I can start working on this. This week is filled with PyWeek. Therefore it will take some more time before this is finished (definitely not for 3.0). What does Zope commit access and z3c.widget have to do with ÜberSelectionWidget? Regards, Florian Schulze ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: NuPlone and Plone 3.0
On Wed, 04 Apr 2007 09:12:43 +0200, Alexander Limi <[EMAIL PROTECTED]> wrote: - Work on IE6/7 issues towards the RCs Too late IMO, spliter offered to help here, but I guess he would like to know the chances on NuPlone to be included before he invests energy in this. So it needs to be feature complete first. Regards, Florian Schulze ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: The big 3.0 ;)
On Wed, 04 Apr 2007 09:09:27 +0200, Alexander Limi <[EMAIL PROTECTED]> wrote: 3.0.x minor are for bug and security fixes, not feature changes. So in 9 months, we can add comments without reloading the page, great... I understand this frustration, but agree that minor releases shouldn't have new features. *But*, I think we should really consider 3.1.x. The question is how we manage this. Regards, Florian Schulze ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: The big 3.0 ;)
On Tue, 03 Apr 2007 20:21:06 +0200, Martin Aspeli <[EMAIL PROTECTED]> wrote: Wichert Akkerman wrote: - Move sendto/print/whatever to bottom of page, use text representation Needs to happen soon or becomes 3.5 material. Bear in mind this probably has an impact on third party products' view templates if they need to change to be consistent with the "new" standard. That's why we switched to viewlets. 3rd party products need to adapt anyway now. The change itself is then transparetn to 3rd party products. Regards, Florian Schulze ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: The big 3.0 ;)
Hi! I also think we should avoid the context switch to the ZMI. We were advocating this all the time. I think we should have a site configuration like we have now and another one for advanced stuff. The advanced one should have a big warning like "Be sure you know what you do here, or you will shoot yourself in the foot. We decided to not hide the gun, but we warn you about it's use!". I certainly wouldn't care about a policy to move configuration to the ZMI just because it's more complex for stuff I do. I know giving people to many options is bad, that's why I think there should be a difference for standard configuration and advanced configuration. I also think optilude has a point in providing some configuration only via local utilities to the developer. But this should be done in a sane way and not require overrides.zcml or something like that. It should just be a matter of subclassing aan existing utility, change some variables and register it locally for the site it should be used for. Regards, Florian Schulze ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: The big 3.0 ;)
On Fri, 23 Mar 2007 07:43:13 +0100, Alexander Limi <[EMAIL PROTECTED]> wrote: - Fieldsets - Do we still support fieldsets that require something on fieldset #1 to be filled out before you can access fieldset #4? You mean the wizard style like before? You have to use a marker interface for this, then the fieldset stuff isn't used for that type. - Next button shows up in the Save/Cancel area when using the inline fieldsets? Probably an oversight, should just be hidden. - Fieldset code: if more than N (N=6?) fieldsets, turn into pulldown You mean a pulldown? Regards, Florian Schulze ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: Re: The big 3.0 ;)
On Fri, 23 Mar 2007 13:03:58 +0100, Wichert Akkerman <[EMAIL PROTECTED]> wrote: > - Can the old-style Add-on products support TITLE.txt to match > the new style products' ability to have a "friendly name"? What does this mean? It means people need to get of their ass and switch to GS profiles. Not supporting something like title.txt only encourages that imho. I see a problem with that. I think GS first needs to be expanded to really support product installation and uninstallation before everyone would switch to GS profiles. I'm not sure how this should work though. Regards, Florian Schulze ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Base tag
Hi! We recently removed the base tag from the main_template. This was done to fix a bug with selecting text in IE [1] and to prevent a reload on links to anchor tags. Now we found more and more problems with relative links. The most glaring examples are the links to site setup and other stuff on the front page of a newly created plone site when used on localhost. A proposed solution is to append a slash on the URLs of all folderish content and rewriting relative URLs to absolute ones on render. This would introduce quite a lot of code though. So we have to decide whether we want to fix this, or revert the change and have the base tag back. My vote is to revert for Plone 3.0 and try to fix it properly in Plone 3.5. https://dev.plone.org/plone/ticket/6236 Regards, Florian Schulze [1] http://www.456bereastreet.com/archive/200608/base_elements_cause_text_selection_problems_in_ie/ ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: Re: Inline editing
On Mon, 05 Mar 2007 00:35:51 +0100, Alexander Limi <[EMAIL PROTECTED]> wrote: On Sat, 03 Mar 2007 15:04:17 -0800, Sidnei da Silva <[EMAIL PROTECTED]> wrote: 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. We already support selection, it's the people that double/single-click (not select) content to read that are having problems. And it currently breaks at least on FF2/Mac. It always goes into edit mode. Regards, Florian Schulze ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: Inline editing
On Fri, 02 Mar 2007 17:19:30 +0100, Sidnei da Silva <[EMAIL PROTECTED]> wrote: It should be possible to differentiate a 'click-and-drag' from a simple 'click' right? I'm sure someone thought about this. :) Yeah, that works, problem is that I often use doubleclick-drag to select full words. This worked at list in Safari before this change, in Firefox that invoked the inline editing. A problem I have with the single clicking is activating the window, which sometimes also invokes the inline editing. Or clicking somewhere to get the focus right for scroll-wheel scrolling etc. Regards, Florian Schulze ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Inline editing
Hi! First things first, this isn't against inline editing in general, so relax Godefroid and Balasz :) This is against the UI decision made by Limi which I already discussed with him. Very recently the inline editing was switched from double clicking to single clicking. IMO this is the worst change in the UI I saw till now. I understand the reasoning by Limi. If the mouse hovers the editable element looks (more or less) like a text box and when you click into it it should be made editable. This follows user expectations and is perfectly valid for the places it's used in Google Calendar. For content pages like in Plone this is very bad IMO. And I guess Geir agrees with me here (he constantly clicks around and selects text while reading :) ). I think we should either limit the inline editablility to certain fields (exclude RichTextFields for example) or do the invokation differently. I proposed to use an icon in a corner of the editable part, but Limi is right in that he says it's a too small area to click onto and not obvious what it may mean. I would really like opinions on this. Regards, Florian Schulze ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: content tab switching
On Wed, 28 Feb 2007 09:48:00 +0100, Godefroid Chapelle <[EMAIL PROTECTED]> wrote: I have the feeling that, if we just disable those stuff now, the generic problems they trigger will never be solved. OTOH, I totally agree that 3.0 final should not ship with stuff we know is really not usable. I propose that we keep the stuff as late as possible, trying to solve the history and autofocus issues and postpone the decision. IMO, postponing is not a risky decision as it is so easy to do the disabling : comments in a single file. That reminds me that I have to look into why RR has problems merging kss files (which should live in their own registry anyway). If that problem is solved, we can easily split the kss files into more pices and enable/disable them easily and thus write configlets to do that. Regards, Florian Schulze ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: plip 101 - batch and sort
On Tue, 23 Jan 2007 23:58:06 +0100, Martin Aspeli <[EMAIL PROTECTED]> wrote: I think he may have been talking about a different Florian, but I do sincerely hope you get more involved in our KSS story, we need it! Oh, right :) There is another Florian involved in this :) Regards, Florian Schulze ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: plip 101 - batch and sort
On Tue, 23 Jan 2007 14:22:18 +0100, Godefroid Chapelle <[EMAIL PROTECTED]> wrote: Florian, how is your experience with KSS ? It would be interesting to have some feedback. Balazs and I (at least) will be sprinting in the snow. So we could take a look at your remarks, if there are any. I didn't really look at it since the Archipelago sprint. I briefly followed checkins and made some remarks to Balazs, but nothing serious. I will probably have the most contact with it during the UI sprint. Regards, Florian Schulze ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] AT Schema and Zope 3 [was: Re: Login redirect in 3.0?]
On Thu, 28 Dec 2006 12:14:13 +0100, Martin Aspeli <[EMAIL PROTECTED]> wrote: Florian Schulze 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. You can do this now if you use ContentFlavors (the 3.0 branch), which is in AT svn. The necessary wiring is in AT, but CF probably needs a bit of updating as I'm intending to bend Kapil's use cases a bit. The necessary wiring is in AT. On the other hand, if we don't mind ATCT depending on plone.app.redirector, we can do this the usual way, with a write-only field and a custom mutator. I just looked at the source, so I might be wrong. AFAICS there are two problems: 1. If we want to change something in the Schema globaly, then we have to overwrite the adapter from BaseObject to ISchema. Overwrites shouldn't be used in a framework though. 2. AT expects the mutators to be available in the context. I'm not really sure about this. Let's see how we could to the alias stuff: - We either overwrite the adapter from BaseObject to ISchema or use a more explicit one from the ATCT base object (which would make it work for ATCT types only). - In the new adapter we return the original Schema plus the new fields for the alias stuff - When the form is saved BaseObject._processForm iterates over all the fields of the Schema, gets the widget, calls widget.processForm, then gets field.getMutator and calls it - To make this work we return our own field with our own widget and mutator I think what's missing here is a way to provide an adapter from BaseObject to ISchema which is extendable by products. Maybe we could make archetypes_tool a local utility and provide a way to register additional Schema parts. I currently have no real idea how this could work properly. Maybe we should also use interfaces for Fields and Widgets in _processForm to make this more flexible. Any ideas and insights welcome. Regards, Florian Schulze ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: Login redirect in 3.0?
On Thu, 28 Dec 2006 06:59:29 +0100, Alexander Limi <[EMAIL PROTECTED]> wrote: On Wed, 27 Dec 2006 08:20:48 -0800, Martin Aspeli <[EMAIL PROTECTED]> wrote: Note, plone.app.redirector does not have a UI like RedirectionTool does for adding specific redirects, but adding the necessary forms would be fairly trivial (it'd just need to talk to the IRedirectionStorage local utility, which already has the necessary methods to query existing redirects and remove or update them). OK, /login it is. I don't feel strongly about it. :) The in-place UI (ie. not the global control, but the "I want to add an alias for this document" use case) for a redirect should ideally be in one of the existing tabs on the new fieldset-based forms (using the term "Alias" as earlier). 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. Regards, Florian Schulze ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: Can I merge plone.memoize and plone.app.layout?
On Sun, 03 Dec 2006 14:01:50 +0100, Martin Aspeli <[EMAIL PROTECTED]> wrote: Hi guys, Following discussions with Whit, Alec and Rocky on the channel last night, and from the lists before, I've created and checked in two packages: - plone.memoize: contains Whit's memojito memoization decorators (in plone.memoize.instance), and a variant of it that memoizes values in the request for views (plone.memoize.view). - plone.app.layout: contains a view viewlet manager definitions (plone.app.layout.viewlets) and a set of views that contain several of the values from global_defines, but cleaned up (plone.app.layout.globals). These are memoized using the view memoization in plone.memoize. [snip] Is this OK? Martin Hi! I did no benchmarks yet, but it feels quite a bit faster now. Did anyone do some before after comparisons? Regards, Florian Schulze ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: PLIP 178 review
On Mon, 06 Nov 2006 00:20:35 +0100, Wichert Akkerman <[EMAIL PROTECTED]> wrote: I did a quick review of PLIP 178. This is based purely on the output from: svn diff -r 11240:HEAD \ https://svn.plone.org/svn/plone/CMFPlone/branches/plip178-back-to-icons-as-images which gives you a list of all changes from the trunk. I have not tried to run the code. PLIP 178 modifies the icon handling in templates to use img elements instead of CSS classes. The icon is determined by calling a new getIcon method on IPlone. This will try to adapt the object IContentIcon, a simple adapter which returns all icon information. This approach makes icon handling very flexible. I have a few remarks on the implementation, most of which are trivially fixe: * folder_factories hardcodes the icon size; it should use the icon size as provided by the IContentIcon interface * livesearch_reply does not set the width and height attributes on the img element; it probably should. For AAA reasons it probably should set an (empty?) alt attribute as well. * I am wondering if there are there possible use-cases for still keeping the contenttype- CSS classes? * The interface for getIcon describes the return value as a dictionary, which is not true: it is either a dictionary or a IContentIcon instance. It should describe the the mandatory and optional attributes in the returned object, as well as what will be returned if there is no icon. Finally something to think about: if we're extending things anyway, would it be useful to add an option to request the icon in different sizes? I can image that at some places in the UI you want to have a large icon instead of a small one. Wichert. This PLIP should be finished now. Regards, Florian Schulze ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: PLIP 178 review
On Mon, 06 Nov 2006 06:16:31 +0100, Alexander Limi <[EMAIL PROTECTED]> wrote: On Sun, 05 Nov 2006 19:26:23 -0800, Alec Mitchell <[EMAIL PROTECTED]> wrote: At least for BBB these should be kept (though how do you deprecate something like this), it's quite likely people are using these classes for some purpose. Keep the class names around for one release (in the code), but turn off the CSS, put generated.css in the plone_deprecated dir. Not perfect, but good enough for people to retrofit it onto a site, should it be needed. I doubt anybody outside of Plone uses the CSS implementation of this, though - getIcon is much simpler inside a particular content type. This makes no sense, because the markup changed in many places, I removed wrapping spans which were only for the icon etc. If this should really be kept, then I can try to put that back in. Regards, Florian Schulze ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: PLIP 178 review
On Mon, 06 Nov 2006 00:20:35 +0100, Wichert Akkerman <[EMAIL PROTECTED]> wrote: Thanks for the review, I will fix the mentioned issues ASAP. Finally something to think about: if we're extending things anyway, would it be useful to add an option to request the icon in different sizes? I can image that at some places in the UI you want to have a large icon instead of a small one. I'm not sure this should be added to getIcon directly. IMO the CA and the way I use it in getIcon makes it possible to declare a specific adapter for a template to override the default behaviour, so for example in folder_listing you could use 32x32 icons. We currently don't have different icon sizes, so what would happen if you request a bigger icon which doesn't exist? IMO we shouldn't add explicit size requests. For limis idea of previews I would propose to add something similar to getIcon named getThumbnail. For this we should also add the possibility to request the size. Content types like file could even add previews for PDFs and other formats easily with this. I wouldn't mix these two functions into one, it makes it too complicated IMO. Regards, Florian Schulze ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] PLIP 127 - Fieldsets on edit screen
Hi! I just wanted to note, that from my point of view the plip 127 implementation is complete. I kept the review branch up to date, fixed some small issues I found (mainly visual glitches) and updated the history files. Regards, Florian Schulze ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: Review for PLIP 127 - commenting
On Mon, 18 Sep 2006 14:32:23 +0200, Vincenzo Di Somma <[EMAIL PROTECTED]> wrote: Introduction The PLIP 127 suggests to clean up the content UI by moving the Properties to a grouped schemata on the edit screen to improve the usability of Plone (for details: http://plone.org/events/sprints/past-sprints/archipelagosprint/report/images/fieldsets.mov). Implementation The implementation touches the CMFPlone and the Archetypes packages. The CMFPlone part is very simple, looks nearly completed and presents no relevant risks. The part that involves Archetypes is basically the merge of dhtml-schemata branch and still need work to be completed. The grouping of properties like it appears on the video is not implemented yet. Conclusions The features proposed are a useful usability improvement that I would like to have in Plone but there is still work to be done on the product before the merge. Thanks, vds Hi! I'm trying to answer on this list, I'm not sure it will go through though. Last week and on this weekend I basically finished the PLIP 127 implementation, only the history files need an update. I didn't see a mail by Vincenzo since I last talked to him, so I write in the hope that PLIP 127 may be merged before Plone 3.0 alpha 1 gets released. Regards, Florian Schulze ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
