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.
> 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.
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.
> 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.
--
Mark H. Wood, Lead System Programmer mw...@iupui.edu
Balance your desire for bells and whistles with the reality that only a
little more than 2 percent of world population has broadband.
-- Ledford and Tyler, _Google Analytics 2.0_
pgpPHV0n1HEb7.pgp
Description: PGP signature
------------------------------------------------------------------------------
_______________________________________________ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
