JSP 2.0 Proposed Final Draft Available

Discussions

News: JSP 2.0 Proposed Final Draft Available

  1. JSP 2.0 Proposed Final Draft Available (30 messages)

    The proposed final draft of the Java Server Pages (JSP) 2.0 spec is now available for download. Some new changes in JSP 2.0 include the ability to write taglibs without java, the addition of an expression language, requirement of J2EE 1.4, JSP fragments, a simpler tag invocation protocol, and more.

    Download JSP 2.0 Proposed Final Draft.

    The early access binaries are also availalbe.

    Threaded Messages (30)

  2. I want jsp2.0 now! :)

    Tag-libs as jsp-files sounds very interesting as it will probably greatly improve reuse of common tasks?

  3. JSP is all well and good, but many EJB people are becomming a bit obsessed with web pages and forgetting GUI interfaces. A really well designed GUI gives about 1000 times more functionality than JSP ever could. Its goof to hear they have a draft that makes improvements but it is important that the professional programmer be aware of what interface works best for which group. All users are not created equal.

    JSP is great for interfaces external to the company and as an internal reporting tool. For internal manipulation of data, a well designed GUI will always surpass the JSPs by leaps and bounds.

    I dont understand the obsession personally. Good GUIs are nto hard to design if you throw that drag and drop GUI builder out the window.

  4. I dont understand the obsession personally. Good GUIs are nto hard to design if you throw that drag and drop GUI builder out the window.


    Have you ever thought about maintenance costs. With what are you planning to write that GUI-application? Java and Swing maybe? So everyone who wants to use that software need also somekind of runtime (JRE). I think that main reason why so many apps are ported to web nowadays is simply because:

    a) they are easy to deploy (everyone has a browser already, don't they?)
    b) they are easy to keep up to date
    c) they are quite easy to debug (depending on app)
    d) they are basically easy to use (everyone who can browse www can use your app? eh)
    e) they use standard protocols (basically http/https)

    etc.

    > A really well designed GUI gives about 1000 times more functionality than JSP ever could

    Are you talking about some video editing application or what? Basic HTML (and maybe PDF) is all that is needed for most business-type (B2B, B2C, etc.) applications. I know that you can create more flexible and rich GUIs with swing or something similar, but if that is needed you can probably use Flash or something more web friendly technique.
  5. ...and another major factor with JSP is that it will run well on pretty much any old hardware. Try your nifty Swing/1.4 GUI on a P90 and you'll see what I mean!
  6. Actually the use of JSP doesnt bother me when it is appropriate. The problem is that it is being used when it isnt appropriate. When developing applications where you control he deployment, internal to companies, developing a rich GUI imparts more functionality and power than DHTML could ever hope to produce. I find it amazing that the industry hasnt learned from the burst in the dot com bubble. The web is merely one tool in the arsenal, not the panacea of all. Many developers are abandoning quality products to get it on the web. Just gettign it working is not good enough.

    IMHO there is a trend going on in the industry that is disturbing. You see developers complaining that thez have to learn something new or actually properly architect code. These bastions of the industry are being burried under a mountain of HTML hacks that just slap it together and throw it on the web and path themselves on the back.

    The right tool for the right job is needed. JSP is good for some jobs but for many it is horribly flawed.

    I wont even go into the maintenance allegations leveled earler because they are just ludicrous. Id rather manage a GUI than a collection of web page generators any day. But then, maybe that is because I invested time doing what many people seem to have trouble doing, I learned it.

  7. Id rather manage a GUI than a collection of web page

    > generators any day. But then, maybe that is because I
    > invested time doing what many people seem to have trouble
    > doing, I learned it.

    Funny, you seem to think that it is harder to develop a well behaving application using a GUI like Swing than to do it with JSP/Servlets or XML/XSLT, and that it somehow makes you a better developer because you know how. I hold exactly the opposite view, I think that it is harder to develop a well behaving application using a Web based architecture, not because of the technlogy used to render the user interface, but because of the limitations of the protocol used for communication between the client and the server, i.e HTTP. Opposite to what you seem to think, rendering the UI is seldom the most challenging part of implementing an application.
  8. Robert Simmons wrote: "...JSP is all well and good, but many EJB people are becomming a bit obsessed with web pages and forgetting GUI interfaces. A really well designed GUI gives about 1000 times more functionality than JSP ever could..."

     See JSR 127
    Java Server Faces on the way http://www.jcp.org/jsr/detail/127.jsp

    The following 8 design goals represent the focus of this proposal:

    Create a standard GUI component framework which can be leveraged by development tools to make it easier for tool users to both create high quality GUIs and manage the GUI's connections to application behavior.

    Define a set of simple lightweight Java base classes for GUI components, component state, and input events. These classes will address GUI lifecycle issues, notably managing a component's persistent state for the lifetime of its page.

    Provide a set of common GUI components, including the standard HTML form input elements. These components will be derived from the simple set of base classes (outlined in #1) that can be used to define new components.

    Provide a JavaBeans model for dispatching events from client-side GUI controls to server-side application behavior.

    Define APIs for input validation, including support for client-side validation.

    Specify a model for internationalization and localization of the GUI.

    Automatic generation of appropriate output for the target client, taking into account all available client configuration data, such as browser version, etc.

    Automatic Generation of output containing required hooks for supporting accessibility, as defined by WAI.


    This JSR is viewed as synergistic with the JSP Standard Tag Library project (JSPTL, JSR-052), as JSPTL does not include GUI-related APIs.

    Additionally, work continues in the W3C to evolve relavent web technologies (XHTML, XForms) and the expert group will track these efforts to ensure the proposed specification includes enough flexibility to evolve with these technologies as needed.

    See XForms:
    http://www.w3c.org/MarkUp/Forms/
    http://www.w3c.org/TR/2002/WD-xforms-20020118

    The XForms User Interface provides a standard set of visual controls that are targeted toward replacing today's XHTML form controls. These form controls are directly usable inside XHTML and other XML documents, like SVG. Other groups, such as the Voice Browser Working Group, may also independently develop user interface components for XForms.

    An important concept in XForms is that forms collect data, which is expressed as XML instance data. Among other duties, the XForms Model describes the structure of the instance data. This is important, since like XML, forms represent a structured interchange of data. Workflow, auto-fill, and pre-fill form applications are supported through the use of instance data.

    Finally, there needs to be a channel for instance data to flow to and from the XForms Processor. For this, the XForms Submit Protocol defines how XForms send and receive data, including the ability to suspend and resume the completion of a form.

    Key Goals of XForms

    Support for handheld, television, and desktop browsers, plus printers and scanners
    Richer user interface to meet the needs of business, consumer and device control applications
    Decoupled data, logic and presentation
    Improved internationalization
    Support for structured form data
    Advanced forms logic
    Multiple forms per page, and pages per form
    Suspend and Resume support
    Seamless integration with other XML tag sets
  9. "See JSR 127 Java Server Faces..." -- Sergey

    Java Server Faces is *not* a departure from DHTML.
  10. Java server faces in JSP 2.0?[ Go to top ]

    So are you saying Java Server Faces part of JSP 2.0?
  11. Java server faces in JSP 2.0?[ Go to top ]

    No, JSF are not part of jsp20.
    jsp20 is "perl"ation (sic) of
    jsp, aparently for good...

    [there is a mistake in naming
    closing tag for c:if, must be c:fi]

    jsp20 is also
    -i118,
    -number ,date formatting,
    -regex

    AV
  12. Java server faces in JSP 2.0?[ Go to top ]

    Alex,

    Your information is incorrect.

    Some things you mention are not part of JSP 2.0, and are not even part of JSTL 1.0. For instance, a taglib for regular-expression matching is NOT part of JSTL or JSP 2.0; there's one offered by the open-source Jakarta Taglibs project, but that has nothing to do with JCP standards.

    JSTL 1.0 introduces tags for control flow (that is, logic and looping), i18n, XML manipulation, and database access (the latter of which is useful primarily for small to medium-sized applications and prototyping). It also introduces an expression language to help you specify access objects, request parameters, and other commonly used data with these tags.

    JSP 2.0 lets the JSTL expression language be used in non-JSTL tags as well as template text. It also introduces the ability to develop tags using JSP itself (instead of Java), which will simplify code reuse for nonprogrammers or page authors. It adds a number of other features too, like support for JSR-45's non-Java-code debugging.

    Before criticizing a standard, it's often very useful to familiarize yourself with it. I've spoken with many users who were initially skeptical but ended up finding JSTL very useful once they read the standard and experimented with it.

    --Shawn
    JSTL implementation lead
    Author, "JSTL in Action" http://www.jstlbook.com
  13. Java server faces in JSP 2.0?[ Go to top ]

    Shawn Bayern wrote: "I've spoken with many users who were initially skeptical but ended up finding JSTL very useful once they read the standard and experimented with it. "

    Hi Shawn!
    Don't worry - you did great job - JSTL is really very useful. I hope in future releses it will contain more and more features, perhaps, some of them will migrate from Jacarta TagLib project (such as security related - isUserInRole, isSecure, etc).

    Sergey

  14. Java server faces in JSP 2.0?[ Go to top ]

    Sergey - thanks for the support! :)

    As for your suggestions - I think JSTL will (expand in features, that is). JSP 2.0's addition of expression-language functions gives JSTL another way to implement extra functionality like this. For instance, I wouldn't be surprised if JSTL 1.1 contains an isUserInRole() function. (This might be easier to use than a '<c:ifUserIsInRole>' tag.) As for isSecure(), you can actually get this in JSTL today (that is, JSTL 1.0) using the expression language:

    <c:if test="${pageContext.request.secure}">
      Phew, the request is secure!
    </c:if>

    I'm glad you enjoy JSTL; please always feel free to let us know of suggestions you have by mailing the expert group at jsr-52-comments at jcp dot org. Best,

    --Shawn Bayern
    JSTL reference-implementation lead
    Author, JSTL in Action
  15. Java server faces in JSP 2.0?[ Go to top ]

    Shawn Bayern wrote: "Sergey - thanks for the support! :)"
    You're welcome! :)

    "As for isSecure(), you can actually get this in JSTL today..."

    I know, expression language is really powerful, I just lazy to write such long expression :)


    Sergey Litsenko

    Senior software engineer,
    LG Industrial Systems


  16. Java server faces in JSP 2.0?[ Go to top ]

    Shawn,

    yes... I mix struts-1.1, jstl-1.0 and jsp-2.0.
    You are right, regex is in oro and struts.

    I am not criticizing any of these. I just
    pointed out that jsp20 is going "perl"ish way.

    May be next step will be direct assign like:
    ${someBean.someAttr = status.counter + 23}
    instead of c:set ?

    What do you thing about JSF ? where it will
    fit in this picture?

    Thanks in advance for any info.

    Alex.
  17. Java server faces in JSP 2.0?[ Go to top ]

    Faces may indeed use the JSP 2.0 expression language for assignment.

    When you say "Perl-ish," I assume you refer to the typeless nature of the expression language...? If so, we've been careful to ensure that this doesn't introduce some of Perl's problems. Also, we've considered the addition of a standard <jsp:declare> tag to restore type safety (for the benefit of translation-time validation when possible, and tool support in general) when it's desired. Note that JSTL and JSP 2.0 don't lack type safety in the traditional sense; there are just a handful of implicit conversions that are supported (e.g., Object -> String) for the benefit of simplicity. This is more on par with Java's implicit call to toString() for the "+" operator than Visual Basic's "variant" type.
  18. Java server faces in JSP 2.0?[ Go to top ]

    Hello Shawn,

    Thanks for answers (here and in c.l.j.p)

    > When you say "Perl-ish," I assume you refer to the
    > typeless nature of the expression language...?

    yes, type-safety and introduction of
    possibility to write non-presentational
    logic were my concerns.

    It is good that type-safety is still
    a priority. Also i18n+formatting+defaults
    +parametrized messages in jstl are great.

    But value of sql tags and possible
    security tags/functions is less obvious.

    In good architecture,
    sql, security, flow and similar belongs to
    controller, model and to lower layers.

    Thus, introduction of non-presentational tags
    and functions must be accompanied with
    "best practise" discussion
    (similar to your note about
    "sql tags = fast prototyping").

    Have a nice day.

    Alex.


  19. Java server faces in JSP 2.0?[ Go to top ]

    In good architecture,

    >sql, security, flow and similar belongs to
    >controller, model and to lower layers.

    I totally agree with you about SQL and flow.

    However i believe there can be presentation logic related to security in a jsp: say we have an administration web application which shows a list of products which can be "crud" and one formular for all these actions : checkboxes for each line of the list + a delete button, a create button and a modify button.

    Say the application defines a certain amount of roles: administrator, assistant, supervisor etc...

    It is usefull to have a tag printing out the buttons that are associated to the roles of the current user. Something like this:

    <drobin:security roles="administrator">
      <input type="submit" value="delete"/>
    </drobin:security>
    <drobin:security roles="administrator, supervisor, assistant">
      <input type="submit" value="create"/>
    </drobin:security>

    Of course a second security check is done in the controller when the actual command is executed.
  20. Java server faces in JSP 2.0?[ Go to top ]

    Hello Thierry,

    My point is that some <xxx:security...>
    tag can go [for example] to database to check for
    isInRole, causing possibility of
    application and system exceptions.

    IMHO, jsp is THE last process layer
    and it is NOT supposed to go back to
    persistance, business and even flow
    control layers. Controller and model
    are responsible for security.

    So it must
    be simple "roles" or "power" attribute
    in appropriate scope that is set BEFORE
    arriving to jsp. This switch can be used
    by jsp [for example] to show or not to
    show "delete" button.

    AlexV.
     
  21. Java server faces in JSP 2.0?[ Go to top ]

    I just want to know the reason we need to use the JSTL Expression Language (EL) to access variable. I think the <%= %> will just do fine and also easy to type. Personally, I think the introduction of EL to JSP makes the JSPs more difficult to read and the learning curve will be deeper for new developers. I believe there must be some good reasons to have the EL but may be I do not have enough knowledge about the web development to understand it.

    Any comment and laugh :-) are welcome!

    Edmund
  22. Java server faces in JSP 2.0?[ Go to top ]

    Hi Edmond,

    Looks like ${someBean.abcd} is much more
    condence and robust than <%=java%> option.
    ${...} automatically search scopes, calls
    getters on attributes and collections,
    and something else...

    Personally, I like what I see now,
    but there is always a tradeoff.
    Here : condence vs new learning

    In fact, jsp2.0
    introduce NEW language inside ${....}.
    Today there are plus-minus and functions,
    tomorry it will be assigments, power and
    root operator, keyword "new",
    (or, may be, tag <c:declare>), "if", "foreach"

    Without any irony, may be java can bring in
    some existing language? Why knows some
    type-safe but simple scripting language?

    Alex.
  23. Java server faces in JSP 2.0?[ Go to top ]

    "In fact, jsp2.0
    introduce NEW language inside ${....}.
    Today there are plus-minus and functions,
    tomorry it will be assigments, power and
    root operator, keyword "new",
    (or, may be, tag <c:declare>), "if", "foreach" "

    I agree to a certain point with this argument, *but* ;) the real point about the "new" jstl languages seems to be that it should resemble ordinary ecmascript. As many [visual,front-end?] webdevelopers already know javascript but maybe not java, this is IMO a good idea? :)

    And *no*, no declaration, nor any if, foreach statements in the language (as those should be handled by tags)
  24. Java server faces in JSP 2.0?[ Go to top ]

    Indeed, the goal of the expression language is remain an *expression* language. It will never conduct assignments or full Java-like statements on its own. (A technology may use it for assignments by treating the result of an expression as an effective lvalue -- that's all.)

    Its goal is to simplify the retrieval of scoped variables, request parameters, context-initialization parameters, and other commonly used objects without requiring that Java be introduced into a JSP page just in order to do so.
  25. Goals for Faces are great. But where they (Faces) are?
    For GUI related tasks you can use right now TICL
    See www.kobrix.com Very nice stuff! And answers to declared Faces goals by the way.

    As per general purposes tags discussed here you can use Coldtags
    See www.servletsuite.com/jsp.htm. Anyway this taglib is bigger that any
    existing set (including JSTL) and growing weekly.

    As per JSTL goals I do not understand (of course, my opinion only, although being shared with many
    co-workers) their directions at all. Why do they think that &#8220;perl&#8221; style is good? If we have one language (Java) already why do weed the second? At the end of the day the first J in JSP means Java.

    We are consulting doing .NET stuff also. And I can say that by our estimation current trend is not good for JSP. An opposite equivalent (ASP.NET) actually lets programmers to create pages much faster. And the amount of tags (components) for this platform is really big even right now. Keep in mind that the platform itself is very young. At the end of the day Java lost desktops development due to lack of equivalent Javabeans against the unbounded set of VB ActiveX etc. Right now we see the same for ASP.NET vs. JSP game. It would be better for me to be wrong here, but ...

    We are trying to monitor all taglibs development in order to have a weapon against ASP&#8217;s. And we see
    that the core Java initiatives (excluding third parties) are concentrating on very useless (of course IMHO again) directions like flows and so on, rather than answering to the business needs.

    Eugene

    P.S. any dates for Faces release?

  26. Eugene wrote:
    "As per JSTL goals I do not understand (of course, my opinion only, although being shared with many
    co-workers) their directions at all. Why do they think that &#8220;perl&#8221; style is good? If we have one language (Java) already why do weed the second? At the end of the day the first J in JSP means Java."

    It's not a stated goal of JSTL to make JSP more like Perl; that's something that Alex just made up :), and as I wrote, I disagree with the characterization.

    JSTL's goal is to remove the need for program code -- yes, including Java code -- from JSP pages. Such code is generally regarded as being poor for maintainability and abstraction.

    JSP 2.0 introduces the ability to develop tags using JSP's own language. ASP.NET doesn't provide anything like this. In fact, most ASP.NET Server Controls tend to wrap or associate with HTML elements; this is also potentially dangerous from the perspective of abstraction.

    The JSTL standard is very readable; I suggest you download it from http://java.sun.com/products/jstl before passing judgment.

    -- Shawn Bayern
    JSTL reference-implementation lead
    Author, JSTL in Action
  27. JSTL's goal is to remove the need for program code -- yes,

    >including Java code from JSP pages.
    As seems to me it is a goal for any taglib, is not it?

    >JSP 2.0 introduces the ability to develop tags using JSP's
    >own language. ASP.NET doesn't provide anything like this.
    Sorry, it does.

    >In fact, most ASP.NET Server Controls tend to wrap or
    >associate with HTML elements;
    >this is also potentially dangerous from the perspective of >abstraction.
    Core tags &#8211; yes. They are just .NET similarities for HTML controls. But the problem for us that they (MS, ASPs) do not stop here :) Or shall I use :( here as a Java developer?

    >The JSTL standard is very readable; I suggest you download
    >it from http://java.sun.com/products/jstl before passing
    >judgment.
    We did of course. Otherwise how can I compare.
  28. ">JSP 2.0 introduces the ability to develop tags using JSP's
    >own language. ASP.NET doesn't provide anything like this.
    Sorry, it does. "

    It would be interesting to here how ASP.NET solves this? Then its easier to discuss the different approaches!

  29. The wingS project (http://wings.mercatis.de) is a today show of this approach. It´s impressive. JSP should have seen it before developing the standard.


  30. Sorry, a mistake, I talk about Java Server Faces not JSP.


  31. Jose María Arranz wrote "The wingS project (http://wings.mercatis.de) is a today show of this approach"

    It looks really good.
    However, some basic features are too slow - unfortunately :(