Re: [Framework-Team] The final(?) verdict
Thanks very much for the report Raphael. I'm going to treat this as the official recommendatation of the framework team. Some quick comments: Previously Raphael Ritz wrote: PLIP #201: Improve the UberSelectionWidget UI http://plone.org/products/plone/roadmap/203 https://dev.plone.org/plone/ticket/7736 Don't know, seems to me this might be deferred to 3.2 It does seem to look good already though. At those who looked more closely at it: what do you really recommend by now? I talked with Florian and Danny yesterday and tried it myself as well: at this moment USW is not ready yet so it'll be deferred. PLIP #202: Support inline validation and editing for formlib forms http://plone.org/products/plone/roadmap/203 https://dev.plone.org/plone/ticket/7737 +4 - but there is still some debate about what's the best way to handle the portal status message. Once this is sorted out (and implemented) it's ready for merge I agree with Danny that that must be fixed before merge. PLIP #203: Manage portlet assignments with GenericSetup http://plone.org/products/plone/roadmap/203 https://dev.plone.org/plone/ticket/7738 +3 - but before merge the encoding issue should be fixed (Martin might look at this later today) Must be fixed - this can break export on sites where export currently works. PLIP #204: Manage content rules using GenericSetup http://plone.org/products/plone/roadmap/204 https://dev.plone.org/plone/ticket/7739 +3 - but before merge the encoding issue should be fixed (Martin might look at this later today) Must be fixed - this can break export on sites where export currently works. PLIP #209: Add buildout to Unified Installer http://plone.org/products/plone/roadmap/209 https://dev.plone.org/plone/ticket/7744 +3 ready for merge but just so we don't forget: after merge we should again double-check that we don't give wrong advice to people about where to put add-on products in the file system in the Plone add-on products config panel (and maybe make it more obvious how to install eggs) SteveM contaced me about that yesterday and we agreed that the behaviour in Plone will change here: if it detects that it is run from a buildout (which we can easily see from the path) we will direct users to Martin's third party add-on tutorial on plone.org. PLIP #212: Use jQuery Javascript Library http://plone.org/products/plone/roadmap/212 https://dev.plone.org/plone/ticket/7747 +3 - but it seems there are a few little glitches still that may need some attention check back with danny and martijn before merging From what I've seen so far those glitches have been correctly ported from the current non-jquery codebase, so they should not prevent a merge. 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] The final(?) verdict
Previously Martin Aspeli wrote: Previously Raphael Ritz wrote: PLIP #201: Improve the UberSelectionWidget UI http://plone.org/products/plone/roadmap/203 https://dev.plone.org/plone/ticket/7736 Don't know, seems to me this might be deferred to 3.2 It does seem to look good already though. At those who looked more closely at it: what do you really recommend by now? I talked with Florian and Danny yesterday and tried it myself as well: at this moment USW is not ready yet so it'll be deferred. Florian wanted to add a some of the non-JS improvements that we built in - basically, the ability to include an initial query so that people have somewhere to start browsing for file selection use cases. That should be pretty unintrusive - I suggest we merge this bit if Florian can prepare it. We'll merge the changes to the sources indeed, just not the changes to the widget itself. I'll coordinate that with Florian. PLIP #202: Support inline validation and editing for formlib forms http://plone.org/products/plone/roadmap/203 https://dev.plone.org/plone/ticket/7737 +4 - but there is still some debate about what's the best way to handle the portal status message. Once this is sorted out (and implemented) it's ready for merge I agree with Danny that that must be fixed before merge. Do we have consensus here? IMHO, the portal message should just not be shown. It's not shown for AT edit forms as far as I recall. I'm happy to do whatever, though. Please take Danny's comments on that PLIP as guideline. On topics of user interface I'll be mostly channeling input from him anyway. 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: tomorrow's PLIP review deadline
On Feb 20, 2008, at 8:53 AM, Raphael Ritz wrote: Done. See my recent post to the list earlier today http://lists.plone.org/pipermail/framework-team/2008-February/001960.html (I didn't change any ticket status though) thanks a lot, raphael! much appreciated! :) 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.6 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] The final(?) verdict
On 20.02.2008, at 09:35, Wichert Akkerman wrote: Thanks very much for the report Raphael. I'm going to treat this as the official recommendatation of the framework team. and so will i. some of the +3 and +4 would actually need to be increased by one, namely my own vote, which i chose to cast 'blanket style', which i admit was not a good idea (and just being too lazy, shame on me!). seeing that there is no area of dispute i think it would be pointless for me now to go through all of them and still cast my vote but i do want to at least take this opportunity and promise to cast my votes explicitly for *all* plips for 3.2 ;-) i also want to thank andi for being a kick-ass (literally, sometimes!) framework spokesperson and raphael for stepping in. cheers, tom Some quick comments: Previously Raphael Ritz wrote: PLIP #201: Improve the UberSelectionWidget UI http://plone.org/products/plone/roadmap/203 https://dev.plone.org/plone/ticket/7736 Don't know, seems to me this might be deferred to 3.2 It does seem to look good already though. At those who looked more closely at it: what do you really recommend by now? I talked with Florian and Danny yesterday and tried it myself as well: at this moment USW is not ready yet so it'll be deferred. PLIP #202: Support inline validation and editing for formlib forms http://plone.org/products/plone/roadmap/203 https://dev.plone.org/plone/ticket/7737 +4 - but there is still some debate about what's the best way to handle the portal status message. Once this is sorted out (and implemented) it's ready for merge I agree with Danny that that must be fixed before merge. PLIP #203: Manage portlet assignments with GenericSetup http://plone.org/products/plone/roadmap/203 https://dev.plone.org/plone/ticket/7738 +3 - but before merge the encoding issue should be fixed (Martin might look at this later today) Must be fixed - this can break export on sites where export currently works. PLIP #204: Manage content rules using GenericSetup http://plone.org/products/plone/roadmap/204 https://dev.plone.org/plone/ticket/7739 +3 - but before merge the encoding issue should be fixed (Martin might look at this later today) Must be fixed - this can break export on sites where export currently works. PLIP #209: Add buildout to Unified Installer http://plone.org/products/plone/roadmap/209 https://dev.plone.org/plone/ticket/7744 +3 ready for merge but just so we don't forget: after merge we should again double-check that we don't give wrong advice to people about where to put add-on products in the file system in the Plone add-on products config panel (and maybe make it more obvious how to install eggs) SteveM contaced me about that yesterday and we agreed that the behaviour in Plone will change here: if it detects that it is run from a buildout (which we can easily see from the path) we will direct users to Martin's third party add-on tutorial on plone.org. PLIP #212: Use jQuery Javascript Library http://plone.org/products/plone/roadmap/212 https://dev.plone.org/plone/ticket/7747 +3 - but it seems there are a few little glitches still that may need some attention check back with danny and martijn before merging From what I've seen so far those glitches have been correctly ported from the current non-jquery codebase, so they should not prevent a merge. 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 mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] The final(?) verdict
Martin Aspeli wrote: [..] PLIP #202: Support inline validation and editing for formlib forms http://plone.org/products/plone/roadmap/203 https://dev.plone.org/plone/ticket/7737 +4 - but there is still some debate about what's the best way to handle the portal status message. Once this is sorted out (and implemented) it's ready for merge I agree with Danny that that must be fixed before merge. Do we have consensus here? IMHO, the portal message should just not be shown. It's not shown for AT edit forms as far as I recall. I'm happy to do whatever, though. As I feel kind of guilty here I try once more to explain my point of view. In Martin's original implementation the portal status message was left alone - which is what Danny is proposing also if I understand him correctly - but that reveals the following issue: Take the sample form shipped with the review buildout and just submit the form without entering anything (by pressing 'save' that is). You will get a portal status message Error: ... *and* the fields will be highlighted as usual. Now go and enter valid input. The fields will turn normal as you switch focus but the error message in the portal status message stays around resulting in a view of the form where there is an error message at the top of the page but no errors present. This is what I found confusing and why I introduced updating the portal status message from the inline validation as well. I agree that this has a negative impact on user experience as things start to jump around because of the portal status message changing but still I consider providing contradicting feedback to the user as we had it initially to be even worse. I don't know the solution to this myself and I would be happy to see this addressed the right way if somebody knows what the right way would be ;-) Raphael ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Ticket #7816 Improve Framework Team process
FYI, limi has created a ticket for improving the framework team process -- but s3kritly, it seems ;-). thanks to raphael for the pointer, though. perhaps others would like add themselves to the cc: list: https://dev.plone.org/plone/ticket/7816 cheers, tom ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] The final(?) verdict
maybe i didn't understand you correctly, but i was under the impression that you had additionally suggestded that the inline validation should als explicitly *clear* and statusmessages. this would certainly address the issue you're mentioning below... at least i think so. *scratches head* just my $0.02, tom On 20.02.2008, at 13:28, Raphael Ritz wrote: Martin Aspeli wrote: [..] PLIP #202: Support inline validation and editing for formlib forms http://plone.org/products/plone/roadmap/203 https://dev.plone.org/plone/ticket/7737 +4 - but there is still some debate about what's the best way to handle the portal status message. Once this is sorted out (and implemented) it's ready for merge I agree with Danny that that must be fixed before merge. Do we have consensus here? IMHO, the portal message should just not be shown. It's not shown for AT edit forms as far as I recall. I'm happy to do whatever, though. As I feel kind of guilty here I try once more to explain my point of view. In Martin's original implementation the portal status message was left alone - which is what Danny is proposing also if I understand him correctly - but that reveals the following issue: Take the sample form shipped with the review buildout and just submit the form without entering anything (by pressing 'save' that is). You will get a portal status message Error: ... *and* the fields will be highlighted as usual. Now go and enter valid input. The fields will turn normal as you switch focus but the error message in the portal status message stays around resulting in a view of the form where there is an error message at the top of the page but no errors present. This is what I found confusing and why I introduced updating the portal status message from the inline validation as well. I agree that this has a negative impact on user experience as things start to jump around because of the portal status message changing but still I consider providing contradicting feedback to the user as we had it initially to be even worse. I don't know the solution to this myself and I would be happy to see this addressed the right way if somebody knows what the right way would be ;-) Raphael ___ 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] The final(?) verdict
Tom Lazar wrote: Hi Tom, maybe i didn't understand you correctly, but i was under the impression that you had additionally suggestded that the inline validation should als explicitly *clear* and statusmessages. this would certainly address the issue you're mentioning below... at least i think so. *scratches head* Yes, it does. That's why I had introduced it in the first place. But this also has the unwanted side effect that things start jumping up and down whenever the portal status message gets inserted or removed. This is annoying and therefore it is suggested to leave the portal status message alone. But this would be exactly what Martin submitted in the first place where I stumbled across the issue I'm trying to raise (but seem to be unable to describe - I wish it were a five minute thing to do a screen cast ...) http://dev.plone.org/plone/changeset/19239 shows the changes I introduced: Line 66/67 issue a status message in case of an error occurring while 71/72 clear the message on error removal. Prior to that change the portal status message was left alone. Now, a variant that we might want to consider is only to clear (but not to issue the error in) the status message. That would address the specific concern I have about inconsistent feedback and make things jump around a bit less. Still not sure what's the right thing to do here though Raphael just my $0.02, tom On 20.02.2008, at 13:28, Raphael Ritz wrote: Martin Aspeli wrote: [..] PLIP #202: Support inline validation and editing for formlib forms http://plone.org/products/plone/roadmap/203 https://dev.plone.org/plone/ticket/7737 +4 - but there is still some debate about what's the best way to handle the portal status message. Once this is sorted out (and implemented) it's ready for merge I agree with Danny that that must be fixed before merge. Do we have consensus here? IMHO, the portal message should just not be shown. It's not shown for AT edit forms as far as I recall. I'm happy to do whatever, though. As I feel kind of guilty here I try once more to explain my point of view. In Martin's original implementation the portal status message was left alone - which is what Danny is proposing also if I understand him correctly - but that reveals the following issue: Take the sample form shipped with the review buildout and just submit the form without entering anything (by pressing 'save' that is). You will get a portal status message Error: ... *and* the fields will be highlighted as usual. Now go and enter valid input. The fields will turn normal as you switch focus but the error message in the portal status message stays around resulting in a view of the form where there is an error message at the top of the page but no errors present. This is what I found confusing and why I introduced updating the portal status message from the inline validation as well. I agree that this has a negative impact on user experience as things start to jump around because of the portal status message changing but still I consider providing contradicting feedback to the user as we had it initially to be even worse. I don't know the solution to this myself and I would be happy to see this addressed the right way if somebody knows what the right way would be ;-) Raphael ___ 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] Ticket #7816 Improve Framework Team process
On Feb 20, 2008, at 3:21 PM, Tom Lazar wrote: FYI, limi has created a ticket for improving the framework team process -- but s3kritly, it seems ;-). that's a PSPS focus area ticket, i.e. one of the things identified at the summit and assigned to be championed by someone, in this case matt. so i wouldn't exactly call this secret — not with the amount of public announcement and discussion we currently see on plone-dev anyway... kinda seems more likely you're currently not following any of that, doesn't it? ;) 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.6 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] The final(?) verdict
Andreas Zeidler wrote: [..] PLIP #216: Template overrides http://plone.org/products/plone/roadmap/216 https://dev.plone.org/plone/ticket/7750 -4 - never submitted (Raphael notes: not sure we are on trac here as all this is about is to include the z3c.jbot package from http://svn.zope.de/zope.org/z3c.jbot OTOH people who want that can just do it) well, i guess first of all the fact that no bundle was officially submitted means that the code hasn't been reviewed either. so i don't think we can include it into the distribution just like that. however, that's just a policy issue, not a technical one. on the technical side, however, i think we shouldn't just include more and more ways of customizing plone. people, i.e. developers and integrators, are already confused more than they should be. so what we really should do is think about better ways to integrate something like jbot with customerize and the old customization story to make the whole customization story more consistent. so imo this could very well go into 3.2, but more as some part of a bigger effort in that area. in short: i like the idea, but i'm -1 on including this _now_. Note that I said -4 - never submitted. My remark was triggered by looking at http://plone.org/products/plone/roadmap/216 and realizing that we were all positive on this in principle and then I started wondering whether that could have been interpreted as acceptance already because in contrast to most other PLIPs there is hardly any implementation involved (for the minimal solution at least). But I agree with everything you said above and I know some of us have been discussing this also at the summit and obviously we need a better and more streamlined customization story where jbot might be part of the solution but definitively not the only one. Considering that all our conversations here are archived and discoverable by search later on I thought in include PLIPs that were initially considered even though they finally never got submitted in the overview as well as adding comments where I deemed appropriate. This was not meant to question our current judgment though I now realize that I phrased it as such. Well, it can be tough at times to deal with such issues in a (for me and I know for many of us as well) foreign language after all :-( Raphael ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] WebDAV (PLIP 187) thanks and late comments
On 7 Feb 2008, at 02:15, Raphael Ritz wrote: Graham Perrin wrote: I'll be more than happy to help with the WebDAV aspect, if required. any kind of feedback is welcomeFeel free to provide any feedback you may have on this to the framework team list right away (included in cc). Thanks, Raphael In any case I have cc'd myself under https://dev.plone.org/plone/ ticket/7732. My apologies for being out of the loop. I was on leave for a week or so (Zope/Plone day slotted in the middle) with no real head space for testing. I realise that the deadline has passed, FWIW my +1 (though I'm not on the team ;) and comments are in Trac, around http://dev.plone.org/plone/ticket/ 7732#comment:17 https://dev.plone.org/plone/query?reporter=%7Egrahamperrinsummary=% 7EWebDAV is the sum total of WebDAV issues reported by me. I'll probably revisit the four January tickets after (a) a server upgrade, 3.0.4 to 3.1 and (b) a laptop Mac OS X upgrade, 10.4.11 to 10.5.2. On 18 Feb 2008, at 14:42, Sidnei da Silva wrote: 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 raising too high expectations where we aren't fully up to (yet) in order to avoid unnecessary frustration by those who might expect too much then. I think we are already setting too high expectations, as Plone is advertising WebDAV on the front page: Plays Well with Others LDAP, SQL, SOAP, Web Services (WSDL) and WebDAV — Plone works with them all. With respect: concerning WebDAV, I _do_ think that Plone's promise is not matched by its current delivery. Ending on positive notes: 1) It's very useful to learn (in this list) what other people expect from WebDAV. 2) At http://www.bud.ca/blog/plone-wishes Kevin Teague's '#16: IMPROVE DESKTOP INTEGRATION' was pleasantly thought provoking. I'll post my thoughts to plone-users via http://www.nabble.com/ General-Questions-f6742.html. Thanks to Sidnei, raphael, tomster, witsch and others involved in this PLIP :) Best, Graham ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] The final(?) verdict
On Feb 20, 2008, at 4:24 AM, Raphael Ritz wrote: Hi Folks, hi raphael, at Wichert's request and in order to update us all I've just compiled the following overview. nice job — thanks again for jumping in! PLIP #216: Template overrides http://plone.org/products/plone/roadmap/216 https://dev.plone.org/plone/ticket/7750 -4 - never submitted (Raphael notes: not sure we are on trac here as all this is about is to include the z3c.jbot package from http://svn.zope.de/zope.org/z3c.jbot OTOH people who want that can just do it) well, i guess first of all the fact that no bundle was officially submitted means that the code hasn't been reviewed either. so i don't think we can include it into the distribution just like that. however, that's just a policy issue, not a technical one. on the technical side, however, i think we shouldn't just include more and more ways of customizing plone. people, i.e. developers and integrators, are already confused more than they should be. so what we really should do is think about better ways to integrate something like jbot with customerize and the old customization story to make the whole customization story more consistent. so imo this could very well go into 3.2, but more as some part of a bigger effort in that area. in short: i like the idea, but i'm -1 on including this _now_. PLIP #224: CSRF protection framework http://plone.org/products/plone/roadmap/224 https://dev.plone.org/plone/ticket/7783 +2 - but either before or after merge efforts should be made to make use of those two new packages in the most important security related forms in Plone. AFAICS Andi is working on this currently but he sure would appreciate some help I guess. yes, i am and of course help is much appreciated. however, i think there's actually not to much left to do code-wise, but having someone review the changes to make sure we're still on the right track and not forgetting any or even introducing new security-issues would be a good thing, imho. so please let me know if you're interested! 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.6 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] Ticket #7816 Improve Framework Team process
On 20.02.2008, at 16:29, Andreas Zeidler wrote: On Feb 20, 2008, at 3:21 PM, Tom Lazar wrote: FYI, limi has created a ticket for improving the framework team process -- but s3kritly, it seems ;-). that's a PSPS focus area ticket, i.e. one of the things identified at the summit and assigned to be championed by someone, in this case matt. ah, i missed that bit. so i wouldn't exactly call this secret — not with the amount of public announcement and discussion we currently see on plone-dev anyway... kinda seems more likely you're currently not following any of that, doesn't it? ;) guilty as charged (seriously, i find it almost insane how much momentum plone is experiencing at the moment... i really have trouble keeping up with it all... but then again: what a truly great problem to have ;-) cheers, tom 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.6 released! -- http://plone.org/products/plone ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Plone 3.1 tree now opened
The framework team has delivered its verdict so we can proceed with the move towards Plone 3.1. I've created a new branch of ploneout: https://svn.plone.org/svn/plone/ploneout/branches/3.1 . As of now everyone should be aware of a few important changes: 1. All changes should be made on the Plone 3.1 and trunk branches. 2. From now on the 3.0 branch is only open for critical fixes, everything else should go in 3.1 and trunk. 3. Always make sure that any changes you make are done in a different branch than used by Plone 3.0. If necessary create new maintenance branches. 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] The final(?) verdict
On Feb 20, 2008, at 4:42 PM, Raphael Ritz wrote: Andreas Zeidler wrote: in short: i like the idea, but i'm -1 on including this _now_. Note that I said -4 - never submitted. yes, i know :) My remark was triggered by looking at http://plone.org/products/plone/roadmap/216 and realizing that we were all positive on this in principle and then I started wondering whether that could have been interpreted as acceptance already because in contrast to most other PLIPs there is hardly any implementation involved (for the minimal solution at least). but the code (in jbot) would have needed a review as well, so i couldn't have been accepted for inclusion at that point. Considering that all our conversations here are archived and discoverable by search later on I thought in include PLIPs that were initially considered even though they finally never got submitted in the overview as well as adding comments where I deemed appropriate. yes, and imho that was a good idea. This was not meant to question our current judgment though I now realize that I phrased it as such. no, it didn't really come across that way — it said note after all. :) 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.6 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] The final(?) verdict
On Feb 20, 2008, at 9:45 PM, Danny Bloemendaal wrote: Hi all, sorry for the late reply, had a busy day. Anyway, thanks again Raphael for your wrap up. On 20 feb 2008, at 15:48, Raphael Ritz wrote: Now, a variant that we might want to consider is only to clear (but not to issue the error in) the status message. That would address the specific concern I have about inconsistent feedback and make things jump around a bit less. Still not sure what's the right thing to do here though I'd say to just clear the message when it is no longer needed and indeed show the message if pressing the save button resulst in an error. That means that no message is shown during inline validation. If the message is cleared because inline validate caused all the error solved then that is ok. It would still be good though to have a more smooth disappearance of this. (When do we finally start using smooth transitions in plone???) perhaps as soon as 3.1 ;-) remember, we will have the full power of jquery at our hands. adding a smooth transition for disappearing the status message will be trivial, once florian has merge #212... good thinking, though. this is really a clear case when animation really serves a purpose and isn't just eye candy! hth, tom . At least you get rid of the sudden jumping and your eye can follow the current widget that has the focus. Danny. ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
