HI Mark: You might want to keep an eye on the CGI stuff we are working on - it essentially amounts to your option #3 (DB serialization). I should have a demo ready by OR11, but if you are interested in 'early access', I'd be happy to give you a look.
Thanks, Richard On Apr 7, 2011, at 11:43 AM, Mark H. Wood wrote: > On Wed, Apr 06, 2011 at 11:27:53AM -0700, Mark Diggory wrote: >> 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. > > Well that's what made me think of JAXB, since it writes the parsers > for us and we just ask the resulting objects what was in the parse > tree. I don't want to think about what "input-forms.properties" would > look like, or the code it would take to decipher that. > >>> 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: > > I would certainly rather use Spring, which we already have to deal > with, than introduce Yet Another Technology. But I don't recall > seeing a way to get Spring to serialize altered "injectables" back to > something it can read next time, and that seems to be a requirement? > Something like JAXB is read/write. > > If we are going to have a web UI to alter forms and ingestion flow, we > need to be able to store the alterations. (IOW we *do* need a > binding.) We can do that several ways: > > 1. write the altered definitions out in the same XML format we use > now. It was designed to represent the relationships in question, > and XML does so naturally. > > 2. write the altered definitions out in Properties format so that > ConfigurationManager or ConfigurationService can deal with them. > This forces us to represent structure in a fragile and unnatural > manner. > > 3. translate the XML schema to a database schema and hide all the > relational hair in DBMS tables. The DBMS is supremely adapted to > supporting us in this, once we get the entities clear and the > relationships represented in code. > > 4. adjust our set of classes as needed so that we can use a > serialization toolkit like JAXB to take care of the storage details > for us. > > 5. write out a new Spring context (more XML). See below for why this > is really really hard. > > There may be others. If those are the choices, I'd probably go with > #3, even though it may be the most work up front. > > The DBMS approach still requires a loader for the default setup. I'd > still go with XML for this. > >> 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. > > Yes. But what does that have to do with the Configuration Service? > The example isn't using that anywhere I can see. Rather it introduces > a new Service which is configured through Spring. > >> 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) > > d.) standalone properties, used all over DSpace > e.) lists of standalone properties > f.) standalone hierarchial structures masquerading as sets of maps with > funny-looking keys > >> 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. > > One may wonder why we need the Service Manager for this. It would > seem that Spring suffices. > >> 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. > > Sensible. > > d, e, f need to be assigned to beans, and then Spring can just jack > them into the appropriate objects. dspace.cfg, this.cfg, that.cfg, > quux.cfg *all* go away and we don't need a ConfigurationAnything. > >> 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. > > At that point, external configuration boils down to "dude, where's my > database?" One question whose answer *does* fit the Properties format > (for standalone applications) and can also be supplied by a servlet > container via JNDI. Or let Spring handle the standalone case. > >> 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. > > Well, if we want to provide UI to customize this stuff, then B really > can't be done. Because, to persist the changes, we have to figure out > where Spring got its instructions for wiring up the objects, and > replace those instructions through a big pile of code that knows how > to write Spring context descriptions. The "figure out where Spring > got it" is the part I don't see how we can do. Depending on how > things are mixed together, we may not be able to do the "replace with > new wiring" either since we might stomp all over things that have > nothing to do with what we are altering. Unless you want to pull it > all into (one or more!) DOM trees, do surgery thereon, and serialize > it all back to the appropriate place(s) (which we don't know). > > So we really first need to work out what we want to configure using a > text editor, and what using DSpace UIs. > >> 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. > > I agree that it is time for an overall review of configuration with an > eye to supplying *representations* and mechanisms that are appropriate > to the code, the entity (Collection, Community, Site) managers, and > the system administrator. (If I'm not putting words in your mouth.) > It seems clear to me that DSpace provides configuration facilities > which no longer match the ways it needs to be configured and the ways > that the people responsible for its functioning want to interact with > it. > > -- > Mark H. Wood, Lead System Programmer mw...@iupui.edu > Asking whether markets are efficient is like asking whether people are smart. > <ATT00001><ATT00002..c><ATT00003..c> ------------------------------------------------------------------------------ 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
