[Framework-Team] Re: The big 3.0 ;)
On Tue, 03 Apr 2007 03:45:56 -0700, Wichert Akkerman [EMAIL PROTECTED] wrote: - Members folder gets created even though it's turned off? Bug, should be fixed. Still present. - Put back autofocus behaviour now that we have ondomload (make sure tabindex is correct) Already done I think Halfway, the iterator still emits tabindex=0, which is wrong, so the JS is commented out for now. But shouldn't be hard to fix, and I asked Florian if he could have a look today. - Move sendto/print/whatever to bottom of page, use text representation Needs to happen soon or becomes 3.5 material. Done. Better styling is coming. - Fix up Table-of-Contents styling - Fix up presentation mode styling Needs to happen soon or becomes 3.5 material. Part of my work scheduled for tomorrow. It depends on getting some help with sanitizing the JS since it emits invalid HTML right now. - Search: only in this section checkbox Needs to happen soon or becomes 3.5 material. Added. - Fix in 3.0.x releases - Incremental KSS UI improvements, examples: - Login should be in-place (digg.com for an example) - Adding comments should give you a textfield inline - etc... 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... -- 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 ;)
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). -- Jeroen ___ 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
Re: [Framework-Team] Re: The big 3.0 ;)
Previously Alexander Limi wrote: On Tue, 03 Apr 2007 03:45:56 -0700, Wichert Akkerman 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... Correct. That is the only way to do release and be able to promise a stable platform for people building on top of Plone. Stability is more important than introducing new features. 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: 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: The big 3.0 ;)
Florian Schulze wrote: What does Zope commit access and z3c.widget have to do with ÜberSelectionWidget? There is a small bit of code in there which I want to use. http://svn.zope.org/z3c.widget/trunk/src/z3c/widget/namespace/README.txt?rev=71292view=markup ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: The big 3.0 ;)
Wichert Akkerman wrote: some comments on this list, based on current status. Previously Alexander Limi wrote: Fix before RCs: - KSS: - Reduce file size, it's currently way too heavy I'll make a seperate post on that. - 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. It really needs to be made to look a bit less amateurish (no offense!) though, even if it's just HTML. :) - Wicked - Needs to use createObject?type_name=Document — the way it is set up now, anything spidering the site with credentials will create objects, and any object clicked will create objects (this change will make it invoke portal_factory) Hasn't happened. Am I right in thinking this should be considered a seriousish bug? - Don't install the following by default: - Content Rules Needs a toggle somewhere. Consider this issue resolved. There is a switch. Content rules is not really installable as such. - 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. - Combine delete confirmation page with integrity checking (having to say yes/no on two separate pages sucks :) Needs to happen soon or becomes 3.5 material. I'd say this is a usability bug that could be 3.0 or 3.0.x even, if someone can fix it. - 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) Done at the sprint. Actually before the sprint. :) - Other - Users seem to be listed twice in the control panel Fixed at the sprint, not merged yet. - You are adjusting the sharing privileges for a default view, to adjust them for the entire container, go here. Fixed at the sprint I think, may not be merged yet. - WF history and versioning history should be shown in the same table Probably too late for 3.0. - We need a way to ping us (image with some info about OS, version etc) when you install Plone — checkbox on install screen Too late for 3.0 And also of debatable merit if you ask me. - Fix up Table-of-Contents styling - Fix up presentation mode styling Needs to happen soon or becomes 3.5 material. These are UI/CSS bugs and should be considered as part of the usual bug fixing process. - Search: only in this section checkbox Needs to happen soon or becomes 3.5 material. Trivial, though, if someone has cycles. 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 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 ;)
Alec Mitchell wrote: On 4/3/07, Martin Aspeli [EMAIL PROTECTED] wrote: Wichert Akkerman wrote: - Wicked - Needs to use createObject?type_name=Document — the way it is set up now, anything spidering the site with credentials will create objects, and any object clicked will create objects (this change will make it invoke portal_factory) Hasn't happened. Am I right in thinking this should be considered a seriousish bug? I don't see why this should be considered any better/worse than the content add menu which uses the exact same links and will be shown on all such pages as well. From a spiders point of view, it's not different, AFAIK. Not that this isn't an important issue, but we've lived with it for a long time. True. So what's it using now? In any case, if it's not using createObject it probably should (if feasible) just to standardise on that API. Note that the add menu can make use of z3 add views now. I don't think there's an immediate need for wicked to do the same, but if it uses createObject, then we could make createObject support addviews as well in the future, again through a common interface. Martin ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: The big 3.0 ;)
Alec Mitchell wrote: On 4/3/07, Martin Aspeli [EMAIL PROTECTED] wrote: Wichert Akkerman wrote: - Wicked - Needs to use createObject?type_name=Document — the way it is set up now, anything spidering the site with credentials will create objects, and any object clicked will create objects (this change will make it invoke portal_factory) Hasn't happened. Am I right in thinking this should be considered a seriousish bug? I don't see why this should be considered any better/worse than the content add menu which uses the exact same links and will be shown on all such pages as well. From a spiders point of view, it's not different, AFAIK. Not that this isn't an important issue, but we've lived with it for a long time. who spiders with credentials? The real issue is clicky users creating content they don't actually edit. This is more of an annoyance than a barn-burner considering it's a wiki convention that most of the time people use the syntax so they can rapidly create and populate a link. this is like 3-4 line fix unless you wanted to create a proper add view (ie less effort than has been expended in writing emails about it). might have time this weekend to do it. an kss inline of the add item page would be by far the best solution overall(still need above as a fallback). -w -- -- d. whit morriss -- - senior engineer, opencore - - http://www.openplans.org - - m: 415-710-8975 - If you don't know where you are, you don't know anything at all Dr. Edgar Spencer, Ph.D., 1995 begin:vcard fn:D. Whitfield Morriss n:Morriss;D. Whitfield org:The Open Planning Project;OpenPlans adr:;;1309 Ashwood Ave;Nashville;TN;37212;USA email;internet:[EMAIL PROTECTED] title:Lead Developer tel;home:615 292-9142 tel;cell:415 710-8975 x-mozilla-html:FALSE version:2.1 end:vcard ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: The big 3.0 ;)
Martin Aspeli wrote: - Search: only in this section checkbox Needs to happen soon or becomes 3.5 material. Trivial, though, if someone has cycles. I was looking at this template anyway, so I've done it. Florian has promised to hook it into livesearch. 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 ;)
Raphael Ritz wrote: snip/ On a related note: let's not forget that one of the strong points of Zope/Plone has always been the possibility to do many things TTW from a browser. In many real life situations, site admins don't have file system access to the server deploying their site which defeats in my view the current tendency to simply move everything to the file system and then saying: Oh, well, just provide your own view class/whatever and override the default in your config.zcml. For those site admins this is simply not an option. (And note that I am not talking about TTW *development*, I'm talking about *site configuration*.) That's what Clouseau is for, now you can edit your filesystem code TTW with standard python semantics ;-) Laurence ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: The big 3.0 ;)
Martin Aspeli schrieb: [..] There is a general developer mis-conception that Plone's not *too bad at* but sometimes we all do it: More options == better. Could we maybe return to the issue that triggered this discussion, namely whether or not to bann the smart folder settings from the Plone control panel. In my view we should not do this because: 1. removing something that's been around for a while now just confuses people. 2. In the long run (aka when at some point moving to Zope 3 entirely) there will be no ZMI anymore as we know it today. 3. Smart folders (aka Topics) are special in various ways and admittedly they are way more complex than the other regular content types. Simply saying that many people don't need their UI-configuration options may fall short here because I assume many sites don't make much use of topics (if at all). On those sites where they are used heavily I claim these options are desperatly needed. On a related note: let's not forget that one of the strong points of Zope/Plone has always been the possibility to do many things TTW from a browser. In many real life situations, site admins don't have file system access to the server deploying their site which defeats in my view the current tendency to simply move everything to the file system and then saying: Oh, well, just provide your own view class/whatever and override the default in your config.zcml. For those site admins this is simply not an option. (And note that I am not talking about TTW *development*, I'm talking about *site configuration*.) Just my 2 cents. Raphael ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: The big 3.0 ;)
Raphael Ritz wrote: Martin Aspeli schrieb: [..] There is a general developer mis-conception that Plone's not *too bad at* but sometimes we all do it: More options == better. Could we maybe return to the issue that triggered this discussion, namely whether or not to bann the smart folder settings from the Plone control panel. ;) In my view we should not do this because: 1. removing something that's been around for a while now just confuses people. 2. In the long run (aka when at some point moving to Zope 3 entirely) there will be no ZMI anymore as we know it today. 3. Smart folders (aka Topics) are special in various ways and admittedly they are way more complex than the other regular content types. Simply saying that many people don't need their UI-configuration options may fall short here because I assume many sites don't make much use of topics (if at all). On those sites where they are used heavily I claim these options are desperatly needed. On a related note: let's not forget that one of the strong points of Zope/Plone has always been the possibility to do many things TTW from a browser. In many real life situations, site admins don't have file system access to the server deploying their site which defeats in my view the current tendency to simply move everything to the file system and then saying: Oh, well, just provide your own view class/whatever and override the default in your config.zcml. For those site admins this is simply not an option. (And note that I am not talking about TTW *development*, I'm talking about *site configuration*.) Maybe the bigger issue is that this control panel is very low level. I don't think it makes much sense to non-programmers, and compared to our other control panels, it's a lot less elegant and feels a lot less usable. Perhaps we can think of some more appropriate metaphors, and a better layout that make these settings more understandable for regular site admins? 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 ;)
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
Re: [Framework-Team] Re: The big 3.0 ;)
Previously Florian Schulze wrote: 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. Having two control panels feels bad to me. A 'advanced management' permission which controls access to the advanced options feels nicer. 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: The big 3.0 ;)
whit wrote: re: zmi. lets talk about being painfully modal. The fact we are having this conversation seems to indicate a different and wider issue to me. Without wanting to get into an abstract and easy-to-talk-past-each-other discussion, I think you're right. :-) A useful metric may be if it's too complex for real users and thus not good to keep in the control panel, it should be configurable in code. Configurable in code should not mean go change config.py, it should mean override this component or register something else for this interface if you need to alter behaviour. How's that for abstract and easy to misunderstand? :) Martin ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: The big 3.0 ;)
Martin Aspeli wrote: whit wrote: re: zmi. lets talk about being painfully modal. The fact we are having this conversation seems to indicate a different and wider issue to me. Without wanting to get into an abstract and easy-to-talk-past-each-other discussion, I think you're right. :-) A useful metric may be if it's too complex for real users and thus not good to keep in the control panel, it should be configurable in code. Configurable in code should not mean go change config.py, it should mean override this component or register something else for this interface if you need to alter behaviour. How's that for abstract and easy to misunderstand? :) sort of? I only half agree if I understand you correctly. we still have some larger knobs that can't be configured via the FS (or are more useful if not): persistent components being the big one I see here without thinking too hard. I also think there is a level of complexity between average site admin control panel tasks and fullon fs configuration. Also, our filesystem configuration story is sort of a mess too with all the different zope2 and zope3 options (ever tried to explain commenting out zcml or adding slugs to someone unfamiliar with zope3? does anyone doing core development now know Zconfig?) this doesn't justify doing more TTW, it just makes configurable in code harder to sell as reasonable step downward from controlpanel. As stated before, I think there is a place for some sort of extension of the plone.app.controlpanel and maybe making some reasonable linkage so if advanced options are available, we have a standard sane way of hooking them up and for the appropriate real users to get to them. My prediction is that addon developers can and will do this(it's the path of least resistance)... so we might as well have a good way to handle it. -w -- -- d. whit morriss -- - senior engineer, opencore - - http://www.openplans.org - - m: 415-710-8975 - If you don't know where you are, you don't know anything at all Dr. Edgar Spencer, Ph.D., 1995 begin:vcard fn:D. Whitfield Morriss n:Morriss;D. Whitfield org:The Open Planning Project;OpenPlans adr:;;1309 Ashwood Ave;Nashville;TN;37212;USA email;internet:[EMAIL PROTECTED] title:Lead Developer tel;home:615 292-9142 tel;cell:415 710-8975 x-mozilla-html:FALSE version:2.1 end:vcard ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: The big 3.0 ;)
Alexander Limi wrote: On Thu, 22 Mar 2007 23:43:13 -0700, Alexander Limi [EMAIL PROTECTED] wrote: - There's something strange going on with enabling comments, it only works on the initial view of the page after saving, possibly related This actually seems to be related to the KSS inline loading of the content area too. When I add a comment, then switch to the edit tab, and then back to the view tab, the comment is gone. It comes back if I force-refresh the page. It's the same problem, I'm guessing, as the one that means when inline switching tabs, the IViewView interface is not applied properly (it should be a marker on the 'view' instance when you're on the actual view tab, and it's used to distinguish when to render certain things). This is also why the content menu drop-downs are sometimes shown when they're not supposed to if you switch from view to edit, or not shown if you switch from edit to view. I've detailed this in a KSS trac issue, can't dig it up right now, gotta run. 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 Thu, 22 Mar 2007 23:43:13 -0700, Alexander Limi [EMAIL PROTECTED] wrote: - There's something strange going on with enabling comments, it only works on the initial view of the page after saving, possibly related This actually seems to be related to the KSS inline loading of the content area too. When I add a comment, then switch to the edit tab, and then back to the view tab, the comment is gone. It comes back if I force-refresh the page. -- 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 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
[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
[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 ;)
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 ;)
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 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: input type=checkbox name=foobar:boolean value=True / input type=hidden name=foobar:boolean:default value= / 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 ;)
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 ;)
Hi! Alexander Limi wrote: - Archetypes - After we removed JS from checkboxes, they no longer stick (really!). Might have to put that back, even though it sucks - There's something strange going on with enabling comments, it only works on the initial view of the page after saving, possibly related Who removed JS from checkboxes when? - 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? - Preferrably move the Collections (Smart Folder) control panel to a ZMI version, since it is very complex and not something site admins are likely to need I'd suggest an advanced section in the control panel. I don't like the idea of moving this back to the ZMI because it's too complex for the typical user. 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? 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: The big 3.0 ;)
Previously Daniel Nouri wrote: Hi! Alexander Limi wrote: - Archetypes - After we removed JS from checkboxes, they no longer stick (really!). Might have to put that back, even though it sucks - There's something strange going on with enabling comments, it only works on the initial view of the page after saving, possibly related Who removed JS from checkboxes when? I did that, it worked correctly for me (and the old javascript did not work with in-place edit iirc). I haven't tested why it doesn't work for alex. - 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. - Preferrably move the Collections (Smart Folder) control panel to a ZMI version, since it is very complex and not something site admins are likely to need I'd suggest an advanced section in the control panel. I don't like the idea of moving this back to the ZMI because it's too complex for the typical user. +1 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: 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 select pulldown? 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 05:03:58 -0700, Wichert Akkerman [EMAIL PROTECTED] wrote: Previously Daniel Nouri wrote: Who removed JS from checkboxes when? I did that, it worked correctly for me (and the old javascript did not work with in-place edit iirc). I haven't tested why it doesn't work for alex. Actually, it doesn't work for anyone, here's how to reproduce: 1. Edit the front page 2. On the Settings tab, uncheck Exclude from navigation, save 3. Edit again, notice how EfN is checked (as it should be) 4. Uncheck it again, click save 5. Edit again, notice how the unchecking didn't stick, and it's impossible to get the item to not be Excluded from Navigation now. 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. Heh. I agree. [Collection Control Panel I'd suggest an advanced section in the control panel. I don't like the idea of moving this back to the ZMI because it's too complex for the typical user. +1 Even Alec (who built it) agrees that the control panel is too much like portal_types, it was just put there for convenience. The general principle behind the Plone control panels is to expose the things *most* people want to tweak (and 3.0 is awesome in that regard), and let the things that very few want to tweak reside in the ZMI settings. It's not about having full settings coverage, then you end up with the ZMI with prettier colors. ;) -- 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 Fri, 23 Mar 2007 06:29:01 -0700, Florian Schulze [EMAIL PROTECTED] wrote: 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. Yes, I didn't know whether that marker interface was there or not. If you can tell me how this is done, I'll make sure it makes it into the product upgrade docs. - Fieldset code: if more than N (N=6?) fieldsets, turn into pulldown You mean a select pulldown? Yes. Like the Types control panel. -- 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 Fri, 23 Mar 2007 05:00:45 -0700, Daniel Nouri [EMAIL PROTECTED] 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. :) -- 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 ;)
whit wrote: What's everyone else's excuse? :-) explosive diarrhea. Tiran once coded in the toilet at a sprint, so that won't do, Whit. Martin ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: The big 3.0 ;)
Martin Aspeli wrote: whit wrote: What's everyone else's excuse? :-) explosive diarrhea. Tiran once coded in the toilet at a sprint, so that won't do, Whit. I didn't want to vomit on my keyboard. -w -- -- d. whit morriss -- - senior engineer, opencore - - http://www.openplans.org - - m: 415-710-8975 - If you don't know where you are, you don't know anything at all Dr. Edgar Spencer, Ph.D., 1995 begin:vcard fn:D. Whitfield Morriss n:Morriss;D. Whitfield org:The Open Planning Project;OpenPlans adr:;;1309 Ashwood Ave;Nashville;TN;37212;USA email;internet:[EMAIL PROTECTED] title:Lead Developer tel;home:615 292-9142 tel;cell:415 710-8975 x-mozilla-html:FALSE version:2.1 end:vcard ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
