Just a quick FYI for those interested (and listening in on this thread): I've implemented Graham's Configurable Submission suggestions in preparation for 1.5 beta (and 1.5 final release). So, if you look at the current 1.5.x branch in DSpace SVN, there is now a single 'item-submission.xml' configuration file containing the configurations for BOTH the XML-UI and JSP-UI.
A <step> configuration now looks like this in the item-submission.xml: <step> <heading>submit.progressbar.describe</heading> <processing-class>org.dspace.submit.step.DescribeStep</processing-class> <jspui-binding>org.dspace.app.webui.submit.step.JSPDescribeStep</jspui-binding> <xmlui-binding>org.dspace.app.xmlui.aspect.submission.submit.DescribeStep</xmlui-binding> <workflow-editable>true</workflow-editable> </step> The Configurable Submission documentation is also updated in [dspace]/docs/submission.html (when you download the 1.5.x branch). Let me know if there are questions, or if anyone notices any bugs. I did some pretty thorough testing, so it *should* be bug-free...famous last words. :) - Tim Tim Donohue wrote: > Graham, > > Ok...I'm coming around, and I agree with your argument about forcing > people to do things the 'right way' in terms of Java programming, and > also better supporting both UIs. > > I'll take some time this week to dig into the 1.5 code and see what a > change like this would involve. Assuming there's no major walls or > sticky points in moving this route, I should be able to implement this > relatively easily and quickly for 1.5. > > - Tim > > Graham Triggs wrote: >> On Mon, 2008-01-07 at 11:01 -0600, Tim Donohue wrote: >>> (1) No ability to easily change the review JSP without recompiling. But, >>> that may not be a big deal...as you noted the same is currently true for >>> the JSPs used to create the various submission forms >> There is nothing to say we couldn't have optional extended configuration >> - so it could be made possible to add additional <input-jsp> and >> <review-jsp> elements to the configuration - or even attributes to the >> jsp-binding element. >> >> That said, the only time that really becomes useful is if you want to >> specify what is eseentially the same step in different submission >> workflows, with different L&F for each. >> >>> (2) If someone wanted to create a custom step for JSPUI-only, they'd >>> have to still create two separate classes: (1) Processing Class and (2) >>> JSP binding class. The current way, you'd just need to create a single >>> Processing Class which implements the JSPStep interface. >> That is absolutely no bad thing. Firstly, although you would have to >> supply two separate classes, the difference in the amount of code >> involved is negligible. >> >> More importantly, it means people do things the right way - so if they >> want to move from JSP to XML ui in the future, or they want to share >> their custom step with our members of the community that may be using a >> different interface, it's all a lot easier. >> >>> On the plus side, your idea does vastly simplify the configurations. >>> The only other option your suggestion brings to mind (which would keep >>> the API mostly as-is), would be to take an in-between route and create a >>> configuration looking more like: >>> >>> <step> >>> <heading>general.progress.describe</heading> >>> <jspui-binding> >>> <processing-class>org.dspace.app.webui.submit.step.JSPDescribeStep</processing-class> >>> <review-jsp>/submit/review-metadata.jsp</review-jsp> >>> </jspui-binding> >>> <xmlui-binding> >>> <processing-class>org.dspace.submit.step.DescribeStep</processing-class> >>> <xml-ui-class>org.dspace.app.xmlui.aspect.submission.submit.DescribeStep</xml-ui-class> >>> </xmlui-binding> >>> <workflow-editable>true</workflow-editable> >>> </step> >> I prefer my 'simplistic' configuration, as forcing people to deal with >> the class seperation now provides them with long term benefits, and >> improves the community's ability to collaborate. >> >>> Here, the UI "binding" is down at the configuration level...and it would >>> allow the <jspui-binding> and the <xmlui-binding> to change more over >>> time, as necessary. As a potential example, configurations/options for >>> various steps could eventually be placed as such: >> as mentioned above, the configuration could still allow for: >> >> <step> >> ... >> <xml-binding>...</xml-binding> >> <jsp-binding>...</jsp-binding> >> <jsp-form>...</jsp-form> >> <jsp-review>...</jsp-review> >> </step> >> >> or preferably: >> >> <step> >> ... >> <xml-binding>...</xml-binding> >> <jsp-binding form="..." review="...">...</jsp-binding> >> </step> >> >> G >> >> This email has been scanned by Postini. >> For more information please visit http://www.postini.com >> >> >> ------------------------------------------------------------------------- >> Check out the new SourceForge.net Marketplace. >> It's the best place to buy or sell services for >> just about anything Open Source. >> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace >> _______________________________________________ >> DSpace-tech mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/dspace-tech >> > -- ======================================== Tim Donohue Research Programmer, Illinois Digital Environment for Access to Learning and Scholarship (IDEALS) 135 Grainger Engineering Library University of Illinois at Urbana-Champaign email: [EMAIL PROTECTED] web: http://www.ideals.uiuc.edu phone: (217) 333-4648 fax: (217) 244-7764 ======================================== ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ DSpace-tech mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspace-tech
