[OCP 17 book] | [OCP 11 book] | [OCA 8 book] [OCP 8 book] [Practice tests book] [Blog] [JavaRanch FAQ] [How To Ask Questions] [Book Promos]
Other Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, TOGAF part 1 and part 2
Ulf Dittmer wrote:It's easy to get started with. JSPs generally get reloaded/recompiled automatically, whereas Java code -either in backing beans or in servlets- requires a restart of the web app.
Regards,
Anayonkar Shivalkar (SCJP, SCWCD, OCMJD, OCEEJBD)
Anayonkar Shivalkar wrote:But in the days of 'hot-redeploy', I don't think that is a problem
Tim Moores wrote:
Anayonkar Shivalkar wrote:But in the days of 'hot-redeploy', I don't think that is a problem
I think it is. Take a look around these forums - most of the folks who use scriptlets have trouble getting a web app to run in a servlet container running inside an IDE; much less in a servlet container running outside of an IDE. Do you think they've mastered hot redeploy?
Seetharaman Venkatasamy wrote:it takes time.... most projects are in maintenance/enhancement(at least in india). people tends to write(most of them write) scriptlet even in development(from scratch) project.
1.to use JSTL etc.., jar needs to put explicitly.
some new developer may afraid to deploy it in lib.
2.some of the developer dont want to learn new things...
Seetharaman Venkatasamy wrote:2.some of the developer dont want to learn new things...
[OCP 17 book] | [OCP 11 book] | [OCA 8 book] [OCP 8 book] [Practice tests book] [Blog] [JavaRanch FAQ] [How To Ask Questions] [Book Promos]
Other Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, TOGAF part 1 and part 2
That's hardly the only alternative.Bear Bibeault wrote:Er, yeah, because building up complex HTML, CSS, and JavaScript markup in strings inside servlets is so much more productive!
![]()
Tim Moores wrote:
Anayonkar Shivalkar wrote:But in the days of 'hot-redeploy', I don't think that is a problem
I think it is. Take a look around these forums - most of the folks who use scriptlets have trouble getting a web app to run in a servlet container running inside an IDE; much less in a servlet container running outside of an IDE. Do you think they've mastered hot redeploy?
Frank Silbermann wrote:
That's hardly the only alternative.Bear Bibeault wrote:Er, yeah, because building up complex HTML, CSS, and JavaScript markup in strings inside servlets is so much more productive!
![]()
There is also Velocity which, though low level, can be more easily built upon.Bear Bibeault wrote:He may also be referring to alternate templating engines such as FreeMarker that were created back in JSP1 days when JSP sucked. Because JSP2 is pure templates, there really isn't any advantage to using those any more -- it's just the same as JSP2 but with a proprietary syntax.
Or he might be referring to frameworks like Play that aren't based on JEE at all, and use a proprietary templating technology (using Groovy or Scala).
But, the vast majority of people writing Java-based web apps use JEE and JSP and should be using JSP2 and not JSP1. It's been freaking 10 years!
Hi JeanneJeanne Boyarsky wrote: What do you think are the reasons people keep writing code in the JSP?
Rudy Gireyev wrote:
I personally prefer using JSP code for presentation layer because
Timothy Stone, MIT, SCJP
http://www.petmystone.com/
"This Satan's drink [coffee] is so delicious, we shall cheat Satan and baptize it." --Pope Clement the VIII (1592-1605)
Ant Jackson wrote:
Rudy Gireyev wrote:
I personally prefer using JSP code for presentation layer because
Agreed. Also TLD libraries are more difficult to debug.
Bear Bibeault wrote:
Ant Jackson wrote:
Rudy Gireyev wrote:
I personally prefer using JSP code for presentation layer because
Agreed. Also TLD libraries are more difficult to debug.
Arguments such as "it's easier" are invalid. It's much important to do thing correctly, than to do them easily. And tags really aren't all that hard to debug either, if they're used.
Enthuware - Best Mock Exams and Questions for Oracle Java Certifications
Quality Guaranteed - Pass or Full Refund!
[OCP 17 book] | [OCP 11 book] | [OCA 8 book] [OCP 8 book] [Practice tests book] [Blog] [JavaRanch FAQ] [How To Ask Questions] [Book Promos]
Other Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, TOGAF part 1 and part 2
[OCP 17 book] | [OCP 11 book] | [OCA 8 book] [OCP 8 book] [Practice tests book] [Blog] [JavaRanch FAQ] [How To Ask Questions] [Book Promos]
Other Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, TOGAF part 1 and part 2
Yup. I got that.Jeanne Boyarsky wrote:Rudy: I meant any Java code. I didn't have any specific code in mind.
Bear Bibeault wrote:Arguments such as "it's easier" are invalid.
Correctly, as defined by whom?Bear Bibeault wrote:It's much important to do thing correctly, than to do them easily.
Bear Bibeault wrote:Arguments such as "it's easier" are invalid.
Invalid on what basis? Spaghetti code is more difficult to read and maintain than code that is clear and concise. Should we stop writing code that is clear and concise and start writing spaghetti code because it is more difficult?
Correctly, as defined by whom?Bear Bibeault wrote:It's much important to do thing correctly, than to do them easily.
![]()
Please remember EJBs were once "The" technology to do things "correctly". I know you are old enough to remember.
[OCP 17 book] | [OCP 11 book] | [OCA 8 book] [OCP 8 book] [Practice tests book] [Blog] [JavaRanch FAQ] [How To Ask Questions] [Book Promos]
Other Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, TOGAF part 1 and part 2
Frank Silbermann wrote:I think the rule should be generalized to Don't Use JSPs.
Frank Silbermann wrote:
What annoys me most about the JSP approach is the difficulty obeying the SLAP -- the Single Level of Abstraction Principle (http://www.ibm.com/developerworks/java/library/j-eaed4/index.html).
... With most JSP-based applications that I've seen, HTML is written not to reflect generic application-wide layout decisions but rather is custom-written for individual user tasks.
Bear Bibeault wrote:Many (most) people do use JSP badly, but I'm not sure that's the fault of JSP itself.
When Facelets was added to JSF, we finally had a respectable Java standard for web development. That said, I don't like the way JSF is taught. You can read five books on JSF and never learn how to instantiate and configure components in code (rather than in XHTML), which is essential for many re-use scenarios.E Armitage wrote:
Agreed. JSF with Facelets is a much better option. The EE spec has already moved on from JSP.
Frank Silbermann wrote:..
For example, suppose there is a database that you want unsophisticated users to mine for information. They don't know SQL, so you want to give them a few dozen queries that they can parameterize and enter. Depending on the query and its parameters, you will get a different set of columns. You certainly don't want to have to lay out the table in XHTML for every permutation -- you'd rather have generate the table configuration from a POJO that is created from the database result set via code. (In fact, for quick and dirty internal applications there should be a modifiable default way of displaying the results of a generic database query without having to _repeat_ in XHTML the table schema information that was already coded elsewhere, and which is already present in the ResultSet -- or at least a reasonably easy way to write one.)
..
That is very disconcerting. I built a system such as I described quite easily using Wicket (to be fair, my table panes were display-only), but the Enterprise Architecture group insists that it be rewritten using one of their technology standards. It was hoping that JSF/Facelets could save the day, because using lower-level frameworks would basically mean re-implementing something like Wicket from scratch.E Armitage wrote:
Frank Silbermann wrote:..
For example, suppose there is a database that you want unsophisticated users to mine for information. They don't know SQL, so you want to give them a few dozen queries that they can parameterize and enter. Depending on the query and its parameters, you will get a different set of columns. You certainly don't want to have to lay out the table in XHTML for every permutation -- you'd rather have generate the table configuration from a POJO that is created from the database result set via code. (In fact, for quick and dirty internal applications there should be a modifiable default way of displaying the results of a generic database query without having to _repeat_ in XHTML the table schema information that was already coded elsewhere, and which is already present in the ResultSet -- or at least a reasonably easy way to write one.)
..
This is a painful thorny issue for me. A big advantage of component based frameworks is that there should be good tooling support (drag and drop and on the fly code generation) since the components are well (and pre) defined. Yet dynamic table generation still remains a problem. Even in EE6 with facelets it's difficult to achieve without you running into runtime vs page compile time tag problems. Especially if you use the new (convenient) ViewScope for the backing beans. I recently had to resort to a mixture of JSTL and facelet tags to get it to work when I'm really supposed to be moving away from JSTL tags with facelets.
Well, that would move us closer to the Applet idea (though not the Applet implementation).Bear Bibeault wrote:The current trend in web applications is moving away from complicated server-side apparatus and towards more client-side frameworks and instrumentation, with the server frequently relegated to providing a simple RESTful API consumed by the client. This ultimate Separation of Concerns bodes well for server-side scalability, but of course, presents its own set of unique challenges that the industry is currently addressing.
Over-complicated server-side machinery like JSF (and to me, all but the simplest JSPs), especially those that interject themselves heavily into the presentation UI, are beginning to feel very dinosaur-ish.
It's a wonderful time to be working the arena of web apps -- so much new stuff going on, and my reading list is sky high!
P.S. Frank, this trend directly addresses the concern you voiced. Dealing with heavily tagged JSP/JSF/whatever pages can be a nightmare from client-side code. With no (or minimal) server-side intrusion into the HTML, those concerns are mitigated or dissappear.
Frank Silbermann wrote:Well, that would move us closer to the Applet idea (though not the Applet implementation).
Of course, I still don't see why it would be more desirable to code in HTML/CSS/JavaScript rather than in, say, a language which compiled to the "machine" implemented by the browser (the GWT idea).
Duh, I didn't say we're moving closer to Applets; I said closer to the Applet idea. (i.e., to execute code in the browser). I guess you didn't read the part where I wrote "though not the Applet implementation".Bear Bibeault wrote:
Frank Silbermann wrote:Well, that would move us closer to the Applet idea (though not the Applet implementation).
Not at all. Since the advent of Ajax, more and more functionality has been moving to the client. No applets, no plugins, no non-native elements. This is simply a continuation of that trend.
Bear Bibeault wrote:
Of course, I still don't see why it would be more desirable to code in HTML/CSS/JavaScript rather than in, say, a language which compiled to the "machine" implemented by the browser (the GWT idea).
You are in the minority on that front. Most web devs would rather deal with the client code directly than let something generate it for them. GWT is a tool that certainly has its place, but it'll never become wide-spread.
Frank Silbermann wrote:Duh, I didn't say we're moving closer to Applets; I said closer to the Applet idea. (i.e., to execute code in the browser). I guess you didn't read the part where I wrote "though not the Applet implementation".
If it is indeed more desirable to code in HTML/CSS/JavaScript, perhaps it should be explained why for twenty years no one felt the need to create a HTML/CSS/Javascript environment for building stand-alone PC applications.
I know that writing HTML/CSS/JavaScript is what most webdevs do, but I've always presumed this was either:
Consider Paul's rocket mass heater. |