On Wed, Apr 6, 2011 at 6:10 AM, Mark H. Wood <mw...@iupui.edu> wrote: > On Tue, Apr 05, 2011 at 09:46:26AM -0700, Mark Diggory wrote: >> Recommendations are that a web ui (and specifically the XMLUI is of >> interest in this case) be constructed not on the "Xml files" >> themselves, but utilizing the DSpace Configuration Service. > > So is the Configuration Service able to represent *structured* values > in an effective and comprehensible fashion, as opposed to the horrid > mess that we sometimes get when trying to cram them into Properties > format using the old ConfigurationManager?
No, it doesn't at the moment. But switching over to XML is even more of a nightmare, ATM. It will just introduce more "custom parsing" approaches like we have in various classes now. the goal of the 2.0 work and the use of the service manager was an attempt to consolidate "custom" parsing. > > If not, and there's a need to serialize the resulting in-memory > structures without a lot of fuss, we might want to look at (say) JAXB > in cases where we need to express some kinds of complex relationships. Your heading in the right direction with the wrong technology. Spring is JAXB in reverse, rather than binding custom XML to Java objects, we use a standardized XML (or Java annotations) to wire together a series of existing Java Beans. Because of this, there is no "binding" that needs to be maintained, Spring already manages that, this is what I was doing the best I could to reflect in my tutorial example here: https://wiki.duraspace.org/display/DSPACE/The+TAO+of+DSpace+Services In this can there is no longer a need to worry about mapping/parsing XML to bind a the Launcher commands to, its just spring and done at runtime config by the service manager. We want the same application at all the levels of the configuration... major portions of what are in dspace/config would/should be redressed as spring configuration. Likewise, we should consider ( and this is a direct concept from the original DSpace 2.0 SimpleStorageService work) that we will want to associate configuration with the Domain Model Entities, and that its the structural framework we seek to align with. If you look throughout the configuration what you see are three types of abstraction a.) properties of a plugin b.) wiring of plugins into a service c.) associating a service/plugin with a DSpace entity (Community, Collection, Item) for (a) and (b) the Spring based Service Manager with associated Configuration Service is sufficient. The takes the need to configure DI in the dspace.cfg altogether because you do it in a more flexible "spring" approach. Thats a considerable amount of hierarchy eliminated or place under the management of Spring. for (c) we should work on the Domain Model such that we can attach properties as attributes of DSpaceObjects and thus if you review configurable submission, configurable reviewer workflow, curation tools, discovery configuration, etc you will find components in each that should be properties attached to the DSpace Domain Model Entities. We will ultimately end up with the question being, what from our current legacy configuration is attached to the Domain Model via db configuration and what gets sent to Spring configuration as wiring of the application. As a strong example, I would take the InputForms and consider that there are two components, (1) validation/schema that should be associated with the Item being created and (2) a set of form fields that are more associated with a "view" in the user interface. However, we really start to rethink what is"Domain Model" and "What is Service" when we dig into the Submission and Reviewer Workflows, here, depending on direction, we end up with two completely different treatments, just taking CS we have: (1) the assignment of a submission workflow to a collection. (2) the assignment of steps to a workflow id (3) the configuration of the capabilities of a step (inputforms and dspace.cfg) Treatment A : Make it a legitimate Domain Model We can treat the whole as Domain Model (which is appropriate given submission is at the heart of DSpace). If we do so, we end up with: (2) is a new Domain Model where, for the legacy case, we actually crete new database tables and DAO bindings for the Submission Workflow Steps. (1) is a Domain Model Association of workflow2collection (3) are simple configuration properites attached to the Collection and/or workflow and step entities. Treatment B : Make it all Service Manager / Spring based. (2) is treated as a set of steps wired in spring configuration (1) are simple properties on the Collection entities associating the workflow with the collection (3) are simple properties on the Collection and/or workflow and step entities. (requires more hierarchical config) This is a simpler design then Treatment A to get into place, but still puts configuration of workflow in the developer hands. Ultimately Treatment A takes a little more thought and work, but the payoff to the community is much more significant and it ultimately is the right choice. Theres a great deal of opportunity here if we get the design right from the get-go. What I am really trying to emphasize to the group is that you need to think out the overall DSpace design goals and strategy rather than focusing in on hacking little areas of the codebase, we should avoid custom parsing, likewise we should recognize that we have historically taken on a strategy for solving customizations to DSpace that is pigeonholing our application design, and that this approach selects for not creating or altering the true Domain Model for DSpace in favor of individual, unique and messy on the spot solutions that meet a local need. The later are like a cancer on an originally clean DSpace design. I really think the core committer groups responsibility to achieve a consensus on approaches that should/will be allowed to be contributed to DSpace and thus mediate the danger of these narrow vision micro-solutions continuing to propagate. Mark -- Mark R. Diggory @mire - www.atmire.com 2888 Loker Avenue East - Suite 305 - Carlsbad - CA - 92010 Technologielaan 9 - 3001 Heverlee - Belgium ------------------------------------------------------------------------------ Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev _______________________________________________ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
