• 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 Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

JSP in Future / Future of JSP

 
Ranch Hand
Posts: 452
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello Mr. Hans Bergsten,
Beacuse of struts and other frameworks, writing java code in the JSP page has been reduced. Developers prefer to follow MVC architecture, and also use of tags is preferred over writing methods or scriplets in the JSP Page. This is not what Sun have thought when the introduced JSP (i,e, scriplets / methods being ignored)

With the type of usage changing what new future do you expect will be or should be introduced in JSP in coming years. For last couple of years many new tag library has been added to JSP. Has we reached a level where no further improvement can be done and only work will be done in building new tags?
 
Ranch Hand
Posts: 8945
Firefox Browser Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Prakash,
I feel that JSP is matured now. The main purpose was division of labor where the web developers who are not familiar with Java can develop JSP, this would mean no scriptlets.
The previous version did not achieve the same but the JSP 2.0 version brought in JSTL, EL etc where there is zero Java code.
 
Pradeep bhatt
Ranch Hand
Posts: 8945
Firefox Browser Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Has we reached a level where no further improvement can be done and only work will be done in building new tags?


Tags are the best way of bringing in new feature, rather than introducing something that is completely new.

I am sure that Mr. Hans Bergsten will have better answer for your question.
 
Prakash Dwivedi
Ranch Hand
Posts: 452
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Tags are the best way of bringing in new feature, rather than introducing something that is completely new.
As JSP is now very often used to listen client request directly, will Sun introduce some new type of JSP.
I am asking this because when EJBs were introduced they were purely distributable that is listening only remote calls, later it was observed that in most of the cases developers were calling EJBs from local machine only, hence concept of local interfaces were introduced. Will we have some JSPs in future which may not be capable of listening Http requests at all or some other changes like that.
 
Pradeep bhatt
Ranch Hand
Posts: 8945
Firefox Browser Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Will we have some JSPs in future which may not be capable of listening Http requests at all or some other changes like that.


I dont see this happening. JSP are for generating dynamic web content,if they cannot be invoked using HTTP protocol I am not sure where else they could be used.
:roll:
 
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Pradeep Bhat:
I dont see this happening. JSP are for generating dynamic web content,if they cannot be invoked using HTTP protocol I am not sure where else they could be used.

As a templating mechanism. As someone already mentioned, few moderately sized applications expose JSPs as the "first point of contact", i.e. receiving HTTP requests directly. Mostly it's the servlet who does that and the JSP is only delegated to for view rendering.
 
Pradeep bhatt
Ranch Hand
Posts: 8945
Firefox Browser Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Mostly it's the servlet who does that and the JSP is only delegated to for view rendering.


True but what is the advantage if JSP cannot be invoked via HTTP ? What I mean ..If they are just used as templates (with no HTTP enablement) are we gaining anything other than may be enforce MVC ?
[ March 11, 2004: Message edited by: Pradeep Bhat ]
 
Ranch Hand
Posts: 4982
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
This is also the concept of MVC. The Servlet mainly handles the requests, see which JSP should be used, and what data is needed from the DB.
Struts doing the same thing as well. But of course, usually, the entry point of the Web-based system should be a JSP, and after that, all goes to Servlets.
Nick
 
Author
Posts: 106
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Prakash Dwivedi:
Hello Mr. Hans Bergsten,
Beacuse of struts and other frameworks, writing java code in the JSP page has been reduced. Developers prefer to follow MVC architecture, and also use of tags is preferred over writing methods or scriplets in the JSP Page. This is not what Sun have thought when the introduced JSP (i,e, scriplets / methods being ignored)

With the type of usage changing what new future do you expect will be or should be introduced in JSP in coming years. For last couple of years many new tag library has been added to JSP. Has we reached a level where no further improvement can be done and only work will be done in building new tags?


I could swear I answered a similar question about likely JSP features for future revs of the spec yesterday, but I can't find it. Am I being censored?
Anyway, first let me correct to misconceptions:
1) JSP, and all other Java specifications, are developed by representatives from many companies, not by Sun. See http://jcp.org/ for details.
2) Tag libraries were part of the plan from day 1 but were not formally introduced until JSP 1.1 due to release plan deadlines. SCriptlets have never been encouraged, but they were hard to avoid until JSTL 1.0 and the EL were introduced.
Regarding what the future holds, JSP is more or less done IMHO. The only core changes I think may be desireable at this point are related to the EL API and possibly adding some hooks for better integration with JSF,
The EL should ideally be moved to a separate specification to make it easier for other technologies besides JSP to use it (JSF is one example) and to allow it to evolve independently. It should also be tweaked a bit to make it a bit more generic and "type declarations" should be added to allow for better design-time error detection.
I know that some people want to make JSP useable as a generic "template processor" outside of HTTP, e.g., for generation of mails and resports. I disagree, because I think too generic solutions end up being harder to use. A better approach would be to break out other parts besides the EL that can be used for other technologies, but keep JSP focused on generating HTTP responses.
 
Ranch Hand
Posts: 5093
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
yes, you did answer the same yesterday
I agree that decoupling JSP from HTTP would be overkill. There's enough templating engines out there already...
 
Prakash Dwivedi
Ranch Hand
Posts: 452
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks Mr Bergsten for such a nice explaination. But i have few queries
The only core changes I think may be desireable at this point are related to the EL API and possibly adding some hooks for better integration with JSF,
Won't this be unfair to other frameworks like struts :roll:
I know that some people want to make JSP useable as a generic "template processor" outside of HTTP, e.g., for generation of mails and resports. I disagree, because I think too generic solutions end up being harder to use.
I fully agree that this could be harder to use, but won't it be better if we have both the version at the same time. That is this new change comes as an add on and not as a replacement. So that the developers can choose which is best for him.
 
Lasse Koskela
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Prakash Dwivedi:
Won't this be unfair to other frameworks like struts


Why would we be bothered about unfairness? This isn't a competition and the Struts developers are not selling Struts for a living.

Originally posted by Prakash Dwivedi:
I fully agree that [JSP as a generic template engine] could be harder to use, but won't it be better if we have both the version at the same time. That is this new change comes as an add on and not as a replacement. So that the developers can choose which is best for him.


But we do have both at the same time. JSP for page-oriented templating and Jakarta Velocity for the generic stuff. I don't see a real need for including Velocity into the JSP specification...
 
Sheriff
Posts: 67746
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Am I being censored?


Hmmm, certainly not by me -- and I can't imagine any of the sheriffs doing so. And I do recall the post. If I get a chance in a little bit I'll see if I can track it down.
 
Nicholas Cheung
Ranch Hand
Posts: 4982
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Because we always wanna things become better, that's why we try to find out more and more interesting things, like Struts, JSF, etc.
In the way of a standardization for JSPs, writing JSPs become more and more complicated. But IDE sometimes may life easier, like JBuilder, can already convert non-advanced JSPs into Struts tag format.
Nick
 
Hans Bergsten
Author
Posts: 106
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Prakash Dwivedi:
Thanks Mr Bergsten for such a nice explaination. But i have few queries
The only core changes I think may be desireable at this point are related to the EL API and possibly adding some hooks for better integration with JSF,
Won't this be unfair to other frameworks like struts :roll:
I know that some people want to make JSP useable as a generic "template processor" outside of HTTP, e.g., for generation of mails and resports. I disagree, because I think too generic solutions end up being harder to use.
I fully agree that this could be harder to use, but won't it be better if we have both the version at the same time. That is this new change comes as an add on and not as a replacement. So that the developers can choose which is best for him.


When I say "hooks for better integration with JSF", I mean looking at what frameworks like JSF needs in order to integrate better with JSP and making the hooks generic and public. Other similar framworks can also use them if needed, so there's nothing unfair about it. I hope everyone realize the difference between a specification developed through the JCP where pretty much anyone can participate and the resulting complete API is public, and a proprietary published API where some methods are kept secret and used only by the vendor for better integration of its own products.
Regarding generic specifications, I'm all for generic components that can be used to build focused "frameworks" or products. To me, JSP is a framework that should stay focused on generating response to HTTP requests, otherwise it just get harder to use. But if there are pieces of JSP that would be usedful for a separate "template engine" specification to use, by all means, they should be decoupled from JSP so that they can be reused. The EL is one example, but there may be others. All I'm saying is that I don't believe in having one "framework" for doing everything; I rather see many "frameworks" for specific purposes, built from a common pool of components.
 
Hans Bergsten
Author
Posts: 106
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Bear Bibeault:

Hmmm, certainly not by me -- and I can't imagine any of the sheriffs doing so. And I do recall the post. If I get a chance in a little bit I'll see if I can track it down.


I was kidding, of course. But thanks for looking into it.
 
Ranch Hand
Posts: 1934
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Future is a combination of JSF, Struts and JSP.
Go J2EE go
Kishore.
 
blacksmith
Posts: 1332
2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Hans Bergsten:
To me, JSP is a framework that should stay focused on generating response to HTTP requests, otherwise it just get harder to use.


Hear, hear!
I haven't worked on a JSP project since the bubble, but I have to say that project - which was abandoned when the initial budget ran out - might well have been completed within that budget had we had JSTL available to ease the interaction between the programmers and the HTML folks, and possibly the workflow aspects of Struts. As best I can tell without reading your book (which Amazon says isn't available yet), the workflow benefits of Struts aren't duplicated by JSTL or JSF; it's just the tag library functionality that may overlap, which I don't see as a problem.
Then again, I haven't actually used anything other than scriptlets, so I'd be interested in hearing from people with practical experience with the more recent technologies.
I would say that it appears to me there's one weakness in all of these newer technologies (JSTL, JSF, and Struts) - they don't seem to me to interact well with client side scripting. Okay, I know client side scripting is evil, but it does allow the creation of nice UI features that depend on faster response than a page reload can provide ... after using the cool little airline seat selection windows on those web travel agency sites, I found it a lot harder to stonewall client feature requests that could only really be implemented using Javascript/ECMAscript. Am I missing something here?
Warren
 
If you look closely at this tiny ad, you will see five bicycles and a naked woman:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic