Improving JavaServer Faces by Dumping JSP

Discussions

News: Improving JavaServer Faces by Dumping JSP

  1. Improving JavaServer Faces by Dumping JSP (66 messages)

    There has been a lot of buzz about JavaServer Faces. Since its release, people seem to love it, or hate it. A lot of the hatred revolves around the JSP tags that you have to work with. Hans Bergsten shows us the flaws, and then shows us, what he thinks, is a better way.

    Conclusion
    I've tried to make a number of points in this article. First, be aware that the JSF JSP layer is flawed in many ways. Second, don't give up on JSF just because the JSP layer is flawed; using a custom ViewHandler resolves all of the issues, and at the core, JSF is a great technology for complex web application interfaces.

    Most importantly, I'm trying to build support for an alternative to JSP for a future version of the JSF specification. The JSR for JSP 2.1 focuses on bridging the gap between JSF and JSP. While good things may come out of this (like alignment of the two ELs), I don't see JSP ever becoming a good template language for JSF; JSP has a completely different purpose, and trying to "fix it" for JSF would likely just make it more complicated and less useful for simple, dynamic content. Instead, I hope to see experimentation with custom ViewHandler implementations in the open source community (for instance, within the MyFaces project, and maybe even within the Tapestry project) as well as in the corporate world. I hope that the best ideas from these efforts will be incorporated into a future version of the JSF specification as an official alternative to JSP.
    Read Improving JSF by Dumping JSP

    Threaded Messages (66)

  2. I think by extending Tapestry
    idea (adding new jwsid attribute to basic html tags)
    we may be able to drop the view specification xml file.

    For example instead of:

    <img id="guessesLeft" height="36" src="images/Chalkboard_3x8.png"
              width="36" border="0"/>

    And in addition:

    <view-specification>
      <component id="guessesLeft" type="javax.faces.Graphic"
        value="#{guessesLeftImages[visit.game.incorrectGuessesLeft]}" />
      ...
    </view-specification>

    we can use something like this:

    <img graphicId="#{guessesLeftImages[visit.game.incorrectGuessesLeft]}"
       height="36" src="images/Chalkboard_3x8.png" width="36" border="0"/>
  3. try echo.....[ Go to top ]

    i haven't see html or tags for over 2 years now. echo is like programming with a WT that simply lives in a servlet container. the best part, is that it's near zero configuration and there's NO SUCH THING AS A 'PAGE'. you basically create a model, and a servlet draws it. that is that application. the rendered model then has hooks that allow to you update the model and/or change it. that is navigation.

    quite nice.

    it's meant for applications. where tags and html is meant for documents that might try to change a little.

    not that anyone need share my opinion, but i see using tags/templates for applications one of those ideas that started of well enough but didn't stop when it's time came. WTs are tried and true for applications.
  4. try echo.....[ Go to top ]

    Sorry everyone for this off topic question but ...

    JP - I am using it on a project now. (Been looking at it for a while and did one minor thing with it before) How has performance and scalability been for you? What size projects have you use it on? Number of users?

    The programming paradigm is excellent (cause I can create a Swing GUI almost from the same code). If we gotta take this off line, let me know and I will provide an email address.
  5. try echo.....[ Go to top ]

    Echo has a large collection of components available (commercial and OSS), and it does resemble Swing code, however Webonswing is Swing code. Have a look at the demos on the Webonswing site and you see how a GUI can be developed using your favourite Swing IDE and then viewed using the Webonswing framework thru a servlet container.
  6. Echo has a large collection of components available (commercial and OSS), and
    > it does resemble Swing code, however Webonswing is Swing code.

    I don't want to belittle Echo but using the Swing API as the role model for future web development is a little off track. The Swing API is a case study on how *not* to do. The future belongs to next-gen markup languages and scripts. For a productivity case study see the slide Swing (Java) vs. Swing (Python) vs. XUL.

    -------------------
    Gerald Bauer
    The Thinlet World | http://thinlet.blog-city.com
  7. Sun are trying to create a framework that allows javabean-like components to be built that can be dropped into application like we are seeing with Swing. By doing so, and allowing application to be developed within an IDE, they are aiming to lower the bar to enable more corporate developers to get start with web-enabled applications.

    JSF is beginning to show signs of success, there are commercially available components that can be dropped into existing applications, but it has taken them a long time to get there. Webonswing allows you to create GUI's using swing and view in a browser (as long as the contributor is available), it really can't be made an easier for the corporate developer who is seeing a VB-like environment.

    In terms of next-gen tools, there is definitely more scope for scripting beyond the elementary constructs offered by JSTL (tho its a good start). I don't see where XUL comes into the equation when we are discussing JSF which is aimed at HTML and perhaps WML rather than actual rich-client tecnologies like flash or applets?

    There are two ways of creating frameworks, hide HTTP like JSF, Webonswing and Echo or show it like Struts etc. I was very much against hiding the details of the request-response cycle, but the event paradigm does allow you to develop much faster by focussing your efforts on the application and not on overcoming the limitations of the protocol.

    It seems that TSS tries to keep us all interested by offering up a discuession on persistence and rich-clients v. mark-up every second week. Very clever indeed!
  8. i hate the swing model, but i hate html more. echo itself basically just has components and actionlisteners. the style i code in is mostly closures and other anonymous objects/actions on the fly. this works great with less nasty taste from swing per say.
  9. Echo is actually a bit simpler than Swing, but the point is that there is an object oriented model based on: events, objects, properties; so don't take it too literally.

    I think you get diminishing returns from markup based languages when you build apps that require much complex visual component reuse. If you don't have such requirements, then it almost doesn't matter what you use - and couple of JSP pages is probably faster to whip up. Big state machine programming model that comes with most tagging style development does not fit in with component oriented development at all.

    What WTs have that markup languages are generally missing is a completely typesafe, compile-time checked, COMPONENT model that can be tooled easily; though I don't have any problem with describing static GUI resources with a markup really - so long as it doesn't force us to design apps as big Finite State Machines - which is essentially GOTO programming. Microsoft's XAML does a fine job of this... and it maps very straightforwardly to the WT code it generates underneath. the only issue with it is that you had better run it all through a compiler to make sure that all references are valid.

    What all WTs are still missing (Echo and Swing included) seems to be along the lines of: 1) Ability to easily script user interaction to automate functional testing with JUnit, 2) A skinning model general enough to allow skins to be things as diverse as "HTML3.2", "Swing", or "SWT". It's kind of crazy that you can't reuse *simple* components for use in a client/server style app in apps targeted for web servers. The barrier is really artificial. I believed that this second problem is the one that JSF was supposed to be helping to solve.

    Needless to say, typical frameworks based on markup languages don't even contemplate such lofty goals. No problem describing GUI resources with markup, but it can't boil down a GOTO programming model among "pages" like it does now. Sometimes I feel like a lot of people that started off as web developers are ignoring some of the deepest lessons learned when doing WT style development; where are the component and event models?
  10. try echo.....[ Go to top ]

    Echo has a large collection of components available (commercial and OSS), and it does resemble Swing code, however Webonswing is Swing code. Have a look at the demos on the Webonswing site and you see how a GUI can be developed using your favourite Swing IDE and then viewed using the Webonswing framework thru a servlet container.
    Have already checked it out. Very cool. All the demos are "simplistic" though - single form/view. Any larger examples?
  11. Wafer Weblog[ Go to top ]

    There's a wafer weblog implementation for WebOnSwing that you can download at sourceforge, this example comes with an already configured Jetty Server.
    It covers almost all WebOnSwing features, except the validation framework that will be included in weblog version 1.5, but you can see it running in "tutorial 3".
    Also we are working on a pet-shop implementation, and a demo with Hibernate.
  12. Wafer Weblog[ Go to top ]

    Thanks. I'll check those other things out. When I saw the validation demo - I was very excited.

    [again, sorry for hijacking this thread]
  13. scalability & performance[ Go to top ]

    performance is great. you hardly use cpu if you set it up right, but you chew up ram.

    scalability is managable, it is a j2ee app. you have to carefully manager how you construct objects and references to ensure not creating things before the're needed, and lose reference when they're not. it's also j2ee, so you can make all objects serializable and do load balancing that way (not recommended), or use apache and sticky sessions.

    it's only really meant for applications (not websites). we haven't ever been under heavy loads yet, but the performance that we've measured has showed that it's much heavier early but plateaus before too long. while we have a couple k users on a single app, we never have many a time on due the the nature of the app/domain.

    problems:
    holding references is deadly, it's the worst of both worlds with thick clients and servers. where you are holding things in memory, but the app 'never' shuts down. so you have to be very careful about whose referencing who.

    benefits:
    in html i never found real resuablity. here we have about 80-90% of our projects code base in a common repository and shared amongst our projects.

    if you want to talk more, i am around the echo forums a bit.
  14. STemplateLayout[ Go to top ]

    If you try echo, give wingS a try, too!

    It features a clear separation of UI logic (accomplished with a proper component model) and design. The STemplateLayout-manager uses a plain html file, that can be produced using the favourite html editor of your web-desigen agency and arranges the components inside it. There is no need for proprietary tags or even jsp tags, that aren't understood by an average web-designer.
  15. I actually like the separation. I think it makes it easier in the case where the html designers are not the same people as those configuring the components. The html can remain relatively uncluttered and editable with tools. The hookup to the components can be kept separate and is also easier to support with a tool in this case as the tools doesn't have to be able to parse html (even if it is xhtml).
  16. Separation is nice, but how many files are needed for one page?
    html template, view specification, faces-config :(

    I think it's better to add some additional attributes to html tags
    (like what we done in Attribute Oriented Programming)
    and declare our components?

    In my sample, what I add to html, remains it editable by general html editors.

    Seyyed Jamal
  17. Hello,
     
       allow me to suggest a more radical approach: Why not dump HTML support alltogether? After all HTML stands for *Hypertext Markup Language* it's not meant for rich internet applications. If you want to create rich internet applications using markup you need - suprise, suprise - a next-gen markup language on *the client-side*. You can find out more about XML UI language at the RICHIE (Rich Internet for Everyone) site formerly known as Open XUL Alliance. See http://xul.sourceforge.net for details.

      - Gerald
  18. Improving JSF by Dumping HTML[ Go to top ]

    Hello,    allow me to suggest a more radical approach: Why not dump HTML support alltogether? After all HTML stands for *Hypertext Markup Language* it's not meant for rich internet applications. If you want to create rich internet applications using markup you need - suprise, suprise - a next-gen markup language on *the client-side*. You can find out more about XML UI language at the RICHIE (Rich Internet for Everyone) site formerly known as Open XUL Alliance. See http://xul.sourceforge.net for details.  - Gerald
    --- Agree.... HTML is evil, it breaks everything.....
  19. Improving JSF by Dumping HTML[ Go to top ]

    I'd agree too. In 10 years, XUL might be really interesting, if it gets a killer app this week. That's how long it took HTML to suck as little as it does. And Microsoft is not years behind with XAML. It may actually have real apps first. I'd like to use XUL too, and I may, but right now, ugly, dynamic, dynamically generated HTML with javascript and CSS and hidden frames and XML data islands and XMLHttpRequest is the best I can get. I'd love to be able to refactor into something like JSF or Echo or Tapestry. My Javascript + frames + would get considerably easier if I only had to target one platform, which is all I'd get with XUL anyway.
  20. Improving JSF by Dumping HTML[ Go to top ]

    Hello,    allow me to suggest a more radical approach: Why not dump HTML support alltogether? After all HTML stands for *Hypertext Markup Language* it's not meant for rich internet applications. If you want to create rich internet applications using markup you need - suprise, suprise - a next-gen markup language on *the client-side*. You can find out more about XML UI language at the RICHIE (Rich Internet for Everyone) site formerly known as Open XUL Alliance. See http://xul.sourceforge.net for details.  - Gerald
    As I said. If you want more people on that site, DROP THE F* YELLOW color !! Than I might be interested in browsing it w/o damaging my already tired eyes. Placing a link to a XUL demo/example(whatever it would be, even just code, so that stupid people like me, that hear about XUL since 2 years now but STILL don't know what is it) right on the first page would be more than helpful.

    thanks
  21. Placing a link to a XUL demo/example(whatever it would be, even just code, so
    > that stupid people like me, that hear about XUL since 2 years now but STILL
    > don't know what is it) right on the first page would be more than helpful.

      For a quick overview of the many XML UI language (XUL) formats in action see the XUL Challenge 2004 Counter showcase online @ http://xul.sourceforge.net/counter.html

      - Gerald

    -------------
    Gerald Bauer
    The Thinlet World | http://thinlet.blog-city.com
  22. Not terribly exiting example.
    In Swing it is trivial and simple to create a new widget and reuse it. Wiring to server side is simple and straightforward too.

    Please show how a new custom widget can be created and _reused_. And how it is wired to server side.
  23. > Placing a link to a XUL demo/example(whatever it would be, even just code, so > that stupid people like me, that hear about XUL since 2 years now but STILL > don't know what is it) right on the first page would be more than helpful.  For a quick overview of the many XML UI language (XUL) formats in action see the XUL Challenge 2004 Counter showcase online @ http://xul.sourceforge.net/counter.html  - Gerald-------------Gerald BauerThe Thinlet World | http://thinlet.blog-city.com
    Got it, thanks. Isn't it a little bit "too much coding" for a simple counter though? I agree Luxor example seems pretty lightweight in comparison with others...
  24. Improving JSF by Dumping HTML[ Go to top ]

    You can find out more about XML UI language at the RICHIE (Rich Internet for Everyone) site formerly known as Open XUL Alliance. See http://xul.sourceforge.net for details. - Gerald
    Ah, excellent Gerald, I love the XUL stuff. Unfortunately this will only ever work if the xul motors get implemented with the client. As long as they stay at the server, it is only adding another layer on top that is increasing complexity. As this is not going to happen anywhere soon, you still have a lot of evangelist work to do :-)
  25. I am just frustrated with struggling with struts and JSF. ASP.NET is a much better programming model. The webform controls and html server side controls are much easier to use. They provide great functionality. Very easy to integrate with javascript client side coding. JSP is built upon the success of ASP anyway. Why don't we just adopt the make-sense approach of ASP.NET and create Java Version of Web Forms, HTML server side controls. I am also disappointer by the Creator Studio Early Access version. The controls and funcationality are so limited. The performance is very poor.
  26. I am just frustrated with struggling with struts and JSF. ASP.NET is a much better programming model. The webform controls and html server side controls are much easier to use. They provide great functionality. Very easy to integrate with javascript client side coding. JSP is built upon the success of ASP anyway. Why don't we just adopt the make-sense approach of ASP.NET and create Java Version of Web Forms, HTML server side controls. I am also disappointer by the Creator Studio Early Access version. The controls and funcationality are so limited. The performance is very poor.
    I don’t totally agree that ASP .NET programming model is better than struts and JSF, but after working with Infragistics ASP.NET components, it's very difficult to come back........
  27. than struts and JSF, but after working with Infragistics ASP.NET components,
    >it's very difficult to come back........Check out Coldtags suite for example: http://www.servletsuite.com/jsp.htm
    And to be honest it is not the only choice by the way
  28. Yes, have to agree. From our perspective, we've been waiting to see what kind of adoption JSF will get.

    I think that the "standards" aspect of JSF alone will make it's use widespread.

    We'll most likely reengineer some of our components to be JSF components in version 3.0.

    Joe Pardi
    dotJ Software
    http://www.dotjonline.com
  29. From a pure technology standpoint (and from experience) I agree it is somewhat better. One issue I have with ASP.Net (other than the Windows Requirement) though is that it takes more than click on drag to make it usable with Mozilla, FireFox, Opera, ... . And these, as browsers, are on the rise (with Mac, Linux and those fed up with Window's viruses) while IE's future is one of assimilation.

    Now comparing ASP.Net to Echo, WebOnSwing, ... - Unfortunately it is still a page based concept which means you have to deal with request/response and HTML and ... .

    Note: I am only commenting on the programming model. Not additional issues like IIS6 (argh).
  30. One issue I have with ASP.Net (other than the Windows Requirement) though is that it takes more than click on drag to make it usable with Mozilla, FireFox, Opera, ... . And these, as browsers, are on the rise (with Mac, Linux and those fed up with Window's viruses) while IE's future is one of assimilation
    I agree and disagree. When you are dealing with highly sophisticated components (like those of Infragistics and ComponentOne), you are going to face the browser compatibility issues with other browsers. But the fact is that the java frameworks (struts, velocity, tapestry) don't even let you get as sophisticated as that to bring out the issues. You have to do all the browser detection on your own. At least in the ASP.NET world, smart components take care of that for you.
    Now comparing ASP.Net to Echo, WebOnSwing, ... - Unfortunately it is still a page based concept which means you have to deal with request/response and HTML and ...
    When HTTP is the underlying protocol, Echo (and similar tools) will be able to shield you from some complexity, but just as .NET or MFC forces you to barebones windows messages for anything sophisticated, so goes in the web world. Besides, I can think of some really complex interactions we had to engineer on a recent project (parent page talking to iframe page and some complex javascript related to that)... I doubt Echo will even support such a level of sophistication.

    Bottom line, the fact that people are unhappy with JSFs tells me Microsoft has clearly won round one. Think about it... M$ looked at what worked and did not with Java - Servlets, JSP, taglibs, etc. and engineered ASP.NET to their strengths (fat client development). And Sun, having the advantage of seeing ASP.NET's success cannot even emulate it! Java was a success for a reason - clean, elegant, simple (no garbage collection). J2EE and a lot of recent API have lost that. And I believe the only way to regain that is not necessarily by simplifying the API but introduced standardized development tools.

    PS: IIS - can't believe it exists. It should be a crime! Yes, the first cyber prosecution - if programs were "beings," then IIS is a convicted criminal.
  31. Kind of funny. The prize of the battle is swamp land. :)

    If one compares what MS has provide vs what Sun has provided - you might have a point. Although, have you checked out Java Studio Creator?

    The problem that I had with ASP.Net was more with the HTML side and not the component side. As usual, they don't tell you what they are doing to you when they do their magic.

    Echo(and Echopoint and Sierra) can do very complicated things and has excellent widgets. I have not found one yet that is not cross browser (IE, Mozilla, Firefox and Opera). The issue you describe, Echo can handle, just different that ASP.Net would.
  32. Velocity[ Go to top ]

    I agree, JSP+taglibs is one of the lousiest possibilites
    for a template based mechanism there is.

    I highly can recommend Velocity in combination with java objects
    or macro libraries for doing the job.

    For instance a decently done jfs like code in velocity would look
    more like

    <whatever hthml tags>
       $formService.createForm("formName")
       <whatever html tags here>
       #for($cnt from [0..10]
          enter ${cnt} formService.createTextField("myText${cnt}",30);
       #end
       $formService.addSubmitButton("submit")
    <whatever html tags>

    this is a close scheme on how a html form can look an a velocity based
    framework, what happens here is, that we have a clear mvc distinction.
    Before the template is parsed, a factory class $formService is put into
    the model (the velocity context) it can be used to generate form elements,
    which in itself render html code.
    Once the submit button is hit, the framework has to take care about
    the event handling (some velocity based framework do this).
    Everthing you see here is pretty similar to JSF but the velocity template
    code is much more readable and easier to program than taglibs and has
    less added bloat since the mvc distinction is done by velocity itself
    and you can pretty much drop every object you need into the model.

    JSF is nice and I think I will move a few old jsp based apps up to JSF, due to good tool integration, but I still think that taglibs are absymal compared to Velocity and Webmacro.
  33. Velocity[ Go to top ]

    HOw is that code any better than scriptlets in JSP? Surely the reason for tags is to allow non-coders to skin web applications, you can bet your bottom dollar that they would make a mess of that velocity code.

    If you are a java coder whose happy to program HTML interfaces too, by all means use velocity or freemarker etc., but when you have to work with a dedicated design team JSP & taglibs becomes one of the strongest candidates available. You give them two rules to follow close every tag you open, and do it in the right order!

    It's also very easy to create re-useable components with JSPs, just look at displaytag, or servletsuite. They can work with the MVC framework you choose, can easily be used across multiple projects, and even a designer can understand (and more importantly, not break) them.
  34. I'm not sure why we should adopt JSF. Sure it's a standard, but there are already products and projects out there that beat JSF at its own game and are more mature. If you want an event driven model, why not just use Tapestry? It works right now and there's no need for JSPs. Frankly I think this is all a little too late. Had something along the lines of JSF been released prior to JSP then I think it would have caught on and been widely adaopted. Currently the primary standard in the J2EE webtier is the servlet spec. Granted it's low level compared to frameworks, but it's already given us a common ground to make a variety of portable, excellent web frameworks.

    JSF sounds neat, I'm just not sure it's really relevant.
  35. Frankly I think this is all a little too late. Had something along the lines of JSF been released prior to JSP then I think it would have caught on and been widely adaopted. ... JSF sounds neat, I'm just not sure it's really relevant.
    Of course it's relevant. Check out Sun's JSF message boards. Developers are tripping over themselves for this. Sure Tapestry does this already. But the point here is that it IS a standard. IBM, BEA, Oracle, and the others will be integrating it into their IDE's by year's end. It will be part of the J2EE standard. While this is not an issue some places, the fact is that many companies rely solely on the J2EE stack and nothing outside it. Some incorporate struts but only because it is shipped inside their chosen container. This will allow those companies to use a very rich framework. It will bring the reality of drag and drop to Java/JSP. Many tools already exist. Show me one mainstream app that has support for tapestry components that allows drag and drop page building (besides an eclipse plugin that is v0.0.1. I don't know of any. For JSF all the big guys and companies like MyEclipse are developing tools that will be SUPPORTED-by a company-that will do drag and drop.
  36. You know I really understand where you're coming from, but I still don't think it's very relevant. We can get into how framwork x, y, or z integrates with what ever but at the end of the day its about getting quality code done as fast as possible.

    It's great that JSF could have drag and drop support in IDE's but I'm not sure that's a silver bullet nor am I sure that's how everyone gets work done. Tapestry gets work done by leaving HTML to designers. They already have drag and drop in Dreamweaver and pure HTML authoring tools. Struts leaves it up to JSP pages that already have wide support. You can make the whole shebang with XML and XSLT. Echo takes HTML out of the picture entirely. WebObjects has been doing the drag and drop HTML elements for years now.

    My impression of JSF is that, like most early J2EE specs, it frankly needs work. It solves some problems but introduces other kinds of complexity. There are better ways of getting this work done. I'm just not sure what JSF brings to the table that needs to be elevated to the status of "the standard".

    That said, if you chose JSF and it works for you I say great. I see it as just another framework.
  37. I Understand Where You're Coming From[ Go to top ]

    Echo takes HTML out of the picture entirely
    Not exactly - http://echopoint.sourceforge.net/LinkedArticles/UsingHtmlTemplatePanel.html
  38. echopoint is not echo, it is a derivative component project that works with echo. html is not 'needed', nor useful, but is, if you must have it for something, available.
  39. echopoint is not echo, it is a derivative component project that works with echo. html is not 'needed', nor useful, but is, if you must have it for something, available.
    Technicality. I think some of those working on Echo work on Echopoint. Echo is the base API with basic things. The Company who how put out Echo has their own add ons too. Without Echopoint there is a lot of functionality missing.

    Echo doesn't take HTML totally out of the picture. First, it generates HTML (and Javascript). I spent time this weekend looking at the HTML it generated so I could use the Grid properly. Second html can be used with it. Sure, Echopoint provides this functionality, but it can be done. So the quote " Echo takes HTML out of the picture entirely" is not correct. And all I was doing was saying that it isn't 100% true.

    As for HTML not being useful. Well No HTML, no view. And, if you read the article, you could see how useful it is for templating. In fact it makes for a wonderful separation if you actually do have view designer types on your team.
  40. I tried Echo[ Go to top ]

    I was involve in many web-app development using Struts, and I was looking for a framework that is more straithforward.

    After trying Echo, I was very impressed by the simplicity of development/deployment of this framework (compared to Struts,JSF and Tapestry).
    No XML config files, mapping and blah,blah

    The only problem I saw was the complexity to do fancy page, with precise layout. You have to work with a Grid object, and its hard to add a component at the right place in little time (because no IDE is available today).

    BUT, with the HtmlTemplate component from EchoPoint, this is the best of both world !!! :

      1 - the power of Echo, that let you work in a compoment/event model and a rich components library
      2 - the flexibility of HTML to let you edit your page layout inside a HTML editor/IDE

    long live o ECHO !!!
  41. i see where the misunderstanding might be. by saying it takes HTML out of the picture, i mean from a development standpoint. i don't write HTML. but yes, it is browser based, so there's still html generated to the browser, but i don't write it.
  42. Spindle is not[ Go to top ]

    ....Show me one mainstream app that has support for tapestry components that allows drag and drop page building (besides an eclipse plugin that is v0.0.1....
    Umm, Spindle is not v0.0.1, its 3.0 heading fast towards 3.1. I suspect you have looked at the content plugins of the Eclipse 'Feature' (plugin packaging construct) that make up Spindle. Sure, the plugins are numbered 0.0.X but the *feature* is numbered 3.0.X. (3.0 took 16 months of part-time work to complete thank you very much).

    Spindle was first released to Sourceforge in Feb or March of 2002, it been around, and actively worked on, for a long time.

    WYSIWYG is cool, but I never found a WYSIWYG tool that proved to be really useful beyond looking at and saying "that's cool!".
  43. Spindle is not[ Go to top ]

    Way too many people are so misinformed about the technologies/tools available in Java.

    There problem is not there aren't good tools to develop apps (web and desktop) in Java but what do you choose. :)
  44. Spindle is not[ Go to top ]

    Of course now that I check the old mailing list archives I did mistate something. The first release at Sourceforge was in April of 2002. But people were using it in Febrary.

    Don't choose *either* JSF or Tapestry based on the tool support. That's crazy, especially if you pay for the tools. Someday the powers on high will declare a new "standard" and your tool support will start to fade away...

    I wonder, if JSF takes off as predicted what will be the state of Struts tool support in 5 years?
  45. Spindle is not[ Go to top ]

    WYSIWYG is cool, but I never found a WYSIWYG tool that proved to be really useful beyond looking at and saying "that's cool!".
    Geoff,

    This is not to say anything bad about Spindle (I love both Spindle and Tapestry), WebObjectsBuilder by NeXT/Apple is a very useful tool for WYSIWYG web component development. I am horrified when HTML designers try to use it, but for me as a developer it is indispensible.

    Given how much similarity there is between Tapestry and WebObjects (not the API of course, rather the philosophy), this might be something worth taking a look.

    Andrus
    http://objectstyle.org/cayenne/
  46. Back in the day, the WOF people I knew would outgrow WOF pretty quickly. Too difficult to do basic things (such as put a loop around a table row) and it got frustrating fast ... and it wasn't stable.

    Spindle is rock solid and does way more than WOF ever did where it counts. The integration into the build is phenominal, the way it can highlight errors in the HTML and the XML is great. It is full of features that make me say "these folks eat their own dog food."

    If you need WYSIWYG support, use Dreamweaver or HomeSite. The point of Tapestry is that it is feasible to use such tools.

    I haven't had a chance to read the OnJava article in detail; at the moment I suspect he's confusing Tapestry's templating subsystem with Tapestry itself. The templating stuff is, ultimately, a simple necessity of all the rest: URL generation and server-side state maanagement. It is nice to know that you can go beyond JSF's surface and properly split up the HTML and the component configuration data.
  47. Back in the day, the WOF people I knew would outgrow WOF pretty quickly. Too difficult to do basic things (such as put a loop around a table row) and it got frustrating fast ... and it wasn't stable.
    Oh please! This was back in the day ;-) It is unfair to do such comparisons. I wouldn't want anyone reminding me that Cayenne 1.0 Alpha 1 was unstable in 2002 :-).

    WOBuilder has its own problems, but its WYSIWYG mode is something that really boosts developer productivity (regardless of the fact that Spindle is better in many other areas). You can't just dismiss that?

    Andrus
  48. Spindle vs. WebObjectsBuilder[ Go to top ]

    I think you have to bear in mind where productivity comes from. WOBuilder is a fantastic tool and I almost went over to WO entirely a few years back the problem was the cost, particular considering that at the time you need to instal webobjects on each server you wanted to deploy to. Still, the GUI builder fast frankly the slickest thing I'd ever seen.

    On the Tapestry side, there is a lot to say for how it works with mostly plain HTML. Yes WOBuilder makes me personally more productive, but that doesn't compare to the ability to hand off the HTML to the design team and let them crank away with all the tools they're accustomed to using. Unless you're a single programmer cranking away, Tapestry's clean separation is preferable.
  49. Um, I've never even *seen* WOBuilder. Pls don't use Spindle as a sword to stike anybody down :-)
  50. JSF components & Tapestry[ Go to top ]

    JSF has support from commercial vendors, Tapestry does not (that I know of).
    If Tapestry jumps on the band-wagon of JSF, then it will increase the likelihood that JSF oriented IDE's will generate Tapestry web applications rather then Struts applications.
  51. I think this aproach is very similar to WebOnSwing Template Engine, except that tags are marked with ID attribute instead of NAME attribute as WebOnSwing templates (this name is configurable), and another difference, that is closer to Tapestry, is that the component mapping is defined in static xml files. The idea of matching html tags hierarchy with component hierarchy is used in WebOnSwing
    with more dynamic behaviour, cause it is matched to Swing component hierarchy by each component name and dont need extra configuration files (xml).
    Also with WebOnSwing you can interchange easily html "templates" to create skins to components or complete pages, you can extract subtemplates from a html file, mix templates and tags, handle the whole template programatically because a java model is created by parsing the file and dont need to be well formed.
  52. do so, it needs to find the component identified by the for attribute, but this component >doesn't exist because the action element that creates it appears after the ><h:outputLabel> element and hasn't been invoked yet.

    I think the word after here belongs to the problems with JSF parser. See
    this stupid Java test for example

    public class test
    {
    public static void main(String argv[])
    {
    System.out.println(x);
    }

    static int x;
    }

    x has been defined after also. And so what?

    >Because JSF components must function in a non-JSP environment, they can rely only
    >on artifacts available in all environments.

    But it is up to component to detect what environment are we in right now. Is not it?

    ><h:panelGroup>
    > <h:outputText value="Some text" />
    > Some more text
    ></h:panelGroup>
    >Now the two texts are reversed: "Some more text" is followed by "Some text".
    >The reason is that the JSP container adds the plain text to the response as soon as it
    >encounters it,

    It means (of course it is in my opinion) that JSF must generate the correct code for JSP container. But it does not.

    >(the page scope is a JSP-specific concept and may not exist in other environments where >JSF must work).

    Again as the above. Why JSF in JSP environment could not see this?


    Marina
    http://www.servletsuite.com
  53. Tapestry comparisons to JSF[ Go to top ]

    (My blog is currently down, so I'm posting a rather long response here)

    A recent article at OnJava, Improving JSF by Dumping JSP has been the source of some interesting discussions. The author, Hans Bergsten, is on the JSF expert group and is quite aware of Tapestry ... he even modified the Hangman example from chapter two of Tapestry in Action for this article.

    Limitations of JSF/JSP

    Interestingly, the JSF component tree is built initially during the JSP render, the first time a page is accessed. That means components early in a page may not be able to reference or interact with components later in the page on that first render, which results in some oddities. He gives an example of a label component and an input field component, where the label does not appear the first time a page is rendered. Whoops! That a violation of the consistency principal to me.

    Then it turns out the JSF mandates lots of limitation on how you write your JSP. For example, in most cases, you must use a <h:outputText> tag rather than literal text to output literal text ... otherwise the text tends to end up in the wrong place!

    Almost two years ago, I was on a quest to mix and match Tapestry and JSP, such that a Tapestry page could use a JSP instead of an HTML template to render its response. I made a lot of progress but hit some complex cases where I could not merge the two models together, and I instead went outside the box to create Tapestry 3.0 (which has JSP-like features, such as implicit components).

    Apparent the JSF team hit the same snags and, because they are blessed by the powers that be, simply said "Thou shalt not do the things that make JSF break. If you do, it is your fault, not ours. Wish I had it so easy!

    Now, as much as the JSF leaders might say that the limitations discussed in Hans' article are merely the result of using JSPs, and that JSF transcends JSPs ... well, any non-JSP implementation of JSF is going to be proprietary, and non-portable
    or lack the IDE tool support that justifies JSF in the first place. This should sound familiar, its the same set of promises that came out five years ago for EJBs (tools will fix everything!), and the same pattern of complexity, lock-in, and inefficiency that resulted.

    Stepping closer to Tapestry

    Hans' article continues with a discussion of how to use JSF with a custom ViewHandler that mimics Tapestry's HTML templates and page specifications. That's great I suppose ... but what I'd rather see is a comparison to chapter six which rebuilds the simple Hangman example using custom components. Creating new components in JSF is very involved ... lots of classes, lots of XML, lots of fiddly bits. Components in Tapestry are streamlined and easy ... and powerful, in that they can have their own HTML templates. So as complimentary as this article is to Tapestry, it is also an unfair comparison.

    More observations

    A JSF application can act as an inversion-of-control container, creating and configuring managed beans. This is a feature of Tapestry as well, primarily through the <bean> element of the page and component specifications. I think this is a better solution, to keep the beans associated with the page (or component) and for the names to be local to the page (or component). A lot of thought in Tapestry has gone into allowing different developers to work on different parts of an application without conflict. Anything global is a measured risk ... in Tapestry, the only true globals are the names of the pages.

    It was interesting to the the <component> tags for selectForm and selections, where selections was nested inside selectForm (this also meant that in the template, the selections component was referenced as selectForm:selections. In Tapestry, the two components would be peers (both children of the containing page) and the relationship (that the form encloses the selections) would be determined at runtime, during the render. This is important, because in Tapestry a Form cannot know statically about all the form element components that will be rendered inside its body ... those components may be in the body of the Form (the most typical case), or inside components within the body of the Form ... or, with clever use of Block and RenderBlock, potentially on an entirely different page of the application! Tapestry doesn't care, which is why artifacts such as form control ids must be allocated dynamically.

    Now I may be nitpicking here, and I'm not sure which of these is related to the JSF standard, and which to Hans' ViewHandler implementation. The HTML template includes the same kind of previewable HTML as Tapestry, but its not clear how or if it is discarded. Additionally, the javax.faces.Command/javax.faces.Link combination (used to render the link around each letter) has a rendered parameter similar to Tapestry's disabled parameter ... but neccessitates a duplication of the javax.faces.Graphic to cover the cases where the link is not rendered (because that particular letter has already been guessed).

    Summary

    I just don't see JSF aspiring to any of Tapestry's guiding principals: Simplicity, Consistency, Efficiency, or Feedback. It's very gratifying that the JSF experts are looking to Tapestry for inspiration ... this is quite similar to the situation with the EJB 3.0 specification and Spring.

    There has been some discussion of what Tapestry can do that JSF can't. That's a silly question ... there's nothing Tapestry can do that JSF can't. There's nothing either framework can do that a servlet can't, or a Perl script for that matter. It's a question of how easy it is to get it working, and how well it works at runtime, and how maintainable it is in the long run.

    Based on everything I've seen, JSF still faces an uphill battle in these areas. Yes, FUD. Yes, I'm biased. But last night at the NEJUG, I coded two simple applications while explaining Tapestry and fielding questions and where I messed up, Spindle or Tapestry itself helped me fix my problems. I doubt I could have accomplished the same things using the JSF RI (even if I had the necessary experience) in the time available. I suspect, over time, we'll be seeing some better shoot-outs between Tapestry, WebWork and JSF. Struts, at this time, is turning into an also-ran kept around for legacy purposes. In the meantime, I repeat the rallying cry: <strong>Results Not Standards</strong>.
  54. Results Not Standards
    Howard, we have already seen the results: there are lots of web frameworks out there, some good, some bad. I have seen a compiled list with more than 50 different ones already. Now, whenever someone has to begin a new project and choose its web framework, what's him to do? You can narrow down to a top 10 list of most used ones or the likes and take a look at each one, but even that would be too time demanding, since each has different strengths and weaknesses, and different paradigms, APIs, etc.
    What we have now is a new specification that can help put some order into this mess. Either we can choose to adopt it, or we can choose to live with this ever increading complexity that we are seeing now and hope that someday a de facto standard raises from this mess, like struts did sometime ago.
    Regarding JSF flexibility, of course it comes with a cost (like everything else), but if it was done in another way (completely tied to JSP and no extensibility, for example), then we would be hearing complaints about its lack of flexibility instead. I vote for greater flexibility. Like you said, tools won't save the world anyway, but a good framework could. And if it is standard compliant, better yet.

    Best Regards,
    Henrique Steckelberg
  55. <blockquoteWhat we have now is a new specification that can help put some order into this mess. Either we can choose to adopt it, or we can choose to live with this ever increading complexity that we are seeing now and hope that someday a de facto standard raises from this mess, like struts did sometime ago. ... Like you said, tools won't save the world anyway, but a good framework could. And if it is standard compliant, better yet.Best Regards,Henrique SteckelbergI'm afraid that what I see is a stratification of the developer pool. Those with less skill will gravitate towards tool-driven approaches like JSF and create a mess for other people to clean up (and trust me, I've been that person brought in to pick up the pieces). Developers with vision will find the best-of-breed and will use it and leave the others in their dust. Who is going to have the long-term employability then?

    A specification is not a standard, at least, not a defacto successful one. Successful standards grow up in the wild, compete and win. I don't trust the JSF team to have come up with the correct solutions to all the critical little issues I've seen developing and supporting Tapestry for four years. Sun has lost its way ... earlier specifications, such as the Servlet API, were much better. They were small and focused and designed to be built upon. The later specifications are big and ponderous and promise to solve all problems but just create more. Tapestry, Spring, WebWork, Hibernate and the many others with a similar spirit are all focused on addressing real problems by real users. They aren't encumbered by a panel of exports, a difficult review process or any of that.

    There were application servers before there was the J2EE specification and we've clearly seen that Sun's attempt to simplify things for us by setting standards has opened up a rats nest of problems that have forced many developers and projects OUT OF Java and into .Net. I'd like to see Sun and the JCP do more than chase Microsoft's tail for once. With Tapestry, I've tried to create something so compelling its a reason to use Java ... with JSF, Sun is aiming to create something to stem the tide of defectors to .Net. That's hard for me to rally behind.

    Or maybe I'm just bitter because they wouldn't let me onto the expert group. :-)
  56. Regarding JSF success or not, I think only time will tell, maybe it is too soon to dismiss it completely right now. And just because JCP has failed before, it doesn't mean it will fail everytime, we have seen some good standards come out even recently. And lately they are focusing more on already existing and proven solutions instead of coming up with magic tricks or extrange new concepts. In this line of thought, I see some similarities between JSF and tapestry in the specification they produced in the end, and that's why I push for their convergence, for me it would benefitial to both. EJB3.0 is following the same path, taking the simple and good ideas from hibernate and spring. The chances of success only increase, by leveraging on existing successful products (just like M$ did by copying Java!).

    Now, regarding you being left out of JSF EG, that was indeed their greatest mistake! ;)

    Best regards,
    Henrique Steckelberg
  57. Tapestry compliant to JSF[ Go to top ]

    yes but this spec is lead craig mcwhatever who's given us little *cough* gem's like tomcat and struts in the past. I have no faith in this spec whatsoever as long as he is leading it
  58. WebOnSwing Implementation[ Go to top ]

    To show how easy is developement of web applications with WebOnSwing, I wrote an implementation of the Tapestry Hangman, that tooks me few minutes. This version re use this article sources: Visit.java, Game.java, WordSource.java, and modified some minor things in the 3 html files, to adapt to WebOnSwing Template Engine.
    You can see that no configuration files are needed, it is pure java and html files with no special tags.
    You can download at: http://webonswing.sourceforge.net/filemanager/wos-hangman.zip
  59. Ah! So Tapestry Hangman is the new Pet Store! :-)
  60. Howard Blogs this issue[ Go to top ]

    http://howardlewisship.com/blog/2004/06/more-on-tapestry-and-jsf.html
  61. JSP 2.0 introduces tag files. These are great because they allow procedural abstraction. This is essential for UI reuse (we define component tags EASILY then reuse them by calling them in more sophisticated tags).

    I know ASP.NET also has this.. and Tapestry has this as well.

    Many many other alternatives DON'T have this, making reuse and the ability to define your own UI elements very difficult.

    On the negative side, JSP has many things I don't need, don't want, and that are temptations to do evil things.
  62. I see a lot of hatred and vitriol for JSP and the recommendation that we should dump HTML altogether and wonder if those critics even grasp the point of JSF.

    JSF doesn't require HTML. If you've read the spec, you'd know that you can have JSF output to any XML-based technology that has a RenderKit for JSF. (And if you want a technology that doesn't have a RenderKit, you could either write one yourself or write a JSTL and pipe the output through Cocoon).
  63. JSF doesn't require HTML. If you've read the spec, you'd know that you can have JSF output to any XML-based technology that has a RenderKit for JSF.
    JSP can emit XUL, SVG, SOAP, or Ant. I suppose 'rendering' is the generation of deliverable text. The generated text doesn't have to be markup. JSP can emit Java, shell script, makefiles, or SQL. This makes JSP more generally useful than JSF. JSF seems aimed at browsers.
  64. Hans,

    I tried running the "Creating and Rendering Components in Parallel" example using Tomcat 5.0.19, and the output renders correctly. Your article states that the <label> element will not be rendered the first time the page is displayed, but that is not what happens when I executed the test.

    -------------------------

    <%@ taglib uri="http://java.sun.com/jsf/html" prefix="h" %>
    <%@ taglib uri="http://java.sun.com/jsf/core" prefix="f" %>
    <f:view>
    <h:form>
    <h:outputLabel for="name">
    <h:outputText value="Name:" />
    </h:outputLabel>
    <h:inputText id="name" />
    <h:commandButton value="Submit" />
    </h:form>
    </f:view>
  65. Hans,I tried running the "Creating and Rendering Components in Parallel" example using Tomcat 5.0.19, and the output renders correctly. Your article states that the <label> element will not be rendered the first time the page is displayed, but that is not what happens when I executed the test.-------------------------<%@ taglib uri="http://java.sun.com/jsf/html" prefix="h" %><%@ taglib uri="http://java.sun.com/jsf/core" prefix="f" %><f:view><h:form><h:outputLabel for="name"><h:outputText value="Name:" /></h:outputLabel><h:inputText id="name" /><h:commandButton value="Submit" /></h:form></f:view>
    You're probably using the JSF 1.1 maintenance release RI.

    The problem for the specific example involving <h:outputLabel> is solved
    in 1.1, as long as both the <h:outputLabel> and the element for the
    component the label belongs to are nested within the same <h:form>
    element (through a hack in the Form renderer)

    The general problem that components may not exist when they are needed
    on the first request because component creation and rendering happens
    in parallel is *not* solved, and I don't think it can be solved.
  66. Is that a limitation of the spec, or is it a bug in the (reference) implementation? Of couse, everybody knows the difference between the two, don't we? ;)

    Have people tried this with other JSF implementations out there (myFaces, for example)?
  67. Is that a limitation of the spec, or is it a bug in the (reference) implementation? Of couse, everybody knows the difference between the two, don't we? ;)Have people tried this with other JSF implementations out there (myFaces, for example)?
    I assume you refer to the problem of parallel creation and rendering, described in the article. If so, it's a problem with the JSF/JSP integration part of the spec. Any implementation that is spec compliant with regards to this has the same problem. Special cases, such as the outputLable example, can be made to work a bit better by hacking things like the Form renderer in a particular implementation, but there's no spec compliant, generic solution to this problem for the JSF/JSP integration.

    The same is true for all problems I describe in the article; they are spec problems related to the JSF/JSP integration, not problems with a particular implementation. As I illustrate in the article, using a custom ViewHandler, they can all be solved.