[Framework-Team] PloneErrorReporting
Hi, Could we please remove PloneErrorReporting from Plone 3.0? - Everybody ends up installing it in their sites, meaning their users get pages and pages of error messages. - Sending people to the Plone issue tracker when something goes wrong on random site XYZ.com is not very useful. - It's another thing to keep track of and update/release. - It was never proposed in a proper manner, it suddenly showed up in a release somewhere along the line, and nobody took it out. Related, I want to do the following to minimize the information disclosure and potential security problems, as well as making the error page friendlier: http://dev.plone.org/plone/ticket/6277 Should be a very straightforward sprint task for the people there this week. :) -- Alexander Limi · http://limi.net ___ 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 Sat, 24 Mar 2007 05:00:05 -0700, Daniel Nouri <[EMAIL PROTECTED]> wrote: I know that the difference between ZMI and Plone configuration has traditionally been: "If you need to do more than that, go to the ZMI", even if more by accident than by anything else. I don't see why we should cling to this distinction. Because now it's by design, not by accident. -- Alexander Limi · http://limi.net ___ 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 Sat, 24 Mar 2007 03:04:50 -0700, Geir Bækholt · Plone Solutions <[EMAIL PROTECTED]> wrote: Yes. of course the :default must be supplied or the checkbox will not be noticed by html. I somehow took this for granted and didn't mention it (sorry. my oversight), but i see now in boolean.pt widget template in AT that it is not included. Zope has its own built-in form typecast for this: Works for all cases i can find. I don't have the 10 minutes i need to actually check it into AT and test that it works TTW right now, but i'll try to get it done tonight unless someone beats me to it. Old-skool Zope power ;) Geir just checked in the fix, and it seems to work for everything I was able to test. -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: The big 3.0 ;)
Alexander Limi wrote: On Sat, 24 Mar 2007 13:26:43 -0700, Alexander Limi <[EMAIL PROTECTED]> wrote: Again, I strongly recommend that we disable this *unless* the KSS people have time (and willingness) to spend fixing history+URL injection. That sentence was missing a "for now". :) I'm happy to reintroduce it in a later version once we know that it works properly, but right now I don't think it's ready. This is pretty much the consensus we had when we discussed this a couple of weeks ago. The idea was that we wait for as long as we can before disabling it so that people have a chance to continue to test and work on it. If we can't make history faking work, then we disable, which only really means commenting out a few lines of KSS. Martin ___ 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 Sat, 24 Mar 2007 13:26:43 -0700, Alexander Limi <[EMAIL PROTECTED]> wrote: Again, I strongly recommend that we disable this *unless* the KSS people have time (and willingness) to spend fixing history+URL injection. That sentence was missing a "for now". :) I'm happy to reintroduce it in a later version once we know that it works properly, but right now I don't think it's ready. -- Alexander Limi · http://limi.net ___ 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 Sat, 24 Mar 2007 07:19:32 -0700, Martin Aspeli <[EMAIL PROTECTED]> wrote: This should now be fixed, svn up plone.app.layout. Note that with KSS inline tab reloading and inline content view switching, you'll need to reload the page manually, because KSS doesn't yet refresh the menu as well as the thing inside the border. See https://dev.plone.org/plone/ticket/6272 I thought we stopped doing that because of the URL/history breakage, but I guess that was just a side effect of KSS being broken for a while. Chalk up another good reason to not do the dynamic replacement of the content area. It's also extremely confusing when you do History comparisons, since the standard pattern is to: - Go to the history page - Compare two revisions - Discover that it was the wrong revision, hit the back button to check a different revision - Suddenly you are back at the view page *of the previous object* you looked at Very bad indeed. Again, I strongly recommend that we disable this *unless* the KSS people have time (and willingness) to spend fixing history+URL injection. -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: The big 3.0 ;)
Alexander Limi wrote: On Fri, 23 Mar 2007 17:49:50 -0700, Martin Aspeli <[EMAIL PROTECTED]> wrote: Martin Aspeli wrote: - Only show the Display/Add/WF pulldowns on the View screen - Possibly remove the border on initial creation forms (ie. keep the actual green border, but remove everything clickable on it, since it causes errors) +1 We already do this with formlib-based add forms from plone.app.form. Done both of these: no border/tabs on the "add form" with portal factory or formlib, and no drop-downs except on the View tab. The former is done with a check in base_edit; the latter is done with a content provider registration: the menu is registered for view = IViewView, whilst there is a fallback one for IBrowserView that is just empty. Great! It has one bug, though: I just created a new site after doing svn up, and on the front page (which is a default view in the portal), you don't get any menus, so it's hard to add anything. In fact, since that's the only page (and the menus are missing from folder_contents), you can't really add anything anymore, which is unfortunate. :) This should now be fixed, svn up plone.app.layout. Note that with KSS inline tab reloading and inline content view switching, you'll need to reload the page manually, because KSS doesn't yet refresh the menu as well as the thing inside the border. See https://dev.plone.org/plone/ticket/6272 Martin ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: The big 3.0 ;)
Alexander Limi wrote: > > > On Fri, 23 Mar 2007 05:00:45 -0700, Daniel Nouri wrote: > >> Do you want to tell (core) add-on developers to not make use of the >> niceties >> of plone.app.controlpanel because their thing is too complex? > > Uhm, if people can't use zope.formlib anywhere else than in > plone.app.controlpanel, then this is a totally different problem. Let me > turn it on its head: Do you want developers to expose every single > setting in the Plone control panels because it's easier than doing it in > other locations? > > Now, *that's* wrong, if you ask me. :) Frankly, I think that requiring people to learn another way to add TTW configuration makes the contribution story harder. I certainly don't want to be the one adding and maintaining that ZMI / formlib layer. Not sure, maybe it's there already. If you really think that "advanced" is too much to ask of the users, and that they're still going to go in there to shoot themselves in the foot, let's make a hidden Plone page where all these forbidden configuration options are. I know that the difference between ZMI and Plone configuration has traditionally been: "If you need to do more than that, go to the ZMI", even if more by accident than by anything else. I don't see why we should cling to this distinction. Regards, Daniel -- http://danielnouri.org ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: Re: The big 3.0 ;)
On 24. mar. 2007, at 00.13, Alec Mitchell wrote: It's a fundamental HTML form issue. No matter what the name of the field (e.g. even if it has a ':boolean'), if the checkbox is not checked then the input is not included in the request (so the value won't be changed). It may be possible to use a hidden field with a False value, so that something is always submitted. IIRC Zope will interpret two fields with the same name as a list of values (even without ':list'). So a hidden field that is False and a checkbox that is checked will give [False, True] which will evaluate to True in a boolean context, but an unchecked checkbox and a hidden False value will just give the False value from the hidden field. If that doesn't work, then I think js is the only way to do this without introspecting the schema to see what boolean fields may have been missing from the form. Yes. of course the :default must be supplied or the checkbox will not be noticed by html. I somehow took this for granted and didn't mention it (sorry. my oversight), but i see now in boolean.pt widget template in AT that it is not included. Zope has its own built-in form typecast for this: Works for all cases i can find. I don't have the 10 minutes i need to actually check it into AT and test that it works TTW right now, but i'll try to get it done tonight unless someone beats me to it. -- __ Geir Bækholt ·Managing Director ·Plone Solutions Consulting · Training · Development · http://plonesolutions.com __ ___ 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 17:49:50 -0700, Martin Aspeli <[EMAIL PROTECTED]> wrote: Martin Aspeli wrote: - Only show the Display/Add/WF pulldowns on the View screen - Possibly remove the border on initial creation forms (ie. keep the actual green border, but remove everything clickable on it, since it causes errors) +1 We already do this with formlib-based add forms from plone.app.form. Done both of these: no border/tabs on the "add form" with portal factory or formlib, and no drop-downs except on the View tab. The former is done with a check in base_edit; the latter is done with a content provider registration: the menu is registered for view = IViewView, whilst there is a fallback one for IBrowserView that is just empty. Great! It has one bug, though: I just created a new site after doing svn up, and on the front page (which is a default view in the portal), you don't get any menus, so it's hard to add anything. In fact, since that's the only page (and the menus are missing from folder_contents), you can't really add anything anymore, which is unfortunate. :) -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
