Certainly in the database, but we should also consider the development model
for your work critical to re usage of this functionality in the future 2.0
release of DSpace. To do so you really only have to follow a few important
guidelines in your work that I would recommend target 1.6.0 for the fall.
1.) Try at all costs not to alter the existing org.dspace.core or
org.dspace.content whenever possible
2.) Focus on using a Service Architecture approach when designing your
solution. This means:
a.) It has its own data model independent of the dspace core and
content models, I would recommend reducing any DSpace Object (like
Collection) to a string identifier before you store it into the Service and
do not cross the service boundaries by returning core or content instances
in your API.
b.) The one caveat to the above is that you should feel free to
continue the model in 1.6 of passing org.dspace.core.Context in your
methods, there is a clear path now for porting out of this situation when
migrating Manager classes from DSpace 1.6 to 2.0.
c.) Keep your "Manager/Service" separate from the data model and keep
your model anemic (meaning it should just be very simple beans).
d.) Keep your "Manager/Service" a Singleton Object with a non-static
Interface that can be retrieved via a single static getInstance method. This
will reduce any needs for refactoring from static methods to non-static ones
when migrating to 2.0.
Following the above steps in building the service and persistence layers
will assure your work will be easily portable to DSpace 2.0 and will greatly
assist us in beginning the porting process for Submission Workflows to 2.0
in the future.
Sincerely,
Mark
On Wed, May 13, 2009 at 7:08 AM, gaurav kejriwal <gaurav...@gmail.com>wrote:
> Dear Dspace Community,
> I have been selected for Google Summer of Code 2009 for my project on
> "Submission Enhancements" to work under the guidance of my mentors Claudia
> Juergen and Stuart Lewis.My project aims at developing UIs for the Dspace
> admins so that they can manage the input forms and submission workflow.Also
> the project aims at allowing item type based submission.More details can be
> found at the wiki page
> http://wiki.dspace.org/index.php/Google_Summer_of_Code_2009_Submission_Enhancements
> .
>
> To implement this,we can follow 2 approaches.Either we can manage the forms
> and submission work flow through db or just create a new updated
> inputforms.xml/item-submissions.xml file when the admin chooses the options
> through UI without disturbing the core database.
> I need the community to suggest which approach will be better considering
> future Dspace development.Please suggest which approach will be better to
> follow.
> Thanks
> Regards
> Gaurav
--
Mark R. Diggory
@mire NV USA
http://www.atmire.com
------------------------------------------------------------------------------
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image
processing features enabled. http://p.sf.net/sfu/kodak-com
_______________________________________________
Dspace-devel mailing list
Dspace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-devel
