Log in
Forgot your password?
History for NewPTKArchitectureDiscussion
??changed:- PJE -- May I suggest adding "For" on the names of methods which take content, container, etc. as their first parameter? I have found this convention to be very helpful when one is dealing with delegation-oriented methods like these, for distinguishing methods that are delegation services from ones which are not. So for example, getState(content) would become getStateFor(content). I would also suggest that if "allow" is a boolean, the convention be "isXAllowedFor" e.g. "isDiscussionAllowedFor(content)". ShaneH -- That sounds reasonable; I have made the change. I have also added descriptions to the methods. I have not yet added descriptions of the other object types or security information. WebMaven: (referring to portal_workflow) Should this be generalized to be a state_machine object that is called portal_workflow? Can these objects nest to build more complex workflows that can be overided at various points in the site? ShaneH: That is the intent; isn't it generalized enough now? WebMaven: I'm sorry, I wasn't clear. I'm saying that the name of the product and the name that the instance shouldn't be the same. So I'm suggesting that the product be named state_machine (which is a slightly more generalized name for the tool), and that the state_machine instance expected by the portal DTML have an id of portal_workflow. The state_machine used by the portal should be easily modifyable. I've encountered several products that expected a ZCatalog named Catalog to be available, and had that specific id hardwired into their code. I'd rather not repeat that experience. ShaneH: Ah, I see--I think. The class name is "WorkflowTool", and it has a hardwired id of "portal_workflow". To replace it with a different implementation, the manager would just delete it and add a different "portal_workflow" object that supports the interface described above. WebMaven: What if you don't want to reference a different implementation, but a different instance? For example, if you already have a "WorkflowTool" named "portal_workflow" in your ZODB and you want to instance a second portal that references a "WorkflowTool" called "internal_workflow" (you want both to be acquired from the root folder so no one but you has management privileges on them), how easy is it going to be to change that in the DTML? Can the id of the appropriate "WorkflowTool" just be a property in the portal folder rather than be hardwired into the code? ShaneH: Can you provide a use case? (Keep in mind that there is no longer going to be a "Portal" object anywhere. The only way DTML can find these tools is through a fixed ID. And a method name like "getPortal()" is roughly equivalent to a fixed ID. If you want to create two different portals in different folders, that will still work since the two portal_workflow objects won't know about each other at all. And that's another reason "singleton" is not the right word. :-( ) WebMaven: Here is a slightly contrived use case: Let's say that I want to create two portals, and that I want to give management priveleges to two different users in those folders. I want the portals to have separate customized workflows, and I don't wan't the users to have management priveleges on the workflow objects. Lets further say that I want the two portals to have a common membership. The obvious way is to move the common elements to the root folder (where only I have management priveleges). This will work fine for the common membership, but not for the "WorkflowTool" objects as they have a name conflict, as they're both named "portal_workflow". I would like to be able to give one of them a different id, and be able to easily switch from a single property in each portal's folder which "WorkflowTool" gets used, rather than having to search for every instance of "portal_workflow" throughout the DTML code. By the way, I just realized that I'm assuming that the "portal_workflow" instance of the "WorkflowTool" is itself customizable (in terms of allowed states and transitions) through the Zope management interface, is this in fact the case? ShaneH: First, there would not be a naming conflict, since the two portal_workflow objects are in different folders. Second, since the WorkflowTool interface is well defined and adhered to, you could actually create a special delegate which chooses WorkflowTools from subfolders (or even have different ID's) based on some special criterion. Future versions of PTK will make the portal_workflow objects customizable. WebMaven: But I stated that I wanted to move the "WorkflowTool" instances (both called "portal_workflow") to the root folder. Hence the name conflict. Your point about creating a delegate is taken, however, I'm not sure how this helps with "portal_workflow" being hardcoded throughout the DTML. The DTML would still have to be edited to point to the delegate instead, unless the delegate is also named "portal_workflow". ShaneH: No DTML editing is necessary, WebMaven. The delegate would be named portal_workflow, and the workflow tools it delegates to would be named something else or would be located somewhere else. All of the capabilities you are asking for are there IMHO. SteveA: Perhaps the portal_catalog should take into account expiry dates for content, as well as start dates.