Hi guys,
Yes, Peter and I have some interesting dialogs ongoing... It would pair well.
I will say... Peter, there is a delete method on Item, albeit, the behavior
seems to lack certain "checks"
https://github.com/DSpace/DSpace/blob/master/dspace-api/src/main/java/org/dspace/content/Item.java#L1914
What is being challenged is that work is happening at the UI level to remove
the item from the collections prior to calling Item.delete (also "inferred" by
its removal from the last collection).
https://github.com/DSpace/DSpace/blob/master/dspace-xmlui/dspace-xmlui-api/src/main/java/org/dspace/app/xmlui/aspect/administrative/FlowItemUtils.java#L412
The question here is should formally deleting an Item with Item.delete() remove
it from its owner collections (and other possible domain/services it is
associated with). Unless there is database Cascade removing the records from
the coll2item etc tables... which I assume, otherwise even the delete method
would always fail for items in the case that the item is still in a collection.
So reviewing Collection.java's removeItem method... we see, theres the logic
that evaluates if theres any collection which still holds the Item, deleting it
if there is not... Seems to just be a "helper" to me, the real pervasive
"delete" should be encapsulated within the item itself.
https://github.com/DSpace/DSpace/blob/master/dspace-api/src/main/java/org/dspace/content/Collection.java#L938
Item.delete should:
1.) Remove its policies
2.) delete its children
3.) remove the item from its parents.
4.) delete its metadata.
5.) possibly call out to any AddOn "request interceptors/listeners" to give
them an opportunity to do some work within the deletion transaction window.
Sure, Collection.removeItem should check for any remaining collection owners
before ever attempting a call to item delete, thats only fair.
Item.delete should be different than Collection.removeItem as a function of the
domain model.
And finally code is replicated in the XMLUI api that does the same work as
Item.delete.
https://github.com/DSpace/DSpace/blob/master/dspace-xmlui/dspace-xmlui-api/src/main/java/org/dspace/app/xmlui/aspect/administrative/FlowItemUtils.java#L631
The big question emerging from the dialog around the Domain Model Proposal is
"How much of this is 'Data Model' and how much is 'Business Services' or
'Helpers'.
My last discussion with Peter and others revolves around "How swappable" do we
want DSpace "behavior" to be. I will give an example:
Example: Hacking Domain Model Locally
Right now, to add behavior to DSpace when Item state is altered has two options:
a.) Alter the Item code
b.) Write a consumer.
The problem with (a) is that we need to maintain differences against core
codebase and merge those differences over time, this is a problem when we have
multiple projects / addons altering the core codebase. Which wins, how do we
maintain both over time, altering the Domain Model is great until you have a
larger community with lots of unique customizations
The problem with (b) is that we can't participate in the transactional window
and utilize the Context /database capabilities to complete our CRUD operations.
We have to spawn our own transactional window after the current transaction and
we cannot use foreign key constraints against the dspace data model tables to
assure our database tables integrity, resulting in a lot of extra coding to
roll our own integrity checking.
I offer up that the benefits of the Domain Model and the Service Manager are
that we be able to attain the "happy medium" where Addons can participate in
the transactional window and contribute their own database tables into DSpace.
By utilizing the SOA approach, we create chained DAO services that can
participate in the transaction window. This was Jim Rutherfords original idea
with the Stackable DAO.
https://github.com/DSpace/DSpace/blob/dspace-dao-prototype/dspace-api/src/main/java/org/dspace/dao/StackableDAO.java
https://github.com/DSpace/DSpace/blob/dspace-dao-prototype/dspace-api/src/main/java/org/dspace/content/dao/ItemDAOFactory.java
What James was struggling with was the means to configure the stack of DAO that
would participate in the transactional window. I think that with the Spring
Service Manager, we now have an opportunity to answer his question.
Mark
On Apr 29, 2011, at 1:07 PM, Joseph wrote:
> Sounds like a great idea to me.
>
> If i'm not confused, then I think this would pair well with Mark Diggory's
> work Refactoring the Domain Model
> https://wiki.duraspace.org/display/DSPACE/Refactoring+the+DSpace+Domain+Model
> -Joseph
>
>
>
>
> On Fri, Apr 29, 2011 at 12:47, Peter Dietz <pdiet...@gmail.com> wrote:
> Hi All,
>
> I'd like to get an effort going to clean up some of the logic that resides in
> the UI's, and move that near-identical logic to a central service, such as
> dspace-api. The benefit of this is that it will simplify the contract that we
> have the UI's make. Plus, selfishly, when building something that talks to
> DSpace, there is a lot of replicated code, much of it ugly, that I don't want
> to essentially copy verbatim into my project.
>
> Let me ask you off the top of your head, how do you delete an item?
>
> Hint: There's no item.delete();
>
>
> Examples
> JSPUI - EditItemServlet.doDSPost#CONFIRM_DELETE
> https://github.com/DSpace/DSpace/blob/master/dspace-jspui/dspace-jspui-api/src/main/java/org/dspace/app/webui/servlet/admin/EditItemServlet.java#L202
>
> XMLUI - FlowItemUtils.processDeleteItem
> https://github.com/DSpace/DSpace/blob/master/dspace-xmlui/dspace-xmlui-api/src/main/java/org/dspace/app/xmlui/aspect/administrative/FlowItemUtils.java#L404
>
> WebMVC - ItemController.processItemDelete
> https://github.com/DSpace/webmvc/blob/master/webmvc-api/src/main/java/org/dspace/webmvc/controller/admin/ItemController.java#L73
>
> REST...
> SWORD...
> Some external software interacting with DSpace (Cotinga, Drupal, 3rd party
> software)...
>
>
> Typically, its implemented by the following in all cases.
>
>
>
>
>
> for (Collection collection : collections)
>
>
>
>
>
>
>
>
> {
>
>
>
>
>
>
> collection.removeItem(item);
>
>
>
>
>
>
>
>
> }
>
>
>
> But shouldn't a simple item.delete() should be enough?
> And why do we need to make the UI know all this?
>
> Then what about item.curate()? That's not something that should live in the
> item domain, but rather some service should do.
>
> So, how much about the internals of DSpace do we need to expose to a client?
> And continued, who performs the authentication checks?
>
> There's alot of crud required just to do some CRUD.
>
> I bring this up now, because even though item.delete is very simple, I'd like
> to get something better in place before something horrifically ugly like
> SaveGroup
> https://github.com/DSpace/DSpace/blob/master/dspace-xmlui/dspace-xmlui-api/src/main/java/org/dspace/app/xmlui/aspect/administrative/FlowGroupUtils.java#L162
>
> I don't want to make the dspace-api code any heavier, but I'd like to
> simplify how things work. Hopefully facilitating some of our GSoC projects,
> and simplifying all projects that interact with the DSpace code. Hopefully
> simpler will mean less buggy.
>
> Thoughts, ideas, prior-art, cheers, jeers?
>
>
> Peter Dietz
>
>
> ------------------------------------------------------------------------------
> WhatsUp Gold - Download Free Network Management Software
> The most intuitive, comprehensive, and cost-effective network
> management toolset available today. Delivers lowest initial
> acquisition cost and overall TCO of any competing solution.
> http://p.sf.net/sfu/whatsupgold-sd
> _______________________________________________
> Dspace-devel mailing list
> Dspace-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/dspace-devel
>
>
> ------------------------------------------------------------------------------
> WhatsUp Gold - Download Free Network Management Software
> The most intuitive, comprehensive, and cost-effective network
> management toolset available today. Delivers lowest initial
> acquisition cost and overall TCO of any competing solution.
> http://p.sf.net/sfu/whatsupgold-sd_______________________________________________
> Dspace-devel mailing list
> Dspace-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/dspace-devel
------------------------------------------------------------------------------
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network
management toolset available today. Delivers lowest initial
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
_______________________________________________
Dspace-devel mailing list
Dspace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-devel
