[OKC JUG] Guidance

[Ivan Zhidov]

Given Jackie's experience I would suggest a low-tech approach of 
creating a simple JSP-based aplication that processes the uploaded file 
using the existing validation logic and presents the user with the 
output text file with listed errors. If no errors were encountered the 
data shall be persisted in the database.

The idea is to re-use as much of the existing process as possible and 
deploy it with very little effort. Jetty or Tomcat should be sufficient.

Ivan


Jason Lee wrote:
> On Mon, Jun 2, 2008 at 2:35 PM, Jackie Oram <grndrt1 at yahoo.com 
> <mailto:grndrt1 at yahoo.com>> wrote:
>
>     I'm currently using Netbeans IDE 6.1 with GlassFish V2 to develop
>     my project.  The error listing that I previously wrote about is
>     not a server log.  My users will be reporting data that must
>     adhere to error validation before loading into Oracle tables.  A
>     report will be returned to the user stating information about
>     their data submission:  number of records, elements flagged as
>     errors, no errors found, etc... 
>
>
> I'm a bit confused as to what, exactly, the application does.  Is it 
> simply reporting a list of errors currently stored in the database, or 
> is it taking input from the users, validating it, and then reporting 
> errors from that data set?
>
> Either way, I think (and I know some people who are going to laugh at 
> me) that JSF is a fine solution for that. 
>
> Trying to sketch out the architecture over email is difficult at best, 
> especially given the information we have, but I'll shoot from the 
> hip.  My guess is that the user will be uploading a data file of some 
> sort (since they will be told "the number of records").  If that's 
> true (and I'm going to be making a BUNCH of guesses and assumptions 
> here), then you have (or will have) a set of model classes to hold the 
> data uploaded (the file is uploaded, and the data read and stored in 
> one or more classes).  That's probably how I'd do it at least.  With 
> the uploaded data, you'd probably have a List of data objects which 
> you would then pass to the validation code.
>
> This part of the code does what it should and stores validation 
> errors...somewhere.  How you handle this will vary from developer to 
> developer.  From the hip, you might create a ValidationError object 
> that holds a reference to the data object that failed validation, with 
> its attributes being something like myDataObject, 
> validationErrorMessage.  If the list returned is non-null or 
> non-empty, send the user to a page that lists the error message.  If 
> desired, prefered, possible, etc., this table could then have a link 
> to an edit page for the user to correct the validation error.  You may 
> opt, though, to report which records have errors and require the user 
> to fix them locally, and then reupload the data.  That requirement 
> will be driven more by the business than any real technology question, 
> as any web framework worth its salt can handle either scenario easily.
>
> Either way, once the data passes with no validation errors, it can be 
> passed, for example, to the data access layer for persisting in the 
> database.  Up to this point, this data would likely be held in memory 
> (if the dataset is not too long) as an instance variable on your 
> session-scoped bean.  At any rate, the data is sent to its final 
> destination, any instance vars holding state are cleaned up (or nulled 
> out) and the user is sent to a "success" page.
>
> How does that sound? :P  Like I said, it's from the hip, so it 
> probably needs work, but should, I hope, give you a push in the right 
> direction.  I helped, if ever so slightly, on a very similar system at 
> IEC, for what that's worth.
>
> I hope that helps (and doesn't overwhelm.  That's a lot of text. :)
>
> -- 
> Jason Lee, SCJP
> Software Architect -- Objectstream, Inc.
> Mojarra and Mojarra Scales Dev Team
> https://mojarra.dev.java.net
> https://scales.dev.java.net
> http://blogs.steeplesoft.com
> ------------------------------------------------------------------------
>
> _______________________________________________
> Jug mailing list
> Jug at lists.okcjug.org
> http://lists.okcjug.org/listinfo.cgi/jug-okcjug.org
>   

-------------- next part --------------
A non-text attachment was scrubbed...
Name: izhidov.vcf
Type: text/x-vcard
Size: 86 bytes
Desc: not available
URL: <http://lists.okcjug.org/pipermail/jug-okcjug.org/attachments/20080602/9626e7c0/attachment-0003.vcf>