Re: [Framework-Team] Re: My PLIPs for 3.1
On Dec 12, 2007, at 10:41 PM, Tom Lazar wrote: On 12.12.2007, at 18:45, Raphael Ritz wrote: In terms of ZCML overrides I think we shouldn't do that as there can always only be one override for a specific component at most (please correct me if I'm wrong). well, depending on the implementation of the override, one might be enough. i think what raphael was aiming at was that we shouldn't use 'overrides.zcml' ootb, since it should be left as a possibility to site admins. if we already make use of it internally there's no way for them to change those registrations anymore. but as raphael also said, there should also be other ways to achieve this anyway... 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.4 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] Re: My PLIPs for 3.1
On Dec 12, 2007, at 4:18 PM, Encolpe Degoute wrote: Wichert Akkerman a écrit : Previously Encolpe Degoute wrote: #196: GroupUserFolder removing There were and there are a lot of critical UI bugs around GroupUserFolder by PlonePAS. Because of these, several Plone release had to be delayed. We fix a lot of them in customer branch. I think this is a too large undertaking for 3.1 and I suspect that there is too much code that uses GRUF-APIs that (Plone)PAS does support, which means that that code will break. That is not allowed in a 3.x release. I can do the UI part without modifying portal_groups and portal_groupdata. cleaning up and removing broken links is a good thing to do, so i'm +1 here. otherwise i'd agree with wichert that ripping out and replacing existing tools is too invasive for a 3.x release and should be left for 4.0. I love the idea though :) Me too: It's one less product to maintain. same here, but imho this is the wrong release to go through with this, esp since the old tools aren't in the way of anything as far as i understand it. 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.4 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
[Framework-Team] Re: My PLIPs for 3.1
Danny Bloemendaal a écrit : > > On 12 dec 2007, at 00:03, Encolpe Degoute wrote: > >> I'd like to see the following for 3.1: >> >> >> #214: Merge of CMFPlacefulWorkflow into CMFPlone/WorkflowTool >> >> CMFPlacefulWorkflow is now mature enough to be merge into the workflow >> tool: >> >>* since two major version there's no critical bug on it >>* GenericSetup support is implemented in the trunk >>* let him outside the workflow tool would leave 2 more monkey >> patches in Plone bundle >>* all page templates can be merged into a plone_workflow skin with >> the #210 >> >> > > Ok, how shall I say this? ;-) > First of all, I truely like the idea of placeful workflows. The idea is > good and I had a need for that in several occasions in the past. > However, back in the days when it was introduced in plone I experimented > with it and to be honest, the UI was a horrible mess. I understood the > concept but the UI made me scream. And from what I've heard and seen > afterwards, it hasn't become any better. That's why we (me,limi and > others) decided to not have it installed by default to begin with. I was aware of this discussion and I was agree with the conclusion. Now my points are that: - Remove a monkey patch on the Workflow acquisition on each object that is used even if CMFPlacefulWorkflow is not installed in Plone - Remove a monkey patch on the worklist results that is used even if CMFPlacefulWorkflow is not installed in Plone - Remove a satellite product to concentrate ourselves on the future workflow engine of Plone 4.0 > So, before I would say +1 I think that this beast needs a true overhaul > for the UI. Workflow as it is is already hard to understand for many > (end)users (mostly because it is not really a 'flow' (at least for > users) but more a state-engine, but that's another discussion, and > because it is being misused as a permissions managing system) and > introducing placeful wfs makes it even harder. So, unless we fix this, I > give this a -2. Many developers don't understand them too. I don't think it would be better if we choose alphaflow, openflow, zope.app.wfmc or if we adapt CPSWorkflow. > And it is far from trivial to do this right. Configlets need to be aware > and redesigned. Containers need to have proper UI where you can assign > (overrule) workflow(s!! see the other plip) in that place. The CMFPlacefulWorkflow is a first step to a more generic system. It's clearly not the solution. If you want to act in anything concerning worklows please join: http://www.openplans.org/projects/plone-workflows/project-home For next question you have to note that CMFPlacefulWorkflow is following the CMFCore/WorkflowTool usages (and not specification). > And it doesn't end here. What about reassinging wfs? Reassign workflow have to put the document in the initial state of the new workflow, even if the current state exists in both. > What happens with objects that have states that only exist in that > workflow in that context? => initial state, always > Are they reset to other states? Yes, see CFMCore. The history is kept by workflow identifiant, but... is you go back on a workflow already used for this object it will use the last known state in this workflow. > Do you have to reassign new states as you can right now in the > wf-configlet that we designed in Norway two years ago? Which workflow configlet ? I never saw anything else that the transition dropdown menu. > What happens if you move an object to another folder where there's > another workflow active. What happens with the permissions? Like Plone framework tem decided for Plone 2.5: copy or cut an object will put it in the initial state of the workflow (local workflow iif there's one). Permissions are changed and object security is reindexed. > How does it behave with multiple-workflows (see the other plip discussion)? Like CMF does and there's more tests in CMFPlacefulWorkflow than in CMFCore on this. > How does it play with the current wf-confliget? > The Plone UI on this point is in the TODO list if you want to contribute. > As you can see, a lot of issues need to be addressed properly. And it is really a challenge to do this > right. Especially because we introduce multiple-object workflows as well. All these issue are well known and are not specific to CMFPlacefulWorklfow but to CMF and to Plone. I'm not agree with almost all these choices but I respect them and they are implemented without any ambiguity in CMFPlacefulWorkflow. At least, I'm agree that the UI need to be polished. Regards, -- Encolpe Degoute INGENIWEB (TM) - S.A.S 5 Euros - RC B 438 725 632 17 rue Louise Michel - 92300 Levallois Perret - France web : www.ingeniweb.com - « les Services Web Ingénieux » Tel : 01.78.15.24.08 / Fax : 01 47 57 39 14 ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: My PLIPs for 3.1
On 12.12.2007, at 18:45, Raphael Ritz wrote: Alec Mitchell wrote: [..] I will be writing a PLIP shortly which will hopefully make any merging of CMFPlacefulWorkflow into the workflow tool unnecessary. The idea is adapter based workflow assignment. By default all IDynamicType objects would be assigned a workflow chain using an adapter that does the normal lookup in portal_workflow, but alternate means could be provided with simple adapters. CMFPlacefulWorkflow/CMFPlone would probably just override the default adapter with one that relies on acquisition, but there may be an even more elegant way. Sneaking in here because of the phrasing "...Plone would just override ..." In terms of ZCML overrides I think we shouldn't do that as there can always only be one override for a specific component at most (please correct me if I'm wrong). I thought the way to be more specific if needed is e.g., by adding qualifiers or introducing more specific interfaces. well, depending on the implementation of the override, one might be enough. the way i understand alec, the CMFPlacefulWorkflow would override the default with a context aware (i.e. placeful) version. but i like the sound of the idea a lot. But I'm confident Alec will get it right ;-) if not he... ;-) Raphael Alec ___ 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 ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: My PLIPs for 3.1
Alec Mitchell wrote: [..] I will be writing a PLIP shortly which will hopefully make any merging of CMFPlacefulWorkflow into the workflow tool unnecessary. The idea is adapter based workflow assignment. By default all IDynamicType objects would be assigned a workflow chain using an adapter that does the normal lookup in portal_workflow, but alternate means could be provided with simple adapters. CMFPlacefulWorkflow/CMFPlone would probably just override the default adapter with one that relies on acquisition, but there may be an even more elegant way. Sneaking in here because of the phrasing "...Plone would just override ..." In terms of ZCML overrides I think we shouldn't do that as there can always only be one override for a specific component at most (please correct me if I'm wrong). I thought the way to be more specific if needed is e.g., by adding qualifiers or introducing more specific interfaces. But I'm confident Alec will get it right ;-) Raphael Alec ___ 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] Re: My PLIPs for 3.1
On Dec 12, 2007 7:18 AM, Encolpe Degoute <[EMAIL PROTECTED]> wrote: > Wichert Akkerman a écrit : > > My personal non-framework team opinion: > > > > Previously Encolpe Degoute wrote: > >> I'd like to see the following for 3.1: > >> > >> #196: GroupUserFolder removing > >> > >> There were and there are a lot of critical UI bugs around > >> GroupUserFolder by PlonePAS. Because of these, several Plone release had > >> to be delayed. We fix a lot of them in customer branch. > > > > I think this is a too large undertaking for 3.1 and I suspect that there > > is too much code that uses GRUF-APIs that (Plone)PAS does support, which > > means that that code will break. That is not allowed in a 3.x release. > > I can do the UI part without modifying portal_groups and portal_groupdata. > > > I love the idea though :) > > Me too: It's one less product to maintain. > > > >> #214: Merge of CMFPlacefulWorkflow into CMFPlone/WorkflowTool > >> > >> CMFPlacefulWorkflow is now mature enough to be merge into the workflow > >> tool: > >> > >> * since two major version there's no critical bug on it > >> * GenericSetup support is implemented in the trunk > >> * let him outside the workflow tool would leave 2 more monkey > >> patches in Plone bundle > >> * all page templates can be merged into a plone_workflow skin with > >> the #210 > > > > How does the CMF workflow tool factor into this? I would be nice if we > > can remove the CMFPlone WorkflowTool and use the CMF one, but I have no > > idea how the CMF community feels about CMFPlacefulWorkflow. > > I never had any report or any comment from CMF users or developpers. I will be writing a PLIP shortly which will hopefully make any merging of CMFPlacefulWorkflow into the workflow tool unnecessary. The idea is adapter based workflow assignment. By default all IDynamicType objects would be assigned a workflow chain using an adapter that does the normal lookup in portal_workflow, but alternate means could be provided with simple adapters. CMFPlacefulWorkflow/CMFPlone would probably just override the default adapter with one that relies on acquisition, but there may be an even more elegant way. Alec ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: My PLIPs for 3.1
Wichert Akkerman a écrit : > My personal non-framework team opinion: > > Previously Encolpe Degoute wrote: >> I'd like to see the following for 3.1: >> >> #196: GroupUserFolder removing >> >> There were and there are a lot of critical UI bugs around >> GroupUserFolder by PlonePAS. Because of these, several Plone release had >> to be delayed. We fix a lot of them in customer branch. > > I think this is a too large undertaking for 3.1 and I suspect that there > is too much code that uses GRUF-APIs that (Plone)PAS does support, which > means that that code will break. That is not allowed in a 3.x release. I can do the UI part without modifying portal_groups and portal_groupdata. > I love the idea though :) Me too: It's one less product to maintain. >> #214: Merge of CMFPlacefulWorkflow into CMFPlone/WorkflowTool >> >> CMFPlacefulWorkflow is now mature enough to be merge into the workflow tool: >> >> * since two major version there's no critical bug on it >> * GenericSetup support is implemented in the trunk >> * let him outside the workflow tool would leave 2 more monkey >> patches in Plone bundle >> * all page templates can be merged into a plone_workflow skin with >> the #210 > > How does the CMF workflow tool factor into this? I would be nice if we > can remove the CMFPlone WorkflowTool and use the CMF one, but I have no > idea how the CMF community feels about CMFPlacefulWorkflow. I never had any report or any comment from CMF users or developpers. Regards, -- Encolpe Degoute INGENIWEB (TM) - S.A.S 5 Euros - RC B 438 725 632 17 rue Louise Michel - 92300 Levallois Perret - France web : www.ingeniweb.com - « les Services Web Ingénieux » Tel : 01.78.15.24.08 / Fax : 01 47 57 39 14 ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
