[Dspace-devel] Replicated "Business Services" in DSpace UI's

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 somethin

Re: [Dspace-devel] Replicated "Business Services" in DSpace UI's

On 3 May 2011 20:34, Mark Diggory wrote: > 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

Re: [Dspace-devel] Replicated "Business Services" in DSpace UI's

Graham, On May 3, 2011, at 1:46 PM, Graham Triggs wrote: > On 3 May 2011 20:34, Mark Diggory wrote: > 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 probl

Re: [Dspace-devel] Replicated "Business Services" in DSpace UI's

On May 2, 2011, at 11:30 AM, Mark H. Wood wrote: > [tangent alert!] > I'd like to hear why we have the "owning collection" concept at all. > We would need a convenient way to find unlinked Items and operate on > them (link, delete, edit). > > -- > Mark H. Wood, Lead System Programmer mw...@iup

Re: [Dspace-devel] Replicated "Business Services" in DSpace UI's

On Tue, May 03, 2011 at 08:58:08AM -0700, Mark Diggory wrote: > I keep seeking a spot to jump in here and have about 4 unsent versions of > responses to this email thread, so it much be a good one ;-) Go for it! > Owning Collections are used for Inheritance of permissions. IMO, linking > should

Re: [Dspace-devel] Replicated "Business Services" in DSpace UI's

As usual, I want to quibble about terms. To me, an "event" is something that has already happened and I (as an event consumer) am merely being notified that it has happened. So event notices can be delivered whenever we get around to it. OTOH code which wants to participate in the event from a d

Re: [Dspace-devel] Replicated "Business Services" in DSpace UI's

On 4 May 2011 08:03, Mark Diggory wrote: > I think we should work to keep the Data Access Layer and the Business Logic > Layer separate. > I agree with that principle, but... > I see the Event Manager as Business Logic layer and the DAO as Persistence > layer. If you need to enforce integrity

Re: [Dspace-devel] Replicated "Business Services" in DSpace UI's

On 4 May 2011 15:12, Mark H. Wood wrote: > As usual, I want to quibble about terms. To me, an "event" is > something that has already happened and I (as an event consumer) am > merely being notified that it has happened. So event notices can be > delivered whenever we get around to it. > Fair

Re: [Dspace-devel] Replicated "Business Services" in DSpace UI's

I want to bump this thread, and to reconnect it to my original point. There is loads of replicated -- exact duplicate -- code in both xmlui, and jspui, and is going to be further replicated in the REST API, and other systems such as WebMVC. Also, there is other cases where the intention is the sa

Re: [Dspace-devel] Replicated "Business Services" in DSpace UI's

Just to add to what Peter's already said. I think this sounds like a great idea to me. I'd love to have a common "Business Services" layer that all UIs utilize, rather than duplicating this logic in each UI. I'd also be open to the idea of shifting to more broad usage of Services as we feel it

Re: [Dspace-devel] Replicated "Business Services" in DSpace UI's

Yes, I think an exercise in this direction would be clear if we can get the ok from the community to allow progress to go forward on 1.) Let the API changes (class signature change and dependency on dspace-core-api) go into the trunk so that people can actually start to work with them 2.) Final

Re: [Dspace-devel] Replicated "Business Services" in DSpace UI's

Most definitely a cheer from the peanut gallery. In trying to figure out how to do some things, I've found the functionality I wanted in other modules. I'm unsure whether to copy code from those modules or just include the appropriate java files. Either way makes me want to scream; even thou

Re: [Dspace-devel] Replicated "Business Services" in DSpace UI's

DRYing up the UI code sounds like a good idea to me. It's not the only part of DSpace that could use a little of that kind of attention. -- sands fish Senior Software Engineer MIT Libraries Technology Research & Development sa...@mit.edu E25-131 On Apr 29, 2011, at 12:

Re: [Dspace-devel] Replicated "Business Services" in DSpace UI's

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 wrote: > Hi All, > > I

Re: [Dspace-devel] Replicated "Business Services" in DSpace UI's

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

Re: [Dspace-devel] Replicated "Business Services" in DSpace UI's

On 2 May 2011 03:35, Richard Rodgers wrote: > > 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. Therefor

Re: [Dspace-devel] Replicated "Business Services" in DSpace UI's

I would tend to agree with the strangeness of the model ATM. It's kind of like modeling driving by saying Highway.driveCar() instead of Car.drive(Highway). It appears (to me) flipped from common logic. I don't know that this itself argues for creating a service, but it certainly calls out som

Re: [Dspace-devel] Replicated "Business Services" in DSpace UI's

[tangent alert!] I'd like to hear why we have the "owning collection" concept at all. We would need a convenient way to find unlinked Items and operate on them (link, delete, edit). -- Mark H. Wood, Lead System Programmer mw...@iupui.edu Asking whether markets are efficient is like asking wheth

Re: [Dspace-devel] Replicated "Business Services" in DSpace UI's

The only explanation that I have ever been able to come up with is that if you enter an item handle in a browser the item needs to be displayed in the context of some collection, the owning collection. Not a serious suggestion but - you could effectively abandon the current community/collection st

Re: [Dspace-devel] Replicated "Business Services" in DSpace UI's

I keep seeking a spot to jump in here and have about 4 unsent versions of responses to this email thread, so it much be a good one ;-) Owning Collections are used for Inheritance of permissions. IMO, linking should have been better accomplished so that there was a clear difference between a "Li

Re: [Dspace-devel] Replicated "Business Services" in DSpace UI's

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#L1