Hi Peter:
Some quick reactions:
cheer: looking for common business logic is a very good idea, and packaging it
in a non-ui-centric way is also good for all the reasons stated.
jeer(not really): however, I'm not sure item.delete() best illustrates your
point. Having a public item.delete() would bend both the data model and the
authorization model in a way, which is why
it wasn't offered to begin with (I'm guessing):
The data model forces all items to belong to at least one container
(collection) - this is why there is no public item.create() either (which would
allow uncontained items in the repository).
Items can also belong to other containers. Therefore the API requires that
calling code (not just UI code, by the way) manipulate items though a
collection.
The authorization model distinguishes regular users (where policies are
checked) and administrative 'super' users ( where they aren't).
The assumption is that most calls are made by regular users of the system with
limited powers. So how would item.delete() work for regular users?
Suppose they had permissions on a linked collection of the item, but not on
the owning collection. Would it fail completely, succeed in removing the item
from collections the user was allowed to do, and leave the rest? The semantics
(contract) of the method become a little more complicated.
The only user that could be assured of success would be the super-user, and
what is the use-case for an administrator deleting an individual item?
So while we certainly could make make life easier for the UI or other callers
by encapsulating all the code loops, etc I think there is a reasonable argument
here for the content API to bare it's teeth
and force a verbose but clearer, more explicit, semantic model of the item.
Having said all this, I do think you are on quite fertile ground here, and
there are many areas where we can factor out common business coding patterns...
Thanks,
Richard
On Apr 29, 2011, at 12:47 PM, Peter Dietz 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
<ATT00001..c><ATT00002..c>
------------------------------------------------------------------------------
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
