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
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.)
Graham,
On May 3, 2011, at 1:46 PM, Graham Triggs wrote:
On 3 May 2011 20:34, Mark Diggory mdigg...@atmire.com 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.
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...@iupui.edu
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
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
On 4 May 2011 08:03, Mark Diggory mdigg...@atmire.com 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
On 4 May 2011 15:12, Mark H. Wood mw...@iupui.edu 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
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
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
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
On 3 May 2011 20:34, Mark Diggory mdigg...@atmire.com 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
On 2 May 2011 03:35, Richard Rodgers rrodg...@mit.edu 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
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
[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
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()
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
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
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.edumailto:sa...@mit.edu
E25-131
On Apr 29, 2011, at 12:47
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
20 matches
Mail list logo
