Home

News: Pre-JCP-filed draft for JavaServer Faces 2.0 JSR

  1. Ed Burns has posted a reference to the proposal for JSF 2.0 on his blog. The proposal focuses on ease of development (no config XML files), the use of templates, bookmarkable urls, and many more elements, including REST and AJAX usage in JSF. They're also focusing on ease of deployment, meaning that components should be "hot-deployable." The drivers for JSF 2.0, from the proposal:
    2.5 What need of the Java community will be addressed by the proposed specification? While JavaServer Faces has succeeded in becoming the standard way to build web application user interfaces while ensuring maximum container portability and minimizing vendor lock-in, the state of the art of web application user interface development has advanced significantly since the first major droft of the specification. The Java community finds itself in a similar situation to that in which the first version of the JavaServer Faces specification was initiated: Many great ideas but no standard specification that delivers them to developers and the marketplace. In fact, many of these great ideas are built on top of the JavaServer Faces Specification but, are not, themselves, standards. It is time to harvest these ideas and bring them to a wider audience in manner consistent with the rest of the Java Platform.
    This is aimed at Java EE 6, so it's likely to be quite some time - the initial proposal suggests March of 2008. If you're interested in JSF becoming a more viable standard, feel free to contribute to this JSR. Whether you're a JSF supporter or not, JSF is here to stay, and there's no point in not being part of it - even if your opinion is that it should go the way of JDO and become a static specification from the JCP's point of view.

    Threaded Messages (40)

  2. Huh?[ Go to top ]

    While JavaServer Faces has succeeded in becoming the standard way to build web application user interfaces while ensuring maximum container portability and minimizing vendor lock-in
    That is a silly statement
  3. Whether you're a JSF supporter or not, JSF is here to stay, and there's no point in not being part of it
    On a similar note, even if you disagree with the war in Iraq you should still support the president, right? The goals listed for JSF sound great. That's mostly because they are cherry-picked from more innovative projects. For example, the use of annotations and zero-XML configuration is something already seen in Stripes. Tying into JPA? Sounds a lot like Seam. Make it easy to create CRUD apps? Sounds a lot like Grails (which is inspired by Rails of course.) Moving more of the controller bits to the client sounds a lot like GWT. The problem is that by the time JSF gets around to all this, there will be new innovations out there.
  4. BEA JEE5 Released[ Go to top ]

    There have been some comments about the lack of major vendor support for JEE5. BEA WebLogic Server 10 is now GA and is fully JEE5 compliant. You can download the final version as of today, although a tech preview that passed JEE5 certification has been available for awhile. James Bayer BEA Systems
  5. What the deal with JDO?[ Go to top ]

    The goals listed for JSF sound great. That's mostly because they are cherry-picked from more innovative projects. For example, the use of annotations and zero-XML configuration is something already seen in Stripes. Tying into JPA? Sounds a lot like Seam. Make it easy to create CRUD apps? Sounds a lot like Grails (which is inspired by Rails of course.) Moving more of the controller bits to the client sounds a lot like GWT.

    The problem is that by the time JSF gets around to all this, there will be new innovations out there.
    This is actually good. Real developers need a well aligned combination of innovation and stability. I do agree with many of others that JSF is superior, bat far from perfection. We need one more step. And I do not get what the deal with JDO.
  6. Re: What the deal with JDO?[ Go to top ]

    And I do not get what the deal with JDO.
    Me neither. What is a "static specification" ? JDO 2.1 is being developed and implemented. JDO 2.x takes ORM to a level higher than any other current specification. Perhaps it was just an editorial comment that can be categorised in the "personal opinion" section and best ignored.
  7. Whether you're a JSF supporter or not, JSF is here to stay, and there's no point in not being part of it

    On a similar note, even if you disagree with the war in Iraq you should still support the president, right?

    The goals listed for JSF sound great. That's mostly because they are cherry-picked from more innovative projects. For example, the use of annotations and zero-XML configuration is something already seen in Stripes. Tying into JPA? Sounds a lot like Seam. Make it easy to create CRUD apps? Sounds a lot like Grails (which is inspired by Rails of course.) Moving more of the controller bits to the client sounds a lot like GWT.

    The problem is that by the time JSF gets around to all this, there will be new innovations out there.
    Isnt that the goal of a spec, a spec should not be state of the art, but one step behind, because, then you can use patterns which work best. Sorry to say that but if you go the spec route then you are more or less on the save side, if you dont, you will get the latest toys. btw. one of the things you listed here already is heavily jsf based (Seam)
  8. The goals listed for JSF sound great. That's mostly because they are cherry-picked from more innovative projects. For example, the use of annotations and zero-XML configuration is something already seen in Stripes. Tying into JPA? Sounds a lot like Seam. Make it easy to create CRUD apps? Sounds a lot like Grails (which is inspired by Rails of course.) Moving more of the controller bits to the client sounds a lot like GWT.

    The problem is that by the time JSF gets around to all this, there will be new innovations out there.
    Sure. That's the nature of standards. JSF is a spec, not a product. The best we can do is ensure that it's a good spec which incorporates as many current innovations as possible. There will always be something else out there that's doing something different and innovative. Hopefully, we'll be able to incorporate those innovations in the next rev of the spec. --- Kito D. Mann - Author, JavaServer Faces in Action http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info
  9. Sure. That's the nature of standards. JSF is a spec, not a product. The best we can do is ensure that it's a good spec which incorporates as many current innovations as possible.
    The problem is that unlike JSP, which started as a product and then became a spec, JSF started as a spec from day 1.
  10. Sure. That's the nature of standards. JSF is a spec, not a product. The best we can do is ensure that it's a good spec which incorporates as many current innovations as possible.


    The problem is that unlike JSP, which started as a product and then became a spec, JSF started as a spec from day 1.
    Not quite true, JSF started as a product from Oracle and then became a spec.... (Ok the original Oracle framework didnt have too much in common with the final 1.0 jsf specs, but nevertheless, the origins are there.)
  11. Werner, that's simply not true. And as the Oracle rep on the JSF EG from day one, I'd know... I'm assuming you're talking about UIX here. While I do know that some of the ideas in UIX did make it into JSF (named children became facets) or are analogous (BoundValues are like ValueBindings), JSF in no way started as UIX.
  12. Werner, that's simply not true. And as the Oracle rep on the JSF EG from day one, I'd know... I'm assuming you're talking about UIX here. While I do know that some of the ideas in UIX did make it into JSF (named children became facets) or are analogous (BoundValues are like ValueBindings), JSF in no way started as UIX.
    Ok then sorry for this, It was sort of a misunderstanding from my side, I was talking about UIX... thanks a lot for the clarification.
  13. 1+ vote[ Go to top ]

    This is SILLY statement

  14. Looks very interesting and it seems to address many of the gripes of JSF. The only problem is that we need this now, latest in a few months. Waiting another year just for the spec is a lifetime in the field of web development.
  15. Looks very interesting and it seems to address many of the gripes of JSF.

    The only problem is that we need this now, latest in a few months. Waiting another year just for the spec is a lifetime in the field of web development.
    I agree, this needs to be handled more quickly. It would be much nicer to see this in a JEE 5.1 release, rather than waiting until JEE 6. The unfortunately reality is that JEE 5 has been out for a year, and yet it is still only supported in a released form by one or two small niche players. If the spec doesn't even make it out until 2008, this won't make it into the real world until 2010! :(
  16. The unfortunate reality is that JEE 5 has been out for a year, and yet it is still only supported in a released form by one or two small niche players. If the spec doesn't even make it out until 2008, this won't make it into the real world until 2010! :(
    Hmm. Niche players... Sun? SAP? Also, the "other" niche players like BEA, Geronimo, JBoss are likely to have Java EE compliant servers out fairly soon.
  17. Also, the "other" niche players like BEA, Geronimo, JBoss are likely to have Java EE compliant servers out fairly soon.
    Which aspect of JEE 5 is not supported by JBoss 4.0.5? This is news to me as I'm using it right now for EJB 3.0 and JPA. I've been a long-time loyal Tomcat user, but with EJB 3.0 showing so much potential, my team is actually seriously considering moving my employer's production applications to a full JEE server with our next upgrade cycle. We've already deployed a few applications using JSF and found that it is superior to competing specs, but still had a lot of room for improvement.
  18. Which aspect of JEE 5 is not supported by JBoss 4.0.5? This is news to me as I'm using it right now for EJB 3.0 and JPA.

    I've been a long-time loyal Tomcat user, but with EJB 3.0 showing so much potential, my team is actually seriously considering moving my employer's production applications to a full JEE server with our next upgrade cycle. We've already deployed a few applications using JSF and found that it is superior to competing specs, but still had a lot of room for improvement.
    The last time I used JBoss 4.x, which, admittedly was a long time ago (we're a GlassFish shop now), JBoss' EE 5 implementation in the 4.x product was using a non-final version of the spec, so certain things like, iirc, jar file names in the ear, library file locations, remote session bean names, etc were not compliant with the final spec. So, in my experience, it wasn't that things weren't supported, necessarily, but that the support was not compliant with the final spec. Granted, that was probably almost a year ago, and I quit following JBoss compliance when we decided to run with GlassFish, so things have likely changed. JBoss AS 5 should fix any remaining issues.
  19. and found that it is superior to competing specs
    exactly what competing specs are you speaking about ? :)
  20. competing specs[ Go to top ]

    exactly what competing specs are you speaking about ? :)
    I'd compare JSF to the various Open Source web frameworks that are presently "fashionable." I think Struts and Spring WebFlow are the current leaders. I've personally done several struts projects while others I work with are experts in WebFlow. We've all concluded that JSF is a better choice, especially considering the wealth of readily available AJAX widgets, such as those offered by IceFaces, RichFaces, and a few Tomahawk components that are so easily integrated into your application. I don't think JSF is even close to perfection, but it's far superior too the frameworks I've worked with in the past. In fairness, I consider JSF superior due to it's wide support from many vendors and rich widgets rather than its inherent design. I am not intimately familiar with the inner workings of all of the competing specs, but I am pretty confident that at this exact moment in time, they cannot match JSF (especially with seam and the 3rd-party AJAX widgets). However, I concede that my research on a half-dozen or so alternatives was relatively shallow, consisting of reading sample code, tutorials, and whitepapers rather than actually writing a full application with the technology.
  21. Re: competing specs[ Go to top ]

    Struts and spring webflow are not specifications and on top of that, they are not even component frameworks. they are front controller frameworks. An apples to apples comparison would be jsf - tapestry or jsf - wicket. Btw. spring webflow is only used for flow logic. Even the authors don't recommend writing your entire application with it.
  22. Re: competing specs[ Go to top ]

    Struts and spring webflow are not specifications and on top of that, they are not even component frameworks. they are front controller frameworks. An apples to apples comparison would be jsf - tapestry or jsf - wicket. Btw. spring webflow is only used for flow logic. Even the authors don't recommend writing your entire application with it.
    But you also mix ton of stuff here : Jsf and I believe Tapestry and Wicket are also front controller based, check out the JsfServlet. The fact that a component abstraction exists doesn't disallow the use of a front controller. About Spring web flow, you are like a lot of people confusing the input controller as the C in MVC and the application controller which according to fowler books are two very different beasts. Spring Web Flow is used to implement the applications controller not the input controler even though most of the time the input controller only delegate to the application controler but the fact remains : you still need an input controller. Hence web flow prove some integration layers to be able to plug in with most of the different MVC frameworks out there.
  23. Re: competing specs[ Go to top ]

    Struts and spring webflow are not specifications and on top of that, they are not even component frameworks. they are front controller frameworks. An apples to apples comparison would be jsf - tapestry or jsf - wicket. Btw. spring webflow is only used for flow logic. Even the authors don't recommend writing your entire application with it.


    But you also mix ton of stuff here :

    Jsf and I believe Tapestry and Wicket are also front controller based, check out the JsfServlet.
    I mean FacesServlet...
  24. concepts[ Go to top ]

    Jsf and I believe Tapestry and Wicket are also front controller based, check out the JsfServlet.
    I mean FacesServlet...
    of course all these frameworks have some technical mechanism to integrate with the underlying servlet technology, and you may call that a front controller if you choose. The significant point is however, that this mechanism, and thus most of the "controller" concepts mentioned here, are at a much lower level of abstraction than the metaphors used by frameworks like JSF, Tapestry and Wicket (where I really hesitate to include JSF). The latter are event- and object-oriented, while I would call the former request- or action-oriented.
  25. Re: concepts[ Go to top ]

    Jsf and I believe Tapestry and Wicket are also front controller based, check out the JsfServlet.
    I mean FacesServlet...

    of course all these frameworks have some technical mechanism to integrate with the underlying servlet technology, and you may call that a front controller if you choose.

    Yes I call this a front controller because it is exactly one according to the pattern : a single point in charge of handling the request and dispatching the treatment to the corresponding event handler. In fact, the only difference between a front controller and a page of servlet is that in the case of a front controller there is only one servlet handling all the different requests while in a page controller application, you have usually one servlet for one type of request. So all the frameworks using only one servlet as a single point entry are front controller based and therefore it's wrong to pretend JSF as I have seen many times is not based upon the front controller pattern.
    The significant point is however, that this mechanism, and thus most of the "controller" concepts mentioned here, are at a much lower level of abstraction than the metaphors used by frameworks like JSF, Tapestry and Wicket (where I really hesitate to include JSF). The latter are event- and object-oriented, while I would call the former request- or action-oriented.
    It has nothing to do with the front controller pattern and that's my point. In all those frameworks, maybe it be Struts, Spring MVC, JSF, Tapestry, Wicket, ... there is only one place where is the request first handled (one servlet) : the front controller. After that the controller dispatch to the correct event handler. In action oriented frameworks the events are not fine grained and so map to request events while in a component based framework they map to component events in a more fine grained fashion. Even if the nature of the events is different in those two frameworks, it doesn't change the facts that it is the front controller job to dispatch to the correct handler. You can't say JSF is not front controller oriented even though it used a component metaphor. The front controller pattern just states that a central point handles and dispatch all the request, that's all. I understand that the OP wanted to distinguish action and component oriented frameworks but the terminology wasn't right at all and confusing. I just wanted to correct it. Other than that, I agree those kind of frameworks are very different.
  26. Hmm. Niche players... Sun? SAP?

    Also, the "other" niche players like BEA, Geronimo, JBoss are likely to have Java EE compliant servers out fairly soon.
    Yep, Sun has little market share (though their leadership in getting JEE 5 support via Glassfish has helped), and SAP isn't exactly a big player in the market for JEE server (aside from the people who run SAP, obviously). Weblogic, Websphere, and JBoss are the big players, and none of those have released final JEE 5 implementations. I think they will have them fairly soon, too, though. It's just that fairly soon will be closer to the end of this year (1.5 years after spec)!
  27. The unfortunate reality is that JEE 5 has been out for a year, and yet it is still only supported in a released form by one or two small niche players. If the spec doesn't even make it out until 2008, this won't make it into the real world until 2010! :(
    Hmm. Niche players... Sun? SAP?

    Also, the "other" niche players like BEA, Geronimo, JBoss are likely to have Java EE compliant servers out fairly soon.
    Yep, frankly, in J2EE server market, SUN is... niche. SAP is almost exclusivelly tied to SAP product portfolio. Frankly i've never seen company using NetWeaver without having, before, SAP installed. Even they have SAP, they use NetWeaver as a SAP addition, serving J2EE applications on IBM, BEA, Oacle etc... What about BEA, IBM, JBOSS or Oracle? They are in 'prevew' stage still. Artur
  28. See BEA above[ Go to top ]

    They apparently have it in GA, and with JBoss due out in late April (my bet on Red Hat's announcement for middleware that Szulik alluded to the other day), you have well over 50% of the Total App Server market. Oralce and SAP basically have the same JEE effort, unless you think OC4J has any independent market share, which I can't believe they would. BEA and IBM are essentially locked in a tie for enterprise deployments. And JBoss certainly makes up for Geronimo's delay. You would have to be completely locked in to the app server vendor if you didn't at least test out JEE5, which is certainly possible, but then, wouldn't you look in to an evolution of the spec. to see if you can become less locked-in?
  29. My other concern is that JSF is still pretty much competing with .Net at the ASP.Net level. The new buzz is WPF in .Net 3.0 and frankly speaking right now Java has nothing comparable to that. And don't tell me applets could do it. They've been dead long enough. I've seen WPF demos done here at work by my colleagues in the .Net team and I hope someone at Sun isn't asleep at the wheel and coming up with something that can compete with that level of eye-candy. It makes quite the initial impression. http://en.wikipedia.org/wiki/Windows_Presentation_Foundation
  30. My other concern is that JSF is still pretty much competing with .Net at the ASP.Net level.

    The new buzz is WPF in .Net 3.0 and frankly speaking right now Java has nothing comparable to that.
    Maybe I'm missing something, but that sounds a lot like Java Web Start. "A WPF application can be deployed on the desktop or hosted in a web browser." Sure there might be some differences -- I don't know .Net or WPF well enough (read: at all) -- but it sure sounds at least *similar* to JWS.
  31. My other concern is that JSF is still pretty much competing with .Net at the ASP.Net level.

    The new buzz is WPF in .Net 3.0 and frankly speaking right now Java has nothing comparable to that. And don't tell me applets could do it. They've been dead long enough.

    I've seen WPF demos done here at work by my colleagues in the .Net team and I hope someone at Sun isn't asleep at the wheel and coming up with something that can compete with that level of eye-candy. It makes quite the initial impression.

    http://en.wikipedia.org/wiki/Windows_Presentation_Foundation
    you are comparing apples and oranges with respect to JSF 2.0. it's like saying ASP.NET and WPF are one and the same thing-- I'd like to see JSF 2.0 do a better job of facilitating technologies from Adobe or other rich clients, but if you want something to compete with WPF, then bark at the swing folks.
  32. Yes, but MS is pushing WPF as the "new" way to do web development as well (since WPF apps can be deployed either in the browser or stand-alone). I just hope someone at Sun is paying attention to it as a competitive threat and figuring out which parts of the Java stack (be it Swing, applets or JSF) that need to be enhanced to have a compelling alternative.
  33. Yes, but MS is pushing WPF as the "new" way to do web development as well (since WPF apps can be deployed either in the browser or stand-alone).

    I just hope someone at Sun is paying attention to it as a competitive threat and figuring out which parts of the Java stack (be it Swing, applets or JSF) that need to be enhanced to have a compelling alternative.
    So you can either launch an application as a standalone application (like JWS) or within the browswer (like an Applet). I'm bet the "features" with which Java needs to compete are: 3. Only really works on Windows (and recent versions at that) 2. Weak-by-default security model 1. It's made by Microsoft. Of course those items translate into better user experience for 90% of computer users. Maybe with Java under the GPL MS will take another crack an "innovating" with Java.
  34. So you can either launch an application as a standalone application (like JWS) or within the browswer (like an Applet).
    No, that's not a Java equivalent of WPF. A Java equivalent would be design an application using JSF (you can pick something else here if you like, but this whole was on JSF), and then being able to compile-deploy into either a web application that renders HTML/CSS/JS or a desktop application with the same functionality plus the ability to work offline. Take things a step further and you can also compile/deploy your application to mobile devices. I don't think WPF has quite made it to that goal, yet. You can go download MS Expression Blend and get an app that will create the UI in XAML. Thus it could theoretically be rendered as a web app in HTML, but I don't think they have anything that will do that just yet. Maybe Orcas (next-generation of Visual Studio) will have (or already does, it's in beta right now) this capability. I actually don't think this is too far from the original design of JSF. That being said, I think the Java community is making the right choice to pursue advancing web development technologies instead of trying to compete with WPF. Adobe has gone the other way and is trying to compete with WPF via their new product Apollo.
  35. Rather than Sun being asleep at the wheel, I think it's the Java team in your organization that has got fat and is in deep slumber. Seriously, STOP scavenging open source and do some work for yourself. Youl'll wow everybody not just windows users. Webstart + Swing(or SWT) + HTTP will swallow up WPF effortlessly. It's not vaporware which WPF still is.. atleast the cross-platform part. Try it, you'll be pleasently surprised.
  36. Who cares ?[ Go to top ]

    This may be fine if you develop just another MS fanboy site because it probably runs only on Windows, requiring IE - perhaps even IE7 and some Vista "uber" edition. For everything else it's even more retarded than doing a whole site in flash (at least every OS has a flash plugin). Therefore I don't consider this as important as long it isn't platform independent as well as vendor independent.
  37. Most of it is already possible[ Go to top ]

    Most of the mentioned stuff is already possible with JBoss Seam! E.g.: ease of development (no config XML files); after writing some initial configuration files in xml one doesn't need to write more of it because Seam uses annotations the use of templates: I'm fine with facelets although some stuff is missing, i.e. https://facelets.dev.java.net/issues/show_bug.cgi?id=202 (<- vote for it plz ;)) bookmarkable urls, and many more elements, including REST and AJAX usage in JSF: REST is possible with Seam page actions. AJAX4JSF i.e. for AJAX integration or Icefaces, ... They're also focusing on ease of deployment, meaning that components should be "hot-deployable.": This is at least partly possible since the 1.2.1 release. With Seam probably being for the WebBeans JSR what Hibernate is for JPA and WebBeans & JSF working hand in hand and the facelets, ... integration I have high hopes :D
  38. I like to see those people he mentioned join the jcp, amongst others , facelets as standard view technologie, integeration with web beans jsr, some sort of standard way that ide’s can incorporate other components (ie icefaces and other third party components), line precise error reporting (facelets already does this), better page flow support, some sort standard templating (facelets already does this too), better standard components, tighter integration with ejb3/JPA (seam style). Many of these can be done now, maybe just a matter of standardization.
  39. JavaServer documentation[ Go to top ]

    on thing I really think they need to improve on is the API/Tag library documentation. I have never seen anythin as bad as the stuff that comes with JSF (see http://java.sun.com/javaee/javaserverfaces/1.2/docs/tlddocs/index.html). Just have a look at the simplest of all examples, the docs for the f:verbatim tag:
    Create and register a child UIOutput component associated with the closest parent UIComponent custom action, which renders nested body content
    This IMO carries absolutely NO immeiately usable information for the end user, who should be the prime audience for this text. In fact most of the docs read like a low-level JSF implementation spec. The fact that this has gone so little noticed demonstrates to me how little the technology is actually being used.
  40. Re: JavaServer documentation[ Go to top ]

    on thing I really think they need to improve on is the API/Tag library documentation. I have never seen anythin as bad as the stuff that comes with JSF (see http://java.sun.com/javaee/javaserverfaces/1.2/docs/tlddocs/index.html). Just have a look at the simplest of all examples, the docs for the f:verbatim tag:

    Create and register a child UIOutput component associated with the closest parent UIComponent custom action, which renders nested body content

    This IMO carries absolutely NO immeiately usable information for the end user, who should be the prime audience for this text. In fact most of the docs read like a low-level JSF implementation spec.

    The fact that this has gone so little noticed demonstrates to me how little the technology is actually being used.
    Well what you linked is just basically the javadoc generated documentation, this is enough if you already know how to apply the tags. I agree Sun could work on beginners docs on their site, like they did with java in the early days. But I do not agree with the conclusion, there are lots of jsf users out there, you can see that at the traffic in the myfaces mailinglist, the main thing is, that most of them revert probably to other resources like http://www.jsfcentral.com/ ( a quick googeling towards jsf tutorial will also reveal links ), for their beginners documentation. All I can see is a lack of documentation for beginners on Suns site, but the documentation issue is not a problem of the core specification, more a problem on Suns part and could be fixed outside of a jsr. (and should be IMHO asap)
  41. Re: JavaServer documentation[ Go to top ]

    I dont know about everybody else, but I usually look at the javadoc comments for immediate usage tips, and I certainly dont expect to find stuff like the example below, which is from the javadoc for the h:message tag. "apalling" is the word that comes to my mind when I see this. Note that the formatting is exactly as in the original.
    Obtain the "summary" and "detail" properties from UIMessage component. If not present, keep the empty string as the value, respectively. Obtain the first FacesMessage to render from the component, using the "for" property of the UIMessage. This will be the only message we render. Obtain the severity style for this message. If the severity of the message is FacesMessage.SEVERITY_INFO, the severity style comes from the value of the "infoStyle" attribute. If the severity of the message is FacesMessage.SEVERITY_WARN, the severity style comes from the value of the "warnStyle" attribute, and so on for each of the severities, INFO, WARN, ERROR and FATAL. The same rules apply for obtaining the severity style class, but instead of "infoStyle, warnStyle", etc use "infoClass, warnClass", etc. Obtain the "style", "styleClass" and "layout" attributes from the UIMessage component. If we have a "style" attribute and a severity style attribute, use the severity style attribute as the value of the "style" attribute. If we have no "style" attribute, but do have a severity style, use the severity style as the value of the "style" attribute. The same precedence rules apply for the style class. Obtain the value of the dir and lang attributes