Graham, That is a good idea to try and simply things on the configuration end. I'm still bouncing it around in my head as to whether it's the best option or not...
There's a few disadvantages I can see: (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 (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. 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> 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: <jspui-binding> <processing-class>org.dspace.app.webui.submit.step.JSPDescribeStep</processing-class> <settings> <input-forms>my-input-forms-JSPUI.xml</input-forms> <form-jsp>/submit/my-edit-metadata.jsp</form-jsp> <review-jsp>/submit/my-review-metadata.jsp</review-jsp> </settings> </jspui-binding> Obviously, this is not possible right now...but, in the future, maybe it'd be nice to be able to pass settings/configurations to a specific UI step to allow it to act differently, etc. Thoughts? Do you (or others listening) still prefer the more simplistic configuration (i.e. your suggestion), or this other potential route? - Tim Graham Triggs wrote: > Tim, > > Obviously there has to be binding between the JSP interface and the > processing class - however, I don't see why that needs to be a class > extended from the main processing class. > > So, like xmlui, you could just specify a 'binding' class that implements > the JSP binding interface (doPreProcessing / doPostProcessing), and the > controller can simply call that around the main processing class. This > binding implementation could also include the path to the review JSP > (getReviewJSP) - it already encapsulates the submission form. > > There is no reason for the heading to be a full key name - it can just > be a description, and the controller for the XML or JSP interface can > prefix it with 'jsp.submit.' or 'xmlui.Submission.' as appropriate. It > would mean changing the full key used in at least one of the JSP or XML > interfaces, but as that means better harmonisation between the > interfaces, that's no bad thing. > > The net result would be a configuration that looks something like: > > <step> > <heading>general.progress.describe</heading> > <processing-class>org.dspace.submit.step.DescribeStep</processing-class> > <jsp-binding>org.dspace.app.webui.submit.step.DescribeStepBinding</jsp-binding> > <xmlui-binding>org.dspace.app.xmlui.aspect.submission.submit.DescribeStepBinding</xmlui-binding> > <workflow-editable>true</workflow-editable> > </step> > > G > > > > On Fri, 2008-01-04 at 09:10 -0600, Tim Donohue wrote: >> Scott, >> >> There's still unfortunately two XML files, since the "step" definitions >> for both the JSPUI and XMLUI differ quite a bit. Take for example the >> "Describe" step definitions: >> >> 'Describe' for JSPUI: >> >> <step> >> <heading>jsp.submit.progressbar.describe</heading> >> <processing-class>org.dspace.app.webui.submit.step.JSPDescribeStep</processing-class> >> <review-jsp>/submit/review-metadata.jsp</review-jsp> >> <workflow-editable>true</workflow-editable> >> </step> >> >> 'Describe' for XMLUI: >> >> <step> >> <heading>xmlui.Submission.general.progress.describe</heading> >> <processing-class>org.dspace.submit.step.DescribeStep</processing-class> >> >> <xml-ui-class>org.dspace.app.xmlui.aspect.submission.submit.DescribeStep</xml-ui-class> >> <workflow-editable>true</workflow-editable> >> </step> >> >> >> You'll notice they are almost entirely different...there are a few >> things going on here: >> >> (1) The JSPUI and XMLUI use different I18N, so they need to have >> differently specified <heading> tags (which correspond to the >> appropriate I18N key) >> >> (2) The JSPUI requires a special JSP "processing" class, which >> implements JSPStep to do appropriate pre/post-processing in order to >> pass appropriate parameters to the JSPs for display. The JSPUI also >> needs a special "<review-jsp>", which is loaded by the "Review" step to >> allow it to be dynamic enough to review all steps in the proper order. >> >> (3) The XMLUI has an <xml-ui-class> which acts as the Step "Transformer" >> necessary for Manakin, and builds the display for that interface. >> >> Believe me, I've tried to figure out a simple way to merge these two >> XMLs. But, unfortunately, since the differences between the JSPUI and >> XMLUI are too great, I haven't been able to come up with an easy >> resolution to the issue. If someone else has an extra pair of eyes to >> look more closely at this before the final 1.5 version, maybe there's a >> resolution that I'm overlooking. >> >> My only other thought has been to actually put both configurations in >> one gigantic configuration file, and mark a <submission-process> as >> being either "interface=xmlui" or "interface=jspui". But, I haven't had >> the time to rework the API to support this (although, I may be able to >> free up time to do so, if everyone else thinks this is the better way of >> doing things). >> >> -Tim >> ------------------------------------------------------------------------- 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
