Re: [Framework-Team] The big 3.0 ;)
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. - 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 Fixed. - NuPlone theme - Be complete and functional by RCs, tested in IE6 too - Be the default in RCs if the above is the case ;) See my other post. - Kupu - Make sure the control panel removes stuff that is no longer relevant with the HTML Filtering control panel - Make sure you can't insert images that are bigger than Preview size by default - Include additional default styles (highlight, table variations) Nobody worked on this to my knowledge. - 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. - Support both (()) and [[]] syntax by default, so we can remove this preference from the control panel (exclusively using either is still supported behind the scenes, of course — just not in the standard control panel) - Wiki control panel can be removed, only needs wiki syntax on/off switch in the control panel Hasn't happened and can just as easily be postponed until 3.5, if ever. - Fieldsets - Do we still support fieldsets that require something on fieldset #1 to be filled out before you can access fieldset #4? - Next button shows up in the Save/Cancel area when using the inline fieldsets? - Fieldset code: if more than N (N=6?) fieldsets, turn into pulldown These need to be fixed still. - Sensible defaults: - Make sure the WFs are sensible and default WF decided All the unittests still require our old default workflow and nobodu has the resources to fix that, so we're going to have to stick with our old default. - Members folder gets created even though it's turned off? Bug, should be fixed. - Only HTML available as format by default, everything else assumes knowledge of markup - But make sure it supports loading existing documents that are in other formats already - Enable wiki support by default on most types? it's unlikely to trigger accidentally anyway All behavioural changes very late in the release process, probably 3.5 stuff now. - Both the Navigation and Search control panel does not show the Friendly types list, but uses the full list instead, should be fixed (user does not know what a ChangeSet or Relative Path Criterion type is ;) Debatable. - Remove personal prefs from the global prefs section - Don't install the following by default: - Content Rules Needs a toggle somewhere. - Can the old-style Add-on products support TITLE.txt to match the new style products' ability to have a friendly name? Behavioural change this very late in the release process, probably 3.5 stuff now. - 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 Behavioural change this very late in the release process, probably 3.5 stuff now. - Put back autofocus behaviour now that we have ondomload (make sure tabindex is correct) Already done I think - Move sendto/print/whatever to bottom of page, use text representation Needs to happen soon or becomes 3.5 material. - 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. - 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. - Other - Users seem to be listed twice in the control panel Fixed at the sprint, not merged yet. - You are adjusting the
Re: [Framework-Team] The big 3.0 ;)
On 4/3/07, Wichert Akkerman [EMAIL PROTECTED] wrote: some comments on this list, based on current status. ... - 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'm pretty sure you can't do this while maintaining post protection for the delete action without adding some tremendous hack to delay the deletion until a second post request, or by making the original delete link a POST form submit. Neither of these is really 3.0 material IMO. Alec ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] The big 3.0 ;)
or maybe allowing an option that turns on advanced panels(or at least a way for addon developer create some sort of navigation to advanced options they may add). 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. the argument that we are now using the zmi by design really rings hollow for me. Though I strongly support generalizes ui that works with or without plone, I'm not sure designing in any more context switches into plone is at all a good idea. Let's keep people in the application or on filesystem, not rummaging though our hot nineties legacy layer. Context switching has almost always been an unfortunate bump on our learning curve for Plone. Just having to explain navigating the zmi increase our support burden. People should design good configuration uis, not just stick badly drawn ones in the zmi. There are options that make more sense in a plone setting even if not for the more general day to day site admin tweaks. addon authors will add their own control panel regardless of what we say the right way is, so I would vote for giving them a more appropriate place to do this (with wicked, I see plenty of fertile options that I'm not at all interested in building zmi pages for but are definitely not basic configuration options). we are also moving into a time where control panel style UIs make sense at any container level, not just the portal. with these things in mind, we may need to rethink the application of the pattern we use in plone.app.controlpanels so it can be easily reused for things like advanced options or container level configuration. This seems like the right direction, rather than claiming the inevitable use of better technology as wrong by decree and advocating a return to the bonny days of 1999. long live frames! -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 ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] The big 3.0 ;)
Previously whit wrote: we are also moving into a time where control panel style UIs make sense at any container level, not just the portal. We have a growing number of 'tweaks' that are starting to clutter our UI which would make excellent candidates for moving to a container-local control panel: placeful workflow policies, content rules and type restrictions. Workgroup systems like teamspace would also fit that scheme very well. 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 big 3.0 ;)
Hi Alex, Time is tight these days, and I just recovered from a fever/cold, but I'd rather overcommunicate than be too silent. No panicking about the list. ;) The list looks good, though I have a couple of points: Fix before beta: - KSS vs. CMF errors - Kupu doesn't work either at the moment, probably related to the KSS/CMF issue Fix before RCs: - KSS: - Reduce file size, it's currently way too heavy - Get a basic UI on ÜberSelectionWidget - 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 - NuPlone theme - Be complete and functional by RCs, tested in IE6 too - Be the default in RCs if the above is the case ;) - Kupu - Make sure the control panel removes stuff that is no longer relevant with the HTML Filtering control panel - Make sure you can't insert images that are bigger than Preview size by default - Include additional default styles (highlight, table variations) - 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) - Support both (()) and [[]] syntax by default, so we can remove this preference from the control panel (exclusively using either is still supported behind the scenes, of course — just not in the standard control panel) - Wiki control panel can be removed, only needs wiki syntax on/off switch in the control panel - Fieldsets - Do we still support fieldsets that require something on fieldset #1 to be filled out before you can access fieldset #4? - Next button shows up in the Save/Cancel area when using the inline fieldsets? - Fieldset code: if more than N (N=6?) fieldsets, turn into pulldown - Sensible defaults: - Make sure the WFs are sensible and default WF decided - Members folder gets created even though it's turned off? - Only HTML available as format by default, everything else assumes knowledge of markup - But make sure it supports loading existing documents that are in other formats already Also, I'd say that plain text makes a bit of sense as being enabled by default, for those without kupu-capable browsers. - Enable wiki support by default on most types? it's unlikely to trigger accidentally anyway - Both the Navigation and Search control panel does not show the Friendly types list, but uses the full list instead, should be fixed (user does not know what a ChangeSet or Relative Path Criterion type is ;) We need to be careful with this so that we don't make it impossible to support certain configurations, e.g. to be able to list a particular content type in the navtree, but not search on it. Also, isn't the list of types managed in the Search control panel actually the friendly types list itself? In that case, you have a chicken-and-egg problem. - Remove personal prefs from the global prefs section - Don't install the following by default: - Content Rules We talked about this before. This isn't easily possible right now, because it's just a registration of a local utility + a control panel, which happens during site setup. I'm not sure I care to productize it and make it installable/uninstallable when it's an admin-only function anyway. Regular users should never see it. If you want to disable the management of content rules, you can turn off the appropriate permission; it may be useful to have some kind of global turn off content rule execution switch, though. I don't know where you'd manage this from, but if it were somewhere other than the Content rules controlpanel, then it'd be possible to turn off the CR control panel with that switch as well. - Can the old-style Add-on products support TITLE.txt to match the new style products' ability to have a friendly name? - 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 assume you mean *not* likely to need. - Put back autofocus behaviour now that we have ondomload (make sure tabindex is correct) - Move sendto/print/whatever to bottom of page, use text representation
Re: [Framework-Team] The big 3.0 ;)
- Both the Navigation and Search control panel does not show the Friendly types list, but uses the full list instead, should be fixed (user does not know what a ChangeSet or Relative Path Criterion type is ;) We need to be careful with this so that we don't make it impossible to support certain configurations, e.g. to be able to list a particular content type in the navtree, but not search on it. Also, isn't the list of types managed in the Search control panel actually the friendly types list itself? In that case, you have a chicken-and-egg problem. Yes, we need to un-nest this somehow, I just left it here so we would remember to look into it. IMO, there are certain types that should be blacklisted from all of these lists (ChangeSet, Criteria, etc) since they are not actually addable types, but just side effects of the implementation strategy. If friendly types is related to the search blacklisting at all, I have misunderstood how this works. I didn't think it did. :) I'm not sure I'd want to make this part of 3.0; such refactoring at this stage could be risky and boring. :) Let's take a pragmatic look at it and work out what's achievable without introducing new properties and new lists of things. - Don't install the following by default: - Content Rules We talked about this before. This isn't easily possible right now, because it's just a registration of a local utility + a control panel, which happens during site setup. I'm not sure I care to productize it and make it installable/uninstallable when it's an admin-only function anyway. Regular users should never see it. If you want to disable the management of content rules, you can turn off the appropriate permission; it may be useful to have some kind of global turn off content rule execution switch, though. I don't know where you'd manage this from, but if it were somewhere other than the Content rules controlpanel, then it'd be possible to turn off the CR control panel with that switch as well. Right, also an old note that made it in. A global enable content rules checkbox in the Content Rules panel is more than good enough. Cool. I've got a few contentrules fixups in the pipeline, will look at them then. - 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 assume you mean *not* likely to need. I mean not something they are likely to need. It's the same. At least in my brain. ;) Note to self: Don't reply to emails before breakfast. - 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 I think you're the only one that understands this code at the moment, so if you could look into this, it would be appreciated. It's quite easy, I think. If I forget, remind me again. :) In the formlib add form world, we actually turn off the border in its entirety (i.e. disable_border=True in the request) when adding objects. I think we need to do the same for AT based objects. In the formlib world, it makes no sense at all to have tabs, because before the object is added, there is no object to have tabs for! The tabs that appear would be those for the parent folder, which makes no sense. At least when using portal factory, we are trying to fake add forms, so I think the semantics should be the same. To the user, there is no object until the add form is submitted. ;) - You are adjusting the sharing privileges for a default view, to adjust them for the entire container, go here. ? Just the wording for the message that needs to show up if you are trying to set Sharing privileges for the default view of a folder. It doesn't exist at the moment (the entire Sharing page seems broken for some reason at the moment, I get a KSS spinner, but nothing happens). Gah. :) Martin ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] The big 3.0 ;)
Hi team, I'm in the process of entering stuff in the issue tracker this weekend (that thing needs a thorough scrubbing, let me tell you ;), and this is how my current list looks like. I'd appreciate feedback, especially on what needs to be resolved before beta/RCs. I just wanted you to see the list I currently have, I'll make sure all of them are handled in a proper manner (ie. get issues in the tracker). Hopefully people at the Sorrento sprint can take a shot at fixing these as well. Time is tight these days, and I just recovered from a fever/cold, but I'd rather overcommunicate than be too silent. No panicking about the list. ;) Fix before beta: - KSS vs. CMF errors - Kupu doesn't work either at the moment, probably related to the KSS/CMF issue Fix before RCs: - KSS: - Reduce file size, it's currently way too heavy - Get a basic UI on ÜberSelectionWidget - 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 - NuPlone theme - Be complete and functional by RCs, tested in IE6 too - Be the default in RCs if the above is the case ;) - Kupu - Make sure the control panel removes stuff that is no longer relevant with the HTML Filtering control panel - Make sure you can't insert images that are bigger than Preview size by default - Include additional default styles (highlight, table variations) - 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) - Support both (()) and [[]] syntax by default, so we can remove this preference from the control panel (exclusively using either is still supported behind the scenes, of course — just not in the standard control panel) - Wiki control panel can be removed, only needs wiki syntax on/off switch in the control panel - Fieldsets - Do we still support fieldsets that require something on fieldset #1 to be filled out before you can access fieldset #4? - Next button shows up in the Save/Cancel area when using the inline fieldsets? - Fieldset code: if more than N (N=6?) fieldsets, turn into pulldown - Sensible defaults: - Make sure the WFs are sensible and default WF decided - Members folder gets created even though it's turned off? - Only HTML available as format by default, everything else assumes knowledge of markup - But make sure it supports loading existing documents that are in other formats already - Enable wiki support by default on most types? it's unlikely to trigger accidentally anyway - Both the Navigation and Search control panel does not show the Friendly types list, but uses the full list instead, should be fixed (user does not know what a ChangeSet or Relative Path Criterion type is ;) - Remove personal prefs from the global prefs section - Don't install the following by default: - Content Rules - Can the old-style Add-on products support TITLE.txt to match the new style products' ability to have a friendly name? - 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 - Put back autofocus behaviour now that we have ondomload (make sure tabindex is correct) - Move sendto/print/whatever to bottom of page, use text representation - Combine delete confirmation page with integrity checking (having to say yes/no on two separate pages sucks :) - 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) - Other - Get rid of all the deprecation warnings in the core - Why is Members folder showing up even if that is disabled by default now? - Is there any way to get formlib to support our checkbox-before-label UI policy? (see control panels for examples) - Users seem to be listed twice in the control panel - You are adjusting the sharing privileges for a default view, to adjust them for the entire
