Ron McLeod wrote:
frege fregenal wrote:I provided a link to another hosting with both files inside a zip.
The download link requires that an email address be provided to get the content - likely that will discourage most from taking a look at your message.
Tim Moores wrote:You can only attach image files. If the SOAP isn't too long you can include it in a post; make sure to use CODE tags and set the type to XML.
Tim Holloway wrote:Yes, it's an ironic truth that doctors are infamous for being technological laggards, but on the other hand, the US medical industry is tightly regulated - AND full of lawsuit-happy people, so using a technology that Microsoft doesn't support is opening up a major set of liabilities. And that's even before HIPAA gets involved. If a major leak of medical records gets tracked back to an un-repaired IE8 exploit, it would have major repercussions. Being a little out of date is somewhat forgiveable. Being so far out of date that you can't even get brought up to date borders on malfeasance. And many other countries are going to have similar considerations, if fewer lawyers.
I think the principals here need to do some major soul-searching before they promote a solution like this for new development.
JSF is, in fact, a very good platform for anything that is based on a lot of data entry. The JSF framework validates data automatically, and will actually refuse to act until every last item on a submitted form is valid. When a JSF action fires, your Model has already been updated with the data from the form and you know that that data is complete and valid. Note that for the most part "valid" here primarily means syntax and range. More complex constraints may still need to be checked by the action code, but in any event, if data is rejected, the form is re-displayed and error messages can be automatically placed either in a fixed area of the page or next to the offending form controls.
There is a bit of a learning curve, since most Java web programmers are used to a procedural approach, and JSF operates on Inversion of Control. Meaning that instead of having the app go out and get data, the JSF framework obtains the data from the form, validates it, and if it's valid, JSF itself injects the data into the Model (backing) bean properties. Likewise, changing the bean causes the next form display to update with the new bean properties.
Tim Holloway wrote:Be warned that IE 8 isn't just past End-of-Life, even the Walking Dead won't touch it. Absolutely FORGET about Microsoft giving you assistance unless you come to them with large quantities of money in your hands.
On top of that, IE 8 has some serious compatability issues with the rest of the world. Not IE6-level, but enough that the Red Hat JBoss Version 3 framework (which is also long past its end of support) won't work right with it.
In short, you are being commanded to construct a monster which is very likely to come back and blow holes in corporate security and fail in unpredictables ways at unpredictable times. And no one is going to feel sorry for you. Unless you pay them. And when you're that far behind, there are things that broke other things, that in turn broke other things. As I've said before, software doesn't "wear out", but it does rot from the outside (hardware, OS) in.
OK, now you've been warned. Regardless, servlets and JSPs are fully capable of doing major work. In fact, my understanding that that's exactly what Amazon.com was originally written in.
And despite the fact that JavaServer Faces doesn't get much love, it's my first option for form-based data entry apps, because it aids so much in the validation of the input data. And loved or not, it's part of the JEE standard, so vendor support is very good - which is more than I can say about IE8.
JSF isn't the only Java server-side technology, and I'll admit I'm biased towards it. I manage the JSF forum here on the Ranch. But the icing on the cake is that it's a non-exclusive technology, so if it doesn't need a particular set of needs, I can blend in other non-JSF features into a JSF webapp.