Win a copy of Serverless Applications with Node.js this week in the NodeJS forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Bear Bibeault
  • Jeanne Boyarsky
  • paul wheaton
Sheriffs:
  • Junilu Lacar
  • Paul Clapham
  • Knute Snortum
Saloon Keepers:
  • Stephan van Hulst
  • Ron McLeod
  • Tim Moores
  • salvin francis
  • Carey Brown
Bartenders:
  • Tim Holloway
  • Frits Walraven
  • Vijitha Kumara

Doubt about servlets capabilities and language recomendation  RSS feed

 
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am doing a webpage for work in JSP and they asked me for new features, so I'm learning about servlets because the logic is getting too big. What I don't want is to be doing this for a couple of weeks to only then realize servlets aren't good enough for what I want to do, so I need some advice.

Initially, the page is used to enter medical measurements (i.e. weight, bpm...) and also it works as a mail server, but now I have to implement some kind of notifications: another server will sent alert messages and I have to redirect (or show some sort of notification) to all sessions active at that moment. Are servlets and JSP capable of this? Do you recommend I use another language for that? Also, I've been coding from scratch, without any frameworks, do you recommend some framework for me, too?

I also should mention that the webpage MUST run on IE8, so the less javascript and modern functions the better.

Thanks in advance,
Frege.
 
Rancher
Posts: 1170
18
Firefox Browser Hibernate IntelliJ IDE Java MySQL Database Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Welcome to the ranch.
If you don't wan't to spend hours on xml configurations, I would advise you to use SpringBoot with an mvc or restarchitecture (since the notificatin come from a different server, rest seems the way to go)
It's the same princple as servlets, jsp's are sufficient, but the technology isn't used that mutch anymore, more and more people make the switch to jsf (I rather work with jsp's to, but just cause I'm more familiar with them).
If you have to start from scratch, you're better to use the newest
 
frege fregenal
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for the advice, I will check what is spring about and watch a tutorial on SpringBoot.
 
Saloon Keeper
Posts: 5344
143
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes, servlets and JSP can do this. The world at large is slowly moving away from server-side rendering (as embodied by JSP and JSF) towards client-side rendering using Javascript. But if you're trying to do without that, then server-side is fine. I am not seeing a shift towards JSF, so wouldn't advise on that.

Note that jQuery (version 1) works fine on IE 8, so any solution using that would work OK. For receiving notifications technologies like server-sent events or websockets would be neat, but IE 8 does not support those.
 
Bartender
Posts: 20580
121
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.

I'm not sure I agree with Tim Moore's asserting that apps are using client side rendering. Even when I use NodeJS, the page templates are on the server. But conversely, a lot of client GUI functions are JavaScript, especially the AJAX stuff, and that's true even with JSF. Many third-party JSF tagsets include a copy of jQuery internally.

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.
 
frege fregenal
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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.

I'm not sure I agree with Tim Moore's asserting that apps are using client side rendering. Even when I use NodeJS, the page templates are on the server. But conversely, a lot of client GUI functions are JavaScript, especially the AJAX stuff, and that's true even with JSF. Many third-party JSF tagsets include a copy of jQuery internally.

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.



I know you are right, but the IE8 thing with as little client side rendering as possible is an obligation. This will be used mostly by medical doctors and pharmacists, and doctors WILL use old pcs with a red button wich will open IE8 and stablish a VPN connection with the DB. And my page must work fine on those pcs. This is because healthcare is public so the databases are shared, and because of that they force doctors to use specific machines with specific software installed so they have "absolute control" over sent and received data.

Believe me when I say I'm the first one whose jaw dropped when I was told about the IE8 thing. I wouldn't be surprised a little bit if they tell me that these pcs have windows xp or 98 installed hahaha.

On the other hand: do you think I will get some noticeable advantages from switching to JSF? Currently I'm switching from JSP to servlets+springBoot, so any extra-time learning JSF should be justifiable.
 
Tim Holloway
Bartender
Posts: 20580
121
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.

The downside to using JSF, however, is that probably none of the the extensions such as RichFaces, IceFaces, PrimeFaces, and so forth will work properly with IE8. And in Red Hat (soon to be IBM) RichFaces, they have actually formally declared that they never will. In fact, I'm not even sure if JSF version 2 supports IE8, since the differences between IE8's JavaScript and industry-standard JavaScript is the primary reason why it was singled out as a cutoff point. And JSF version 2 uses AJAX, which means JavaScript.
 
frege fregenal
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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.

The downside to using JSF, however, is that probably none of the the extensions such as RichFaces, IceFaces, PrimeFaces, and so forth will work properly with IE8. And in Red Hat (soon to be IBM) RichFaces, they have actually formally declared that they never will. In fact, I'm not even sure if JSF version 2 supports IE8, since the differences between IE8's JavaScript and industry-standard JavaScript is the primary reason why it was singled out as a cutoff point. And JSF version 2 uses AJAX, which means JavaScript.



Yes, it's a pain in the ass, but it's the government who hire us and all healthcare is public here, so it's almost impossible that we have problems with lawsuits if we don't screw up badly. What my boss did was delegate security on the ones who had been already storing the medical info (the main ISP here). So they have a DB which can only be accessed (until now) from the VPN the doctors use (the big red button I told earlier). But now we (my page) will have to access the DB from a third party machine, and I don't really know how they want to manage.

But I agree with you that they need to do some major soul-searching. Most people suggesting the features of the system need help to access their own email so... that's something...
 
Tim Holloway
Bartender
Posts: 20580
121
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Oh, good. You can substitute lawsuits with "ambitious politician who demands an enquiry".

And in Europe, you can substitute HIPAA with "stringent digital privacy laws". And don't forget your cookies!
 
frege fregenal
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Instead of "stringent digital privacy laws" you should say "LOPD" but, besides that, you are right on the spot!
 
crispy bacon. crispy tiny ad:
global solutions you can do at home or in your backyard
https://www.kickstarter.com/projects/paulwheaton/better-world-boo
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!