4 ms·

A Java app of my university does this too. Is this a practice shared by most Java programmers? How come?

by progval 10y ago

meddlepal 10y ago
Not in modern Java... or any I've seen in the last several years. There's a lot of fucked up legacy code and frameworks out there though.
pavement 10y ago
This practice has nothing to do with Java, at all. It is not an approach that was invented by Java, for Java, and it is not in any way unique to Java. Most web technologies support rendering a view based on a set of values residing in a database, and use the values to populate a template. The template contains placeholders reserved for values expected to originate from a database. The version of the page that appears in your web browser usually does not exist as a serialized HTML page on a disk connected to a server. It often only exists as a representation of two pieces of information bound to a session in memory on a server: 1. The Template or server-side script, 2. the values you are authorized to retrieve from the database, which may or may not be a SQL database. What you see in the address bar does not need to correlate to the HTML rendered in the browser window. JavaScript (which is not Java) often employs this technique, termed as a "single page web application." This is true for PHP, Mcrosoft, Ruby, Python, Perl, server-side JavaScript (such as node.js) and yes Java too.
- jsolson 10y ago
  What's being described above isn't simply template-based rendering (which, yes, essentially everything does), but the practice of building web-software like desktop software and keeping the state of the UI server-side. It ignores that browsers are capable of effectively forking the UI through (today) tabs and (historically) "Open in New Window". Interacting with such software is a profoundly unpleasant experience; thankfully it's not particularly common, especially outside of "enterprise" applications (including government services, public utilities, education management, property management, healthcare, etc.) It is not Java-specific, but it is common to a few specific Java frameworks as well as at least one of Microsoft's older frameworks (I forget which one). The vast majority of frameworks (including most modern Java frameworks) do the sane thing and keep application state on the server side (often in a database, as you describe) and UI state on the browser side, which allows links and forms to work the way links are generally supposed to work.
  - anticedent 10y ago
    Which is great, because everybody should downvote anything because of a mild distinction, rather than the wildly off the mark question that prompted a reasonable response. Good job!
    - jsolson 10y ago
      I, at least, did not downvote the original post. I assumed it was honest ignorance of the practice I described in my reply.
  - DaiPlusPlus 10y ago
    > It is not Java-specific, but it is common to a few specific Java frameworks as well as at least one of Microsoft's older frameworks (I forget which one). ASP.NET WebForms has a feature where the Session ID, normally stored in a cookie, is stored in the request URL path instead. This was done back in 1999-2001 to support extremely rudimentary HTTP clients which did not support HTTP Cookies - imagine really prototypical mobile-phone web-browsers or hastily-written shell scripts using CURL. Fortunately it was disabled by default and the documentation describes why it's a bad idea to use it - and I understand the business reasons for including it - however this design does not break things like multiple-tab browsing: that's just what happens when you have any stateful web-application, regardless of framework. It's now gone in ASP.NET MVC (where you gave full control over rendered URLs), so that horrid chapter has ended.
    - dotandimet 10y ago
      Storing things in the URL only got you so far (Internet Explorer would eventually complain about the request string being too long), so ASP.Net or whatever would bundle the entire stateful object into a hidden form, which would be submitted with POST via Javascript when the link was clicked.
  - jethrow 10y ago
    What's being described above isn't simply template-based rendering How are you able to draw that conclusion? The GP didn't supply a link as an example. It is simply a non-specific anecdotal remark, with no further evidence provided.
vborinquen 10y ago
God, what a retarded question. The mind boggles at its asking.
deleted 10y ago
[deleted]
tritosomal 10y ago
It's called a "Single Page Application" or SPA, and it's made with JavaScript. https://en.wikipedia.org/wiki/Single-page_application https://en.wikipedia.org/wiki/Single-page_application
timv 10y ago
Historically it was fairly common. I wouldn't say it was standard, but it happened often enough to notice. There's a bunch of reasons that come together to cause that. During the explosion of the web, enterprises moved much of their development into web solutions using an existing workforce that had skills in different technologies - often client-server desktop-to-RDBMS tech. Java was a popular choice for these new projects. Those developers would range in their general aptitude - some were quite good, some weren't - but they all came onto these projects with existing skills and knowledge in patterns and architectures that weren't particularly well aligned with web development. They were expected to adapt and deliver at pace consistent with their previous projects. So they did what they could to get the job done, even though that meant that their solutions were not well suited to the web environment. That doesn't have a lot to do with Java specifically, except that it was a common language for that situation. It was far more common for enterprises to take VB/PowerBuilder/Delphi/etc Devs and move them into Java than something like PHP. But Java was more likely to produce this horrible implementation for a couple of reasons. Firstly, as a general purpose language (that also happened to have decent web capabilities) it was easy to design an application using your traditional patterns and then just shoe-horn the web UI on top. You were far less likely to do that in a web-oriented platform like PHP or ColdFusion (!). Secondly, the Java servlet spec makes sessions really easy (because it stores standard, stateful, Java objects) and didn't offer a lot for managing complex page state. You could spend several days trying to build something to page through database search results with query parameters, only to find that the back button broke your design. Or you could just throw it all into the session, and call it "done". That probably peaked about 15 years ago, but inertia is a strong force, particularly in government and large enterprises. Some of those developers are probably still working like that. Some of them trained others. And many others know that it's a bad design, but there's no budget to fix it.
- anticedent 10y ago
  This is being conflated as a Java thing, because of a sideways remark about Brazilian programmers. Reading other comments, it's now clear that in this instance we are dealing with a Microsoft Server. [0] [0] https://news.ycombinator.com/item?id=14173595 https://news.ycombinator.com/item?id=14173595
- 10y ago

A Java app of my university does this too. Is this a practice shared by most Java programmers? How come?

by progval 10y ago

A Java app of my university does this too. Is this a practice shared by most Java programmers? How come?

Not in modern Java... or any I've seen in the last several years. There's a lot of fucked up legacy code and frameworks out there though.

pavement 10y ago

This practice has nothing to do with Java, at all. It is not an approach that was invented by Java, for Java, and it is not in any way unique to Java. Most web technologies support rendering a view based on a set of values residing in a database, and use the values to populate a template. The template contains placeholders reserved for values expected to originate from a database. The version of the page that appears in your web browser usually does not exist as a serialized HTML page on a disk connected to a server. It often only exists as a representation of two pieces of information bound to a session in memory on a server: 1. The Template or server-side script, 2. the values you are authorized to retrieve from the database, which may or may not be a SQL database. What you see in the address bar does not need to correlate to the HTML rendered in the browser window. JavaScript (which is not Java) often employs this technique, termed as a "single page web application." This is true for PHP, Mcrosoft, Ruby, Python, Perl, server-side JavaScript (such as node.js) and yes Java too.

jsolson 10y ago
What's being described above isn't simply template-based rendering (which, yes, essentially everything does), but the practice of building web-software like desktop software and keeping the state of the UI server-side. It ignores that browsers are capable of effectively forking the UI through (today) tabs and (historically) "Open in New Window". Interacting with such software is a profoundly unpleasant experience; thankfully it's not particularly common, especially outside of "enterprise" applications (including government services, public utilities, education management, property management, healthcare, etc.) It is not Java-specific, but it is common to a few specific Java frameworks as well as at least one of Microsoft's older frameworks (I forget which one). The vast majority of frameworks (including most modern Java frameworks) do the sane thing and keep application state on the server side (often in a database, as you describe) and UI state on the browser side, which allows links and forms to work the way links are generally supposed to work.
- anticedent 10y ago
  Which is great, because everybody should downvote anything because of a mild distinction, rather than the wildly off the mark question that prompted a reasonable response. Good job!
  - jsolson 10y ago
    I, at least, did not downvote the original post. I assumed it was honest ignorance of the practice I described in my reply.
- DaiPlusPlus 10y ago
  > It is not Java-specific, but it is common to a few specific Java frameworks as well as at least one of Microsoft's older frameworks (I forget which one). ASP.NET WebForms has a feature where the Session ID, normally stored in a cookie, is stored in the request URL path instead. This was done back in 1999-2001 to support extremely rudimentary HTTP clients which did not support HTTP Cookies - imagine really prototypical mobile-phone web-browsers or hastily-written shell scripts using CURL. Fortunately it was disabled by default and the documentation describes why it's a bad idea to use it - and I understand the business reasons for including it - however this design does not break things like multiple-tab browsing: that's just what happens when you have any stateful web-application, regardless of framework. It's now gone in ASP.NET MVC (where you gave full control over rendered URLs), so that horrid chapter has ended.
  - dotandimet 10y ago
    Storing things in the URL only got you so far (Internet Explorer would eventually complain about the request string being too long), so ASP.Net or whatever would bundle the entire stateful object into a hidden form, which would be submitted with POST via Javascript when the link was clicked.
- jethrow 10y ago
  What's being described above isn't simply template-based rendering How are you able to draw that conclusion? The GP didn't supply a link as an example. It is simply a non-specific anecdotal remark, with no further evidence provided.

vborinquen 10y ago

God, what a retarded question. The mind boggles at its asking.

deleted 10y ago

[deleted]

tritosomal 10y ago

It's called a "Single Page Application" or SPA, and it's made with JavaScript. https://en.wikipedia.org/wiki/Single-page_application https://en.wikipedia.org/wiki/Single-page_application

timv 10y ago

Historically it was fairly common. I wouldn't say it was standard, but it happened often enough to notice. There's a bunch of reasons that come together to cause that. During the explosion of the web, enterprises moved much of their development into web solutions using an existing workforce that had skills in different technologies - often client-server desktop-to-RDBMS tech. Java was a popular choice for these new projects. Those developers would range in their general aptitude - some were quite good, some weren't - but they all came onto these projects with existing skills and knowledge in patterns and architectures that weren't particularly well aligned with web development. They were expected to adapt and deliver at pace consistent with their previous projects. So they did what they could to get the job done, even though that meant that their solutions were not well suited to the web environment. That doesn't have a lot to do with Java specifically, except that it was a common language for that situation. It was far more common for enterprises to take VB/PowerBuilder/Delphi/etc Devs and move them into Java than something like PHP. But Java was more likely to produce this horrible implementation for a couple of reasons. Firstly, as a general purpose language (that also happened to have decent web capabilities) it was easy to design an application using your traditional patterns and then just shoe-horn the web UI on top. You were far less likely to do that in a web-oriented platform like PHP or ColdFusion (!). Secondly, the Java servlet spec makes sessions really easy (because it stores standard, stateful, Java objects) and didn't offer a lot for managing complex page state. You could spend several days trying to build something to page through database search results with query parameters, only to find that the back button broke your design. Or you could just throw it all into the session, and call it "done". That probably peaked about 15 years ago, but inertia is a strong force, particularly in government and large enterprises. Some of those developers are probably still working like that. Some of them trained others. And many others know that it's a bad design, but there's no budget to fix it.

anticedent 10y ago
This is being conflated as a Java thing, because of a sideways remark about Brazilian programmers. Reading other comments, it's now clear that in this instance we are dealing with a Microsoft Server. [0] [0] https://news.ycombinator.com/item?id=14173595 https://news.ycombinator.com/item?id=14173595
10y ago