On May 28, 2010, at 11:19 AM, Mark H. Wood wrote: > On Fri, May 28, 2010 at 09:56:51AM -0700, Mark Diggory wrote: >> Not only this, but with the work I am planing for discovery, we need events >> for all the workflow stages and state changes (withdrawn, submitted, etc) >> ... > > Hmmm. I was also thinking of breaking up the all-static, no-fields > InstallItem "class" and distributing its behaviors among the objects > to which they are proper. INSTALL would then be emitted by > InProgressSubmission, which is associated with workflow.
I wonder if we need to think "Data Model" and "Service" here to try to clarify who/where the events should eventually occur. 1.) Is a Submission workspace or reviewer Workflow step a "state" of the Item or a "Container" the Item is in? 2.) In 2.0 "Items" are Anemic almost just "Identifiers" with state stored in various "Session level" Storage Services, in 1.0 Items are mixed up Session and Entity Beans. In 2.0 the Services emit the Events, not the Item (Entity). So if this is the case, the direction we will want the workflow to go in over time is that "InProgressSubmission" is a just a state associated with the Item (Entity) a state which signifies richer detail than we currently can store on the Item As Such we will eventually need to tear the WorkflowItem and WorkspaceItem classes in two... A "WorkflowService" that would have the CRUD support and emit events and "WorkflowItems" that would contain the State of the Item. Does this mean that we need Classes like InstallItem to really be "EventListeners" that listen to the WorkflowService for WorkflowEvents and complete tasks when the WorkflowItems state is changed to be "Archived", certain actions such as generating a Handle or assigning the permissions found int he collection seem to be things that happen in other 2.0 services (MappingService for handle ids and UserService for Item resource policies/permissions). We already have Search and Browse indexing externalize as Event Consumers. It seems that significant parts of InstallItem would actually go away. I'm also of the opinion that the things happening in InstallItem suggest that it is really just "state change" and that we should not be using "WorkflowItem" and "WorkspaceItem" as containers, but that they are again just state, the user should have a "Workspace" and the Repository should have 1 or more "Workflows", but these just represent views on the Items stored in the Assetstore. This really starts to remind me of the approach employed in Hydra / Fedora. Where the Fedora Object exists in one place and how it is treated by the system is always just state change on that Fedora Object, the Hydra "Services" just facilitate a means to modify that state where appropriate. >> Actually, What I really want to see that would align with the EventService >> more clearly is that there is no "fixed" list of Event types to choose from. >> But that Events either be typed by a java interface or even more simply by >> a simple string or URI type identifier. I think the later would allow for >> endusers to define new event types in their XMLUI or other addons without >> having to create java classes to represent them. But those are just ideas, >> the important need is that the EventManager or Event object "not" exert >> draconian rule over what Events are allowed in the system and just passes >> any event onto its listener... Much the way the EventService is designed to >> operate. > > Well, it seems that the only thing against your constructing an > org.dspace.event.Event with type 32768 (for example) today is that > getEventTypeAsString will return "(unknown)" for that type code. The problem is that Consumers aren't really written with this in mind and may be brittle / break for undefined types in those filtering rules that we have placed into the dspace.cfg. (Yet Another candidate for dragging out of that file and into Spring Config) > > But a String code might be better. My only concern so far is that > there is no simple way to find out whether the type that interests you > exists, since there is no central registry to define them. Searching > the whole codebase for something when you don't know its name could be > tedious. That is where the use of interfaces becomes valuable, you can always find all the classes that implement an interface rather easily in todays IDEs and we can use the Interfaces/Classes to define the Domain of use for a specific Event Type in the Code itself. > >> So a longer term question is, how do we align the EvenManager to be more >> like the EventService. And the steps to do that are going to look something >> like >> >> 1.) "masking" EventManager behind the EventService initially as an >> EventListener >> 2.) , replacing all calls to EventManager with calls to EventService >> 3.) finally rewriting EventConsumers to be EventListeners and dropping >> EventManager altogether from the codebase. > > Sensible. I'd been thinking along these lines ever since I saw that > there was a parallel event Service. > > What I'd like to know right now, though, is: since we are currently > at step 0, is there some reason not to introduce a new Event type for > the movement of an item from workspace/workflow to a Collection? It > sounds like the answer is: it was going to happen anyway. Yes, it seems so. I would just go for it. Mark R. Diggory Head of U.S. Operations - @mire http://www.atmire.com - Institutional Repository Solutions http://www.togather.eu - Before getting together, get t...@ther
------------------------------------------------------------------------------
_______________________________________________ Dspace-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspace-devel
