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 would be necessary.
One thought that comes to my mind is whether the REST API can actually help to drive the creation of this "Business Services" layer. In other words, a proper REST API should likely just be a "thin layer" which exposes the underlying "Business Services" API via REST. If we were able to achieve that, then *all* existing UIs (XMLUI, JSPUI, WebMVC) could be refactored to either: (a) When deemed appropriate, actually make calls to the REST API to perform various tasks, or (b) alternatively, call directly upon the Business Services layer (by bypassing the REST API "thin layer"). This is just one idea of we could potentially fit this "Business Services" idea into an existing initiative. Obviously, it'd require some refactoring of the REST API work. But, that might actually be easier than coming from the opposite direction of attempting to "extract" out the essence of Business logic commonalities from XMLUI, JSPUI and WebMVC into one common API (which is something that the REST API project already did, in a way). - Tim On 5/11/2011 1:09 PM, Peter Dietz wrote: > 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 same, but the > implementation is different. Some better, some worse. > > For item metadata change. > Some have sloppy implementations: XMLUI, WebMVC (for now). > They clear all existing metadata from the item, and then add new fields > of everything that was submitted by the form. > > Others have really elegant implementations: Bulk Metadata Importer > It compares the submitted metadata field with what already exists in the > item, and updates it if it has changed. > > But, if there is an easy to use off-the-shelf component / business > service available to me, I'll use that instead of creating (replicating > exactly) my own. Then our performance Czar can focus on tweaking the > business services. Our reliability czar can focus on all the business > services being tested. Our New Features Czar can rest easy that the > standard stuff is taken care of for them. > > > I think that having Business Services available in DSpace would require > that we shift to using Services, and having the basic singleton service > do everything as normal. And then have an enhanced business service > added to gives us extra (yet very common) abilities available for each > data model object. However, this is where I (and the subject) need > clarification. > > > Peter Dietz > > > > On Wed, May 4, 2011 at 12:15 PM, Graham Triggs <[email protected] > <mailto:[email protected]>> wrote: > > On 4 May 2011 15:12, Mark H. Wood <[email protected] > <mailto:[email protected]>> 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 enough. I would tend to talk about messages as being what's > passed around (and can be synchronous), and events as being a > special type of message (which is asynchronous). > > However, I do note that Spring has an internal synchronous > notification system, in which it delivers ApplicationEvent. Whilst I > wouldn't necessarily take that terminology out of choice, I wouldn't > go to the lengths of building / integrating a different system, so I > would be obliged to take on their terminology. > > G > > > ------------------------------------------------------------------------------ > 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 > [email protected] > <mailto:[email protected]> > https://lists.sourceforge.net/lists/listinfo/dspace-devel > > > > > ------------------------------------------------------------------------------ > Achieve unprecedented app performance and reliability > What every C/C++ and Fortran developer should know. > Learn how Intel has extended the reach of its next-generation tools > to help boost performance applications - inlcuding clusters. > http://p.sf.net/sfu/intel-dev2devmay > > > > _______________________________________________ > Dspace-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/dspace-devel ------------------------------------------------------------------------------ Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay _______________________________________________ Dspace-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspace-devel
