Discussions

News: Craig McClanahan: Struts Or JSF? Struts And JSF?

  1. Craig McClanahan: Struts Or JSF? Struts And JSF? (61 messages)

    Craig Mcclanahan, creator of Struts and co-spec lead for JavaServer Faces, has started blogging. In this entry, he gives his current recommendations for the common question: Struts or JSF?

    Here's an excerpt:
    The Bottom Line

    But what about all those existing Struts applications? Are they going to get left out in the cold, or the developers forced to abandon their existing code and rewrite it? Nothing could be further from the truth.

    The ideal scenario for existing Struts applications would be that we should be able to migrate, one page at a time (nobody has time to replace their entire UI in one fell swoop) to using JSF component tags -- either the standard ones shipped with JSF, or from any available third party component library -- to improve the richness of the user interface. And, because of the original MVC-based promise of separation of concerns, this migration should require little or no change in the back end functionality of the application (for Struts, that primarily means Action and ActionForm classes). Also, the migration should not eliminate the ability to use key Struts features like Tiles and the Validator Framework.

    This scenario is, in fact, achieveable. In the Struts source repository is the Struts-Faces Integration Library, that achieves exactly this goal. It is currently available in nightly builds, but will shortly be released as a stand-alone add on library for Struts 1.1 or 1.2 based environments. The nightly builds include two versions of the canonical Struts example application, one using Tiles and one not, both using the Validator Framework.

    If you have an existing Struts based application, then, I encourage you to evaluate a migration towards using JSF components instead of the original Struts HTML tags. Not only are the original tags effectively superceded by JSF, they are also not undergoing active development at the moment. You will find effectively equivalent functionality in JSF components already available, and much more sophisticated user interface components under development by many providers, for use in the future.

    For new development, here's the best strategy for determining what to do:

    Evaluate the two technologies individually, to see if they satisfy your requirements.
    If one or the other technology is sufficient, go ahead and use it (it's easier to learn and use one technology rather than two where possible); keeping in mind, however, the caveats about Struts HTML tags mentioned above.
    If your requirements include unique features supported only by Struts (such as Tiles or client side validation support), feel free to use the two frameworks together.

    The Future

    It should be clear by now that there is overlap between Struts and JSF, particularly in the view tier. Over time, JSF will continue to evolve in the view tier area, and I'm going to be encouraging the Struts community to focus on value adds in the controller and model tiers. Thus, it will become more and more clear that there is room in many web application architectures for two frameworks, each focused on their own tiers, cooperating to meet overall architectural requirements. The details of this, however, will be the subject of further discussions on the Struts developer mailing list, and (undoubtedly) future blog entries.
    Read Struts OR JSF? Struts and JSF?

    There has been a lot of talk on this issue over the last few days:

    Q&A: JavaServer Faces

    Kris Thompson on JSF, don't we get it?

    Craig Walls on My thoughts on JSF vs. Tapestry

    Threaded Messages (61)

  2. Kris Thompson on JSF, don't we get it?:: JSF is NOT a framework you edit with emacs, JEdit or any other text editor, JSF is Sun's attempt to compete against dotNet.
    - JavaStudioCreator simply does not work on Linux kernel 2.6 : http://swforum.sun.com/jive/thread.jspa?threadID=46519
    - JavaStudioCreator requires its target directory belonged to 'root' - kind of RED flag for me.

    JSF promized component model, but it looks half baked for me. Page is not a component, I mean I cannot insert(reuse) it as a panel on different page. How can I programmatically manipulate component tree? Do I miss something?

    Even JSF looks as a taglib it does not interact well with JSP tags and scriplets. All that makes me feel uneasy about whole JSF direction.
  3. JSF - What's the point[ Go to top ]

    I'm not sure I understand why we need JSF.
    Struts isn't perfect but it works well enough and I'm sure it will improve.

    I wrote a "Hello World" app using JSF.
    I downloaded Sun Java Creator Studio.
    I started reading "Core JSF".

    And so far I just don't see the point.
    I found JSF to be unintuitive.
    Sun Java Creator Studio looks like some kinda Java meets .Net Studio nightmare.
    It appears that one can only write web apps with SJCS. Please correct me if I am wrong about this. Why would I invest in a tool that only allows me to write web apps?
    Why were Pointbase and Sun's app server installed on my machine when I installed SJCS? I don't want them. Talk about an invasive piece of software.

    Sun has gone out of their way to make it so page developers could continue to work on web pages in the Java world without having to deal with actual Java code. With JSF everything is a tag. Do they really expect the people who develop pages, (not Java programmers), to learn all these JSF tag libaries?
    Aren't they defeating their own purpose?

    As well, it appears that I can target particular methods of objects on the server side from web pages using JSF. That just doesn't seem right to me.

    On the plus side Core JSF seems like a pretty good book.

    Can someone please just answer one question for me;
    JSF, what's the point?
  4. JSF - What's the point[ Go to top ]

    [SNIP]...I found JSF to be unintuitive.Sun Java Creator Studio looks like some kinda Java meets .Net Studio nightmare.It appears that one can only write web apps with SJCS. Please correct me if I am wrong about this. Why would I invest in a tool that only allows me to write web apps? Why were Pointbase and Sun's app server installed on my machine when I installed SJCS? I don't want them. Talk about an invasive piece of software.[SNIP]
    If you read the webpages surrounding SJSC carefully and you attend SUN meetings on SJSC you will understand that it is targetting corporate developers. Developers that know the syntax but still aren't Java developers (I'm not trying to disrespect corporate developers, but this is the feeling that SUN, and Microsoft for that matter as well, give me about corporate developers). SJSC is intended to be the Visual Basic for Java. In that they succeeded pretty well in my opinion. It is very easy to click away in the IDE and have a fairly good looking and functional web-interface on top of your back-end. That it is not really architectuarly sound is another matter. I've truly never seen a VB application that would pass any serious architectural review either.
    SJSC is also a pretty good tool to learn JSF. Yes indeed. You click your intended GUI and then take a look at what the tool created as source. The source is fairly clear and you get a pretty good grasp on how things work in JSF and how things were intended to be used. Then you can just refactor the code into you own architecture without loosing all those small yet so important details of JSF.
    [SNIP]...Sun has gone out of their way to make it so page developers could continue to work on web pages in the Java world without having to deal with actual Java code. With JSF everything is a tag. Do they really expect the people who develop pages, (not Java programmers), to learn all these JSF tag libaries?...[SNIP]
    Here I'm agreeing with you all the way. But it is not SUN or any other vendor, it is the mere fact that JSP, taglibs etc are not living up to the promise of leaving web-design up to the web-designers and Java development up to the Java-developers. Every time I work with a web-designer on a GUI for a web-based app (in JSF, Struts or any other framework) I end up in creating the JSP pages myself, copy-pasting the HTML-files into the JSP-files replacing HTML-tags with taglibs because web-designers unleass they have some affinity with Java find JSP's, taglibs etc way too technical, which is good, because most of the times they can create great looking GUI's that appeal to the customer which was the sole reason they were part of the development team.

    Just my opinion.

    Iwan
  5. JSF - What's the point[ Go to top ]

    It appears that one can only write web apps with SJCS. Please correct me if I am wrong about this.

    I write JSF web apps entirely by hand and find it very simple: There is tag entry on the web page, and the description of managed beans and action mappings in an XML configuration file.

    Why would I invest in a tool that only allows me to write web apps?

    It could save time I guess. It would certainly make keeping track of page navigation a lot easier - the faces configuration files can become large.

    Why were Pointbase and Sun's app server installed on my machine when I installed SJCS? I don't want them.

    This is so that you can start to play around with JSF and run the examples even if you have no database or app server previously installed. You don't have to use these features.

    With JSF everything is a tag.

    It doesn't have to be. I code primarily HTML, only switching to JSF tags handling the form controls or any conditional rendering. This may not be the right way to do it, but it works for me.

    Do they really expect the people who develop pages, (not Java programmers), to learn all these JSF tag libaries?

    There aren't that many tags in the core system, and they are simple to use. Compared to the number of standard HTML tags and stylesheet features that skilled web coders have to learn, the JSF tags should be pretty easy to pick up.

    As well, it appears that I can target particular methods of objects on the server side from web pages using JSF. That just doesn't seem right to me.

    I think its a major advantage - it makes for fast coding and it clearly shows which beans provide data and functionality for which tags. I find it a lot like Swing or SWT where you bind events to components.

    Can someone please just answer one question for me;JSF, what's the point?

    Firstly, its a standard for a component model. This means that many companies can (and do) provide component libraries. Look at http://www.myfaces.org or oracle's components (http://www.oracle.com/technology/products/jdev/htdocs/partners/addins/exchange/jsf/index.html). It also means that different IDEs can provide visual tools for Faces.

    Secondly, its a standard, not an implementation. This means that companies compete to produce quality implementations.

    Thirdly (and I can only speak for myself here) I find it very intuitive and easy to code for.
  6. JSF - What's the point[ Go to top ]

    <quote>There aren't that many tags in the core system, and they are simple to use. Compared to the number of standard HTML tags and stylesheet features that skilled web coders have to learn, the JSF tags should be pretty easy to pick up.
    </quote>

    I tend to agree with Iwan in this case. You cannot forget that those designers design the HTML page not only for Java but also for Coldfusion, PHP, etc... To ask them to learn JSF tags is just impossible. At the end you will have a nice UI, so you won't ask for the Java knowledge :-) IMO, JSP with all those Tag libs is just a bad choice. Why don't we just use the right tool for the job? XMLC is the way to go in this case. Add JSF for the <view framework> to work with XMLC and you get everything (or just use Barracuda ;-))

    Cheers,
    Lofi.
  7. JSF - What's the point[ Go to top ]

    <quote> You cannot forget that those designers design the HTML page not only for Java but also for Coldfusion, PHP, etc... To ask them to learn JSF tags is just impossible.</quote>

    I just don't see how the use of JSF tag libs is difficult to learn. After all, if a designer has learned all of Coldfusion, they should find JSF much easier!

    The thing is, that JSF is a lot simpler than normal JSP: No conditions, or loops or embedded code as in PHP or coldfusion. No Java knowledge is needed by the designer, as all the data and logic is in the managed beans. Here is an example:

    <f:form>
    <h:inputText value="#{bean.text}"/>
    <h:commandButton action="#{bean.action}" value="Ok"/>
    </f:form>

    The JSF tags also allow a designer with no Java knowledge at all to control presentation and validation, through the use of formatting, style and validation tags.

    The page designer should have very little difficulty using or learning these tags: its virtually a 1-to-1 substitution of HTML form tags with JSF tags. Its certainly by no standards impossible.
  8. Separation of concerns[ Go to top ]

    The goal of a well-designed view-technology is to separate the concerns of web-designers and -programmers - and JSP with JSF doesn't accomplish that. If you develop web pages for the consumer market, few Java-developers have the skills to make appealing graphichs, layout etc (IMO), so a web-designer is needed - even late in the development cycle. Development with JSP is a one-way street: when a Java-programmer has polluted a HTML page with JSP-tags, a web-designer cannot edit the page with his/her favourite HTML-editor - web-designers should not be forced to learn a new markup language or tool.

    As Lofi pointed out, I hope JSF will be integrated with other view-technologies besides JSP.
  9. Separation of concerns[ Go to top ]

    My kid brother is 15 and plays with html and he could understand how to design something i did after a 5 min intro. ok it wasent a very big system but still. its not that difficult to learn a few new tags and use them. compared to jsp with scriptlet code this is a big step in the right direction.
    the web-designers play with asp/php/javscript so what does a few new jsf tags change.. and for those who need it there will be tools to handle it.
  10. Separation of concerns[ Go to top ]

    The goal of a well-designed view-technology is to separate the concerns of web-designers and -programmers - and JSP with JSF doesn't accomplish that. If you develop web pages for the consumer market, few Java-developers have the skills to make appealing graphichs, layout etc (IMO), so a web-designer is needed - even late in the development cycle. Development with JSP is a one-way street: when a Java-programmer has polluted a HTML page with JSP-tags, a web-designer cannot edit the page with his/her favourite HTML-editor - web-designers should not be forced to learn a new markup language or tool.As Lofi pointed out, I hope JSF will be integrated with other view-technologies besides JSP.
    JSP and JSF can certainly separate web design from programming if used appropriately. The web designer uses these tags to apply the functions supplied by the programmer. JSF includes attributes to allow the designer to specify CSS styles for the runtime generated HTML. The developer need know nothing about these styles, or the HTML that the designer has included. Indeed, the designer can freely use additional JSF/JSP tags that the programmer need not know about.

    As for HTML tools - the designer will not be editing pure HTML: much of the HTML in web applications is, after all, generated at runtime. All decent HTML editors allow the user to embed custom tags within the page - the JSP/JSF tags provided by the programmer.

    There would be an issue of separation of design if the developer used embedded Java code or logic within a JSP page, but this is now generally accepted as bad practice, and would anyway conflict with the way that current implementations of JSF work.

    Finally, there is no reason why JSF/JSP should emit HTML. The programmer can add custom renderers to the JSF and code JSP tags to emit all kinds of markup. There have been examples of JSF emitting SVG, for example.
  11. JSF - What's the point[ Go to top ]

    I wrote a "Hello World" app using JSF.I downloaded Sun Java Creator Studio.I started reading "Core JSF".And so far I just don't see the point.
    I agree in the -1 for JSF; it was sold as better UI. There has been posts that only Struts people "like" JSF, not true. I don't like it and others don't:
    http://www.sys-con.com/story/?storyid=46050&de=1


    .V

    ps: Of course, I do like any RiA: Including Swing!
    http://www.javamug.org/mainpages/2004Meetings.html#Oct
  12. Re: JSF - What's the point[ Go to top ]

    I found JSF to be unintuitive.
    I thought it was very easy to pick up. It found the architecture similar to Swing, in some respects (i.e. events, listeners, UI components, et cetera), just with all your UI code on the server.
    Sun Java Creator Studio looks like some kinda Java meets .Net Studio nightmare.
    Nightmare? What didn't you like about it, specifically? I thought it was pretty good for a reasonable price, although I confess that I didn't purchase it (just downloaded the EA). It wasn't available when I started working with JSF, so by the time it came out I was comfortable creating JSF applications without a RAD tool. I might consider it for future projects, though.
    Why would I invest in a tool that only allows me to write web apps?
    To create web apps. SJCS is pretty reasonably priced, and does its job pretty well, IMO. It's not trying to be one-IDE-to-rule-them-all.
    Why were Pointbase and Sun's app server installed on my machine when I installed SJCS? I don't want them.
    I agree that I don't want Pointbase and the Sun app server installed, either. However, I see why Sun did it; it does let developers immediately use the IDE (complete with persistant storage and an app server for preview/testing) without going through additional installation and configuration.

    I think the installation should support an option that lets you specify that you don't want Pointbase and the Sun app server, and that you can manually configure the IDE to use a different app server.
    Do they really expect the people who develop pages, (not Java programmers), to learn all these JSF tag libaries?
    I don't think this is such a big deal. The tags are pretty straightforward. Also, I've never been on a project where there was a web designer that worked in isolation. Usually the web designer is also a Java programmer, or is mainly a UI designer that works very closely with the programmers (no matter what the page technology is). I just don't see learning the JSF tags as a major issue for a web designer who works on web applications. Heck, it's their job, right? We're not talking about Joe Sixpack slapping up a homepage to show off his pets and kids.
    On the plus side Core JSF seems like a pretty good book.
    I was impressed with it, too.
    JSF, what's the point?
    Well, for one, it provides a standard. I think we're going to see some very nice components libraries built on JSF (much richer than the RI components). The components from Oracle are an early example. JSF has a familiar model for handling actions/events/validators/listeners. It allows you have HTTP requests apply to component-specific event handlers. It has good separation of presentation and behavior. It allows you to manage UI state on the server, in UI objects. Lastly, one of the major benefits is that it can be used with RAD tools like SJSC; that may not be important to some developers, but it could attract an awful lot of developers who want RAD GUI tools.
  13. I Still Don't Like It[ Go to top ]

    It found the architecture similar to Swing, in some respects (i.e. events, listeners, UI components, et cetera), just with all your UI code on the server
    But I don't work with Swing. I write web apps, not fat client, so the whole idea wasn't as straight forward to me. The architecture appears to be just a rip off of ASP.NET. I don't find it to be a very good architecture for non-trivial sites. Allowing programmers to write front end components that can basically call back end methods is just a recipe for spaghetti code. What Sun should have done is not ripped off Microsoft and just come up with their own ideas. JSF was created to be used with a tool, or so I have read. Do they really think that they are going to make a better tool than Microsoft? You can't out Microsoft Microsoft. If Sun wants Java developers to do things the Microsoft way, they what exactly do I need Java for? Why not just move to C# now and use Microsoft's better tools?
    Nightmare? What didn't you like about it, specifically? I thought it was pretty good for a reasonable price, although I confess that I didn't purchase it (just downloaded the EA). It wasn't available when I started working with JSF, so by the time it came out I was comfortable creating JSF applications without a RAD tool. I might consider it for future projects, though.
    I've found a few bugs in it. Deleting Datasource references and then deploying caused an error. The error message was badly formatted and so long that I actually couldn't read it all. What's with having to put in CSS parameters to define the style of an component? I don't really know CSS. I'm a Java programmer. In Visual Studio I can just set the font, or the size very easily. So now I have to learn CSS to use SJCS. How exactly do I hook in another server beside Sun's? Ok, I have a few pages up, I now need an EJB. How do I create one with this tool? As well, the interface isn't really appealing. They have tools inside of this thing to show me how to write a for loop. Are they for real? What would have been more useful would have some generated JavaScript code in the JavaScript section of the properties.
    SJCS is pretty reasonably priced, and does its job pretty well, IMO. It's not trying to be one-IDE-to-rule-them-all.
    I don't want half an IDE. I want to be able to do everything inside of one IDE, like Eclipse for example. It doesn't have to do things for me, it just has to allow me to do them myself.

    I don't buy the whole RAD thing. It works well for small apps, but for large enterprise wide systems, I believe that it could be a detriment. Managers are going to look at a tool like SJCS and think "Wow, we can build our web apps in half the time!", and then cut your time lines. We all know that it just isn't true. A tool like SJCS might save a little time, but over the course of a large project I just don't believe that it will produce quality code that much faster. In fact I'll bet that it will attract people who don't really know how to program, just like VB did back in the 90's, and they'll build all kinds of crappy apps that will do nothing but give Java a bad name.

    Look, I would love to love JSF. I started programming in Java in 1998 and never really looked back. I've done my share of ASP programming, but even when I was doing that I was still writing some apps with Java. I've always been a Java cheerleader. But I have to tell you, if JSF is the future of Java then I really have to wonder why I don't just move to C# now and get it over with.

    Someone do me a favour and change my mind.
  14. I Still Don't Like It[ Go to top ]

    OK, Studio Creator sucks. . .let's build a bridge and get over it. This thread is about the merits of JSF, not one vendor's implementation of it. JBuilder, WebSphere Studio and JDeveloper will all support JSF and should provide a much nicer development environment. And I'm sure someone will provide a nice JSF plugin for Eclipse in the not too distant future.
    But I don't work with Swing. I write web apps, not fat client, so the whole idea wasn't as straight forward to me.
    Why should the approach for developing a fat-client be any different than the approach for developing a thin-client app? Most developers are familiar with an event-driven programming model. JSF provides the event model for Java web apps.
    I don't find it to be a very good architecture for non-trivial sites.
    I'm not sure I follow you on this point, but there's much more to the architecture of an application than the UI. JSF provides the UI, the rest is up to you.
    If Sun wants Java developers to do things the Microsoft way, they what exactly do I need Java for? Why not just move to C# now and use Microsoft's better tools?
    This is the question of the day. Instead of talking about "JSF or Struts" we should be talking about "JSF or ASP.NET". I agree with you on this point, Microsoft's development tools are great and it's going to be difficult for anyone to compete with them. I've been playing around with Visual Studio and ASP.NET and it's a really nice environment to work in.
  15. I Still Don't Like It[ Go to top ]

    I started programming in Java in 1998 and never really looked back. I've done my share of ASP programming, but even when I was doing that I was still writing some apps with Java. I've always been a Java cheerleader. But I have to tell you, if JSF is the future of Java then I really have to wonder why I don't just move to C# now and get it over with.
    Unlike MS world where there is only one proper path to the sunny future, Java universe does not present the ultimate solution. Even if someone called JSF "future of Java", there are other options.
  16. I Still Don't Like It[ Go to top ]

    May be in M$ world there is only one PROPER path, whether its sunny or not, but definately Java world will take another 2 years to meet the ASP.NET 1.1 functionalities and it'll take 4 years to meet ASP.NET 2.0 to become developer friendly. Im not comparing VS.NET Whidbey with Other Java IDE's, which any of these Java IDE's can give in near future.

    But, what i feel is, when Struts / JSF is compared with ASP.NET, these two server side technologies have to go hand in hand and bring some fruitful common framework, but, not as a competing technology within the Java world itself.
  17. JSF development tools[ Go to top ]

    I trust only one company to set up a great JSF development tool, and that is Idea with their IntelliJ.

    IntelliJ is today far better than any Microsoft development tool ever was, and believe me, I have used both.

    regards,

    Martin
  18. Thread.notifyAll[ Go to top ]

    what do I notice that each one of you defends his preferred tool, but is that the question?

    The question is not to use struts or JSF or both or velocity but the question is purely paradoxical from purist point of view. If we see the history :
    The servlets were a substitute of the cgi in JAVA.
    The JSP separates Presentation logic from the business logic

    But we are satisfied with what we do ?
    Actually, JAVA community is divided into an enormous number of groups, each one defends its solution, but at the end J2EE projects are the most difficult projects to realize.

    If we take a look at the presentation tier of J2EE architecture with a critical eye:
    We find it so complex, considering that the 'standards' or the ways of making are many. The experience demonstrates that the cost of team setup and project methodology... is realy height comparatively to .NET.
    With JSP, you cannot separate the design of HTML screens from the integration of TagLib. Separation must be in minds.
    With JSF, HTML designer doesn’t have an existence in the methodological curve of the project, here I speak about big projects.

    JSF as technique, (sorry, I can’t say that it’s a standard, respecting contributors) the principe introduced which we miss, it’s the ' Componentization' but the principe steel a recommendation and not a requirement. I will not speak about the power or weakness of JSF but I’m interesting more on methodology.
    Technically J2EE is better than NET but I am really sorry to say that methodologically NET is really better than J2EE.

    Here is the question: we need a methodology, a unique way to develop.
    from the apis that I appreciate is swing due to its architecture, then let us profit from this approach to do the standard of Web development.

    Developer will not need to know many api, many ways to understand and the project manager will estimate better his tasks.

    Oh Yes !!!
    Converging web development strategy to rich client approach (see Microsoft vision).

    Within this approach, we don’t need many jsp files to write instead of 1 jsp file and components like Panels, Frames, InternalFrames, Dialogs, Inputs, Titles, Grids, Menus, Trees and others.

    Like that we take advantage of inheritance of reusable components and Templates

    To develop a screen :
    1 - Designing your Frame (swing point of view)
    2 - Coding or configuring your Model/View Data Binding according to a giving controller
    3 - Coding your Business
    Like we did with swings.

    Example of how a frame:

    <?xml version="1.0" encoding="UTF-8"?>
    <frame name="page-example" template="simple" background="lightGray">
    <flow-panel name="flow" border="white,SOLID,1">
    <bar-title text="Example Form" border="gray,SOLID,2" foreground="yellow" background="0, 0, 119" textAlign="CENTER" textDecoration="line-through" size="400, 20" vgap="30"/>
    <label label="ID Num"/>
    <textfield name="a.b.a"/>
    <label label="Name" leftIcon.src="" units="10"/>
    <textfield name="a.b.b"/>
    <vgap spacing="10" constraint="SOUTH"/>
    <label label="Description" constraint="SOUTH"/>
    <line width="200" lineBorder="yellow,SOLID,1"/>
    <textarea name="a.b.c" constraint="SOUTH"/>
    <label size="100, 20" label="GOGOGO" units="60" constraint="SOUTH"/>
    <label label="press" size="60, 20" toolTip="press me"/>
    <row-panel name="flow" constraint="SOUTH" border="white,SOLID,1">
    <bordered-title name="gogogogog" text="My Table" border="red,SOLID,1"/>
    <textfield name="a.b.f" maxLength="50" />
    </row-panel>
    </flow-panel>
    </frame>

    Example of a template:
    <?xml version="1.0" encoding="UTF-8"?>
    <template name="simple"
    border="green, SHADED, 1"
    padding="5, 0, 5, 0">
    <textfield
    font="Garamond, BOLD-ITALIC, 10"
    background="orange"
    foreground="blue"
    border="green, SHADED, 1"
    padding="5, 0, 0, 0"
    />
    <textarea
    font="Garamond, BOLD, 12"
    background="magenta"
    foreground="red"
    border="green, SOLID, 1"
    padding="10, 0, 5, 0"
    />
    <label
    font="Arial, BOLD, 12"
    foreground="red"
    textAlign="right"
    />
    <bar
    background="blue"
    border="gray, SOLID, 1"
    />
    </template>

    Sun must think about the future of J2SE
  19. example[ Go to top ]

    I think that everybody who even mentions non-liquid, absolute coordinate based layout should be slowly tortured and then fired.
  20. Re: example[ Go to top ]

    Replica watches shop
  21. Re: I Still Don't Like It[ Go to top ]

    But I don't work with Swing. I write web apps, not fat client, so the whole idea wasn't as straight forward to me. The architecture appears to be just a rip off of ASP.NET. I don't find it to be a very good architecture for non-trivial sites.
    I tend to think just the opposite. I think that a straight JSF is best for non-trivial sites where you can maximize the benefit from the clean separation of UI and business logic and the component-focused event model. For a trivial site, I'd be more likely to use straight JSP, and not worry as much about the application's architecture.
    Allowing programmers to write front end components that can basically call back end methods is just a recipe for spaghetti code.
    I don't understand what you're getting at, here. Are you saying that JSF encourages tight coupling of the presentation and the back-end? If so, I don't agree. Do you have an example of what you mean?
    JSF was created to be used with a tool, or so I have read.
    I've heard that bandied about, too. I think it was a mistake to say that, because it suggests that you need a RAD tool to use JSF. That's simply not the case. Certainly, the ability to use JSF with a RAD tool was part of the design goals for JSF, but that doesn't mean that JSF is a poor technology without such a tool.
    Why not just move to C# now and use Microsoft's better tools?
    That's a good question, especially if you use Windows for your development platform. It's an especially good question if you do exclusively server-side development.

    My main reason for preferring Java over C# is cross-platform capability and the wealth and maturity of the libraries that are available. I do both client and server development, using Mac OS X as my development platform and Linux and OS X as my deployment platform, so you can see why I prefer Java over C#.

    That said, I am keeping a finger in the .NET pie. I have Mono installed on my Mac and have been playing with it. I also have done some C# client development in Borland's C#Builder (on Windows).
    I've found a few bugs in [SJCS] ... [etc]
    Those sound like legitimate complaints. As I said, I just used the EA version, and decided that I didn't need SJCS to develop JSF applications, so I don't really have anything to add, as far as SJCS goes. Nevertheless, I don't think JSF's success or failure relies on one tool.
    What's with having to put in CSS parameters to define the style of an component? I don't really know CSS. I'm a Java programmer.
    Shouldn't the styling be left to the web designer, anyway? I thought that was the whole idea. JSF allows the Java programmers to concentrate on building backing beans, action listeners, server-side UI components, et cetera. The presentation is all markup, ideally done by a web designer (who will be familiar with CSS).

    In our JSF application, the styling is all done in CSS stylesheets, completely separate from the JSP pages, and not even a consideration for the Java developers.
    I don't want half an IDE. I want to be able to do everything inside of one IDE, like Eclipse for example. It doesn't have to do things for me, it just has to allow me to do them myself.
    Yeah, I see your point. I don't think SJSC is useless, or that it is necessarily bad to focus on just one thing. I think some developers might consider it a reasonable value, but it wasn't for me. (I use Eclipse, by the way).
    But I have to tell you, if JSF is the future of Java then I really have to wonder why I don't just move to C# now and get it over with.
    Well, I don't think JSF is "the future of Java," although I think it will have a place in Java's future. I think there's still a lot of work to do in JSF; the RI provides the bare minimum, and performance could be better. On the other hand, I think it's a solid architecture that does a good job MVC-wise, and I expect it to grow and improve as time goes on.

    I don't think web applications are the future, though. Or at least not HTML-based web applications. I think XUL and the whole "rich thin client" thing is going to be the next big bandwagon. Even for a "rich thin client" I don't think XUL will be the only answer. For example, you can deliver a rich, thin Swing (or SWT) application over Java Web Start today. On the XUL front, you can put a Thinlet applet in a web page.

    I like JSF, but honestly, I'm more excited by things like JDNC or Thinlet. I think the client is going to move to things like JDNC, Thinlet, XAML, etc., communicating with the server side over remoting protocols (RMI, SOAP, Hessian, Burlap, et cetera).

    To me, the real question is this: if the "rich thin" client becomes dominant, where will that push server-side development? Will MS be able to leverage XAML such that .NET on the server becomes an obviously superior choice over Java on the server?

    Sorry for the tangent. <grin>
  22. JSF - What's the point[ Go to top ]

    I agree that Studio Creator is not a great IDE, but most major vendors will have support for JSF including Borland, IBM and Oracle. In my opinion, here's the point:
    1) JSF allows me to build my web application UI using an event driven programming model, similar to traditional desktop applications.
    2) I can use my IDE to drag and drop JSF components onto a page without having to "hand code" everything.
    3) I can achieve a seperation between my UI and my business logic without much effort.
    4) I can use built-in validators and converters to manipulate form data simply by dragging them from the component palette and dropping them on my form
    5) I could go on for days. . .
    Do they really expect the people who develop pages, (not Java programmers), to learn all these JSF tag libaries?
    No, they don't. They expect that the JSF standard will allow vendors to provide great development tools that will generate the code for us. I've been a Java developer for several years now, and after evaluating ASP.NET and MS Visual Studio I think JSF is a must have in order for J2EE to keep pace with .NET.
  23. JSF?[ Go to top ]

    In my opinion the biggest advantage of JSF is an ability to create a custom UI control. Using JSF for html creation or form creation is a bit bulky, but if you need to create a UI control that does a specific function (stock market indices for example) it is very useful. I look at it as a web based “visual basic” control with properties. A user can reuse the whole functionality as a product. MVC technology is good for isolation between UI and model but it is really not a good strategy for creation of Web Based controls.

    Your thoughts?
  24. JSF?[ Go to top ]

    In my opinion the biggest advantage of JSF is an ability to create a custom UI control. Using JSF for html creation or form creation is a bit bulky, but if you need to create a UI control that does a specific function (stock market indices for example) it is very useful. I look at it as a web based “visual basic” control with properties. A user can reuse the whole functionality as a product. MVC technology is good for isolation between UI and model but it is really not a good strategy for creation of Web Based controls.Your thoughts?
    It seems so, but as usual eveil is hidden in details. Try creating such reusable component accompanied with JScrips, and Image resources, and i18n resources and then move it to another machine into different project.
    Try that in JSF and with Tapestry.
    In Tapestry it is a breeze: simple and straightforward, just pleasure to deal with.
  25. jsf components and jsp[ Go to top ]

    Page is not a component, I mean I cannot insert(reuse) it as a panel on different page.
    At the moment in our JSF application all reuse is achieved by common jsp:includes. I think that's rather clunky. Writing your own JSF components precludes using jsps in defining them. That's very unfortunate. This is due to the issue with JSP rendering vs JSF rendering. It would be great if this could be solved in JSF.
    How can I programmatically manipulate component tree? Do I miss something?Even JSF looks as a taglib it does not interact well with JSP tags and scriplets. All that makes me feel uneasy about whole JSF direction.
    Manipulating the component tree is easy: if you write your own JSF tag and delegate to an existing component and renderer you can manipulate the component tree.
  26. I had same problem but then I copy directory containing palette components from main installation directory to user specific (some ~/.creator...) and then it run well. Try it.
  27. Craig Walls on My thoughts on JSF vs. Tapestry
    Yeap, Tapestry looks much more appealing if we target rendering to HTML only.

    How about comparing to Echo or webonswing? Echo model looks mu-u-uch more convenient to work with. It is easy to create and reuse own components in Echo too!
  28. Tapestry is superior[ Go to top ]

    After spending a month developing with Tapestry, I can honestly say that Tapestry is clearly superior to a JSP/Struts based approach.
  29. Just like i see no need to get into BMP, and CMP entity ejb for most applications and plain vanila JDBC approach with stored procedure is best way to go in most cases, i don't see any need to get into struts, and jsf. To do a good separation of presentation and business logic, we only need to put all the necessary server side code in taglib and minimize java scriptlets in jsp file. Jsp files sould mainly contain html and references to CSS and javascript files. It is hard to tweak struts html controls and jsf controls with javascript code. However a lot of time client side browser javascripting are still more efficient than serverside processing of GUI components, especially when most organizations are standardized on IE Version 5 and above/NetScape 7 and above browsers, a lot of them on IE only, which make cross browser compatiblities non-issue. DHTML does wonder and acheive far better effect than the server side struts html and jsf components. In terms of usability and functionality, Microsoft ASP .Net html controls and server side controls do a better job than the current JSF UI components. I don't know if JSF has anything comparable to ASP .Net's dbgrid, datalist, calendar components. and Microsoft is churning out more user friendly and functionality rich components and I don't know if JSF can ever catch up in these 2 areas: user friendly and functionality rich. I think another area that jsp should learn from ASP.Net is that ASP.Net server control are really easy to use. You create an ASP.Net server control. And the only thing you need to do in the hosting file is to have a reference tag to the components and then reference the component like you would do to any other class while the taglib are much harder to use. You have to configure .tld file. You have to specify different type of input parameter in the tld files. Then you need to have extra info class to pass the output parameters to the hosting jsp files. Pain in the neck. If using JSF means that i have to do a lot of configuration file meddling, if it means hard to integrate with client side javascripting and DHTML, i would say it is better to stay with html, javascript, jsp with minimized server side java scripting with most server side coding (business logic, database acessing) done in taglib.
  30. I don't know if JSF has anything comparable to ASP .Net's dbgrid, datalist, calendar components...

    ...I don't know if JSF can ever catch up in these 2 areas: user friendly and functionality rich.
    In JSF's RI maybe there is'nt. However, until JSF final release several IDE vendors will make it to us. ;-)
    JSF is just an API for to be implemented!

    Deivson Rayner T Costa.
  31. I don't know if JSF has anything comparable to ASP .Net's dbgrid, datalist, calendar components.....
    Check out the Early Access release of the Oracle Faces component set:
    http://www.oracle.com/technology/products/jdev/htdocs/partners/addins/exchange/jsf/index.html
    That will give you a better idea of the kind of promise that JSF has. Coupled with IDEs that provide integrated editing capabilities around the standard, JSF is probably going the single most important lever in attracting developers to J2EE rather than .NET, and I mean this at many levels - not just attracting VB style programmers with Hand holding tools like Studio Creator, but the full range of developer competences and styles.
  32. Examples of richer Faces Components[ Go to top ]

    JSF is probably going the single most important lever in attracting developers to J2EE rather than .NET,
    I have always thought the most important factor in favour of J2EE rather than .NET was that you actually have a choice of operating systems on which you can deploy! This is such a fundamental advantage, I have never considered using .NET in any way. However, making Web app development easier is likely to attract developers even in pure Microsoft setups.
  33. Folks, don't mix the <view techniques> like JSP with JSTL, XMLC, Tapestry "jwcid", Velocity ... with the <view frameworks> like Struts, EAF, Barracuda, Tapestry, JSF, ... OK, many of view frameworks bring their own view technique like Tapestry...

    Yes, JSF RI uses JSP as its view technique and therefore it's horrible. JSP is actually horrible, not the JSF itself. Tapestry "jwcid" is quite nice but the best is XMLC view technique, why? Because:

    1. It uses the same technique as Tapestry "jwcid". All HTML, WML, VoiceXML, XHTML, cHTML, etc. only added by "id". Not more than that -> Clean separation of developers and designers!

    2. You compile the pages into Java DOM classes! So, every errors can be found in the compile time and not runtime. This also means that you only work with Java classes (DOM) in your presentation layer implementation. Once you have worked with DOM and XML you can work automatically in XMLC (anyone hasn't done any XML and DOM programming?) ;-) In runtime you have a very fast presentation view (already pre-compiled => compiled Java classes!).

    Check out this article:
    http://www.theserverside.com/articles/article.tss?l=XMLCvsJSP

    If you need a view frameworks for XMLC you can choose between EAF (Action oriented) and Barracuda (Event oriented). I also read once in TSS that someone uses Struts + XMLC (instead of JSP) with success...

    It would be really cool to see that someone implements JSF with XMLC as its <view techniques> instead of using JSP, because as we all know, JSP (not JSF) is sooo bad...

    Cheers,
    Lofi.
  34. Tapestry is nice as a "view technique"..

    You don't seem to like JSP (and I've seen a lot of code that would make me hate it too).. but I think JSP 2.0 with EL is a major leap (maybe even better than Tapestry). Let me explain why:

    - The main problem w/ UI reuse in web pages is that they often use include as the reuse mechanism. Include is no better than a GOTO, what we need is procedural abstraction.

    - Enter taglibs.. tag libs are nice because you can define "your own higher level language" for web pages, just as we could "invent" our new language in Pascal (define new procedures that just do it for us). Unfortunately, they are too hard and unnatural to program.

    - Enter tag files (Disclosure: ASPX also has these).. these are good because now creating a new tag is as easy as writing the original XML style file in the first place.. this is truly procedural abstraction at its best.

    So as long as you layer your tag files using JSP and avoid Java code and Javascript (except at the lowest layers), JSP 2.0 is pretty darn good (alternatively you could write your cleaned up version of JSP called XJSP that omits all the useless JSP 1.0 "features").

    <my-web-page layout="border-layout">
      <north><title-bar /></north>
      <south><copyright-statement /></south>
      <east><menu-pane /></east>
      <center><content-pane /></center>
    </my-web-page>

    (The above is just a made up example... to illustrate an abstraction easily possible w JSP 2.0)

    Tag files and EL are great improvements.. you could still write bad code if you wanted to.. but now it is easy not to (before is wasn't).

    I won't comment on XMLC because I'm not familiar with it.
  35. Web Designers[ Go to top ]

    For those who argue that it is simple for web designers to pick up JSF tags.

    Guys, the issue is not abt complexity in picking up tags.

    Think reverse. How tough is it for a Java developer to learn HTML. Name a single java developer who might not know html. But does that mean that java developers should do web design. i know there are several companies where java developers do UI and in many cases, the UI just sucks as a result.

    Any guy with reasonable brains can pick up anything, but the issue here is separation of concerns. Java developers should not be focussing efforts on UI. Web designers should not be deprived of the freedom to work with raw HTML.

    Next thing, most people here are arguing abt web designers dragging and dropping JSF components. My question is how abt writing custom components. No, I am not saying that u r into the business of creating custom componenets. But I think there will be a high probabiliy of projects needing custom components. Compare the JSF approach of writing a custom component to Tapestry's approach of using an HTML template. Tell me which one would be simpler for the web designer.

    If JSF was the only option for a component model, I could understand, but with stuff like Tapestry around, I fail to understand why people would want to go the JSF route. Look at pages using JSF components. They look ridiculously horrifying. Then look at the java code for the JSF components. Equally horrendous - tonnes of presentation markup in java code. Is this really where you would all like to go?
  36. I agree with you, also with René above.

    For the example above from Steve:

    <f:form>
    <h:inputText value="#{bean.text}"/>
    <h:commandButton action="#{bean.action}" value="Ok"/>
    </f:form>

    Now I put a pure HTML version (with CSS) of it which can be used by XMLC:

    <form action="Save.html" method="GET">
    <input type="text" name="amount" id="Amount" class="forminput">
    <input type="submit" name="submit" value="Ok" id="Submit" class="formbutton">
    </form>

    1. Standard HTML. Open it with any Web editors.
    2. Open it with standard Web browsers and do your "go through application without functionalities == simulation" with your customer.
    3. Use the power of CSS (class).
    4. With the standard "id" of HTML you can do everything: multi-languages, etc.
    5. To make your components: simple, for example:
       -> create a stand-alone <table> which contains anything you want.
       -> embed it in the runtime to a table placeholder (in one or many pages).
       Remember of DOM tree? You can insert everything in that tree. All the
       formatting stuffs will be taken from the CSS of the page, that's it.
       Actually it is quite simple to implement portlets in XMLC :-)

    JSP with TagLibs (not the event model of JSF) always hurts me, because I have to train people in this topic and they want to learn it because it is "standard"...

    <quote>
    Compare the JSF approach of writing a custom component to Tapestry's approach of using an HTML template. Tell me which one would be simpler for the web designer.
    Then look at the java code for the JSF components. Equally horrendous - tonnes of presentation markup in java code.
    </quote>

    Yes, I agree with you. The same as writting TagLibs. I know, nobody should write their own components, TagLibs, .... because you should re-use or buy the components. Anyway, one good point with JSP (in connection with JSF): all the tool vendors can sell their products (yes, this is indeed needed) :-) So, keep all the industries behind it happy :-)

    Cheers,
    Lofi.
  37. 1. Standard HTML. Open it with any Web editors.
    2. Open it with standard Web browsers and do your "go through application without functionalities == simulation" with your customer.3.
    Use the power of CSS (class).
    4. With the standard "id" of HTML you can do everything: multi-languages, etc.
    5. To make your components: simple, for example: -> create a stand-alone <table> which contains anything you want. -> embed it in the runtime to a table placeholder (in one or many pages). Remember of DOM tree? You can insert everything in that tree. All the formatting stuffs will be taken from the CSS of the page, that's it.
    But - everything you say here applies to JSF! you can freely use CSS in JSF components, you can use multiple languages, you can assign standard HTML ids, you can open it in a HTML editor (a decent editor anyway).

    The point about JSF is that its easy for a non-coder, using a tool such as Studio Creator, to design, test and demonstrate "with functionality" pages.
    Tell me which one would be simpler for the web designer. Then look at the java code for the JSF components. Equally horrendous - tonnes of presentation markup in java code.
    Yes, I agree it would have been better if there was a way for non-coders to add components to JSF. But the point is not for the web designer to design the components. That is the role of the programmer. The web designer uses the components.
  38. <quote>
    But - everything you say here applies to JSF! you can freely use CSS in JSF components, you can use multiple languages, you can assign standard HTML ids, you can open it in a HTML editor (a decent editor anyway).
    The point about JSF is that its easy for a non-coder, using a tool such as Studio Creator, to design, test and demonstrate "with functionality" pages.
    </quote>

    ... and now we are back to the topic ;-) Why should one buy those JSP/JSF tools if you can do it NOW, easy and cheap? No need to upgrade the knowledge of those web designers. Just to fullfill the need of the tool vendors? Always to upgrade with no advantages? This is the main question, I have asked...

    - Updating from C++ or Delphi to Java is worth it (platform independence, easier, free...)
    - Updating from "only code" to "add model" (MDA) is worth it (faster to develop your application, stable architecture, good documentation for your application, ...)

    But updating from XMLC + <view framework like EAF, Struts, Barracuda> or Tapestry or JSP + Struts to JSP/JSF? This is mostly not worth it. If you build a new application, *maybe* you can try JSP/JSF just to do something new (because we all like to try something new, right?), but really worth it? Nope, not with JSP/JSF IMO :-)

    Cheers,
    Lofi.
  39. <quote>But - everything you say here applies to JSF! you can freely use CSS in JSF components, you can use multiple languages, you can assign standard HTML ids, you can open it in a HTML editor (a decent editor anyway).The point about JSF is that its easy for a non-coder, using a tool such as Studio Creator, to design, test and demonstrate "with functionality" pages.</quote>... and now we are back to the topic ;-) Why should one buy those JSP/JSF tools if you can do it NOW, easy and cheap? No need to upgrade the knowledge of those web designers. Just to fullfill the need of the tool vendors? Always to upgrade with no advantages? This is the main question, I have asked...- Updating from C++ or Delphi to Java is worth it (platform independence, easier, free...)- Updating from "only code" to "add model" (MDA) is worth it (faster to develop your application, stable architecture, good documentation for your application, ...)But updating from XMLC + <view framework like EAF, Struts, Barracuda> or Tapestry or JSP + Struts to JSP/JSF? This is mostly not worth it. If you build a new application, *maybe* you can try JSP/JSF just to do something new (because we all like to try something new, right?), but really worth it? Nope, not with JSP/JSF IMO :-)Cheers,Lofi.
    The main push for JSF is that it is a STANDARD. Multiple vendors can compete on implementation, multiple vendors can provide components, and you can mix and match components and implementations. Plus it helps foster a market for it: more books, more articles, more knowledge.

    About JSF being tied to JSP and taglibs, this is not true. Almost everything in JSF is pluggable, so you can create another view templating mechanism and plug it in a JSF implementation and off you go. For example, <href="this" rel="nofollow">http://www.onjava.com/pub/a/onjava/2004/06/09/jsf.html">this article</a> shows how you can replace JSP entirely in JSF, with a templating mechanism very similar to tapestry's. If someone could continue from where the article stopped, one could almost recreate all of tapestry completely. What would we get? All the well-known benefits of tapestry, plus a major benefit of JSF: it is STANDARD, so you get tons of books, experienced developers, components providers, faster adoption, etc., as a consequence.

    +1 for making tapestry JSF compliant. They are not competitors, instead they should leverage each other's benefits, for the sum will be much greater than the parts. I am sure Java community would adopt such a solution like there's no tomorrow.

    Regards,
    Henrique Steckelberg
  40. OOps, never type faster than you can think! Article link fix: this article
  41. Race Condidtion[ Go to top ]

    How fast were you typing? ;-)
  42. Tapestry / Standards[ Go to top ]

    I was joking with Dion a ways back that Tapestry is more standard than JSF ... just different standards. Tapestry conforms to the Apache Tapestry Component Web Application Standard really well. :-)

    People keep pointing to the Hans' article about replacing the JSP portion of JSF with a Tapestry-like HTML template mechanism. I think that's a step in the right direction, since it starts to get the seperation of concerns right, but still falls a great deal short of Tapestry 3.0.

    In addition, as I've noted before ... the JSP integration is the JSF standard and if you depart from the JSF standard, any advantages of using JSF fall away.

    We've been sold this bill of goods before; J2EE was going to be a snap because it was so easy for IDEs to magically do all the work. We were going to buy all our business components on eBay. Trained monkeys would produce our code while we were out getting lattes. Is that the world you live in, because it isn't mine. I work in a world of results not standards, so on my current project I'm using Tapestry, HiveMind and Solarmetric Kodo (because JDO is a standard that actually improves and simplifies things).

    I don't have time for drag and drop. As a previous poster in this thread pointed out (and as something implicit in Tapestry's design from day one), it is ridiculous to expect any single individual to be both an HTML coder and a Java coder. It's two seperate skill sets, two seperate tool sets, two seperate mind sets. Any solution that doesn't meet that challenge head on is flawed. Any solution that expects a single tool to be used by both sides of the equation is sacrificing productivity, not enhancing it. Any tool that doesn't embrace the fact that the presentation side (HTML templates) is in constant flux is missing living in a fantasy. Drag and drop tools get in the way ... while you are fussing in a tool to get your tables and loops to layout properly, I can take the <table> and <tr> in the HTML template passed to me by an HTML coder and quickly convert it into a live component, just by adding jwcid attributes and some simple XML (in a seperate document, not mixed in with the presentation).

    I still can't picture what a JSF-compliant Tapestry would look like. I can't see what the advantage for Tapestry would be, beyond marketing ... and I'm unwilling the lead the team in that direction if it means crippling what makes Tapestry great.
  43. Tapestry / Standards[ Go to top ]

    I was joking with Dion a ways back that Tapestry is more standard than JSF ... just different standards. Tapestry conforms to the Apache Tapestry Component Web Application Standard really well. :-)People keep pointing to the Hans' article about replacing the JSP portion of JSF with a Tapestry-like HTML template mechanism. I think that's a step in the right direction, since it starts to get the seperation of concerns right, but still falls a great deal short of Tapestry 3.0.In addition, as I've noted before ... the JSP integration is the JSF standard and if you depart from the JSF standard, any advantages of using JSF fall away.
    I have a different view of things: it would mean a (small) change in JSF for _another_ standard (HTML), with plenty of tools for it also. JSP is used in JSF as just a mean of arranging your components together as blocks to create your UI. Using Tapestry's mechanism in JSF would mean exchanging JSP for HTML, and there's plenty of tools to help you create HTML UIs. This is a change is just _one_ part of JSF, and that doesn't mean it's "less" standard than JSF + JSP.
    We've been sold this bill of goods before; J2EE was going to be a snap because it was so easy for IDEs to magically do all the work. We were going to buy all our business components on eBay. Trained monkeys would produce our code while we were out getting lattes. Is that the world you live in, because it isn't mine. I work in a world of results not standards, so on my current project I'm using Tapestry, HiveMind and Solarmetric Kodo (because JDO is a standard that actually improves and simplifies things).I don't have time for drag and drop.
    But tools are not the only benefit you get with JSF, and IMO, it the smallest one. The possibility of having a huge market involving vendors, users, developers, book writers and OS community around a STANDARD, and increased industry/community adoption are the biggest benefits, IMO.
    As a previous poster in this thread pointed out (and as something implicit in Tapestry's design from day one), it is ridiculous to expect any single individual to be both an HTML coder and a Java coder. It's two seperate skill sets, two seperate tool sets, two seperate mind sets. Any solution that doesn't meet that challenge head on is flawed. Any solution that expects a single tool to be used by both sides of the equation is sacrificing productivity, not enhancing it. Any tool that doesn't embrace the fact that the presentation side (HTML templates) is in constant flux is missing living in a fantasy. Drag and drop tools get in the way ... while you are fussing in a tool to get your tables and loops to layout properly, I can take the <table> and <tr> in the HTML template passed to me by an HTML coder and quickly convert it into a live component, just by adding jwcid attributes and some simple XML (in a seperate document, not mixed in with the presentation).
    As I said, forget tools, and focus on what following a standard means, which doors it may open for everyone. Tools will be a consequence of it all, _IF_ developers demand it at all anyway. But I imagine the result will be so easy as tapestry is today, and there will be no need for tools beside a regular HTML editor and your preferred Java IDE.
    I still can't picture what a JSF-compliant Tapestry would look like. I can't see what the advantage for Tapestry would be, beyond marketing ... and I'm unwilling the lead the team in that direction if it means crippling what makes Tapestry great.
    Of course no one would want Tapestry to cripple, this is not the idea. I think though there is space for a detailed technical evaluation of the impacts of such endeavor, and then it would be possible to answer if making Tapestry JSF compliant would be benefitial or not, which benefits it would bring (from technical and marketing POVs), and if the cost of such change is not greater than the benefit itself. In a situation where standards are demanded, a JSF-compliant Tapestry solution would be very hard to beat, comparing to other JSF implementations! :)

    Sorry if I am bothering you Howard with all this JSF push, I don't mean to. IMO Tapestry would gain a lot by joining forces with JSF, but of course the best person to judge that is you.

    Regards,
    Henrique Steckelberg
  44. Henrique,

    <quote>
    About JSF being tied to JSP and taglibs, this is not true. Almost everything in JSF is pluggable, so you can create another view templating mechanism and plug it in a JSF implementation and off you go. For example,
    </quote>

    agree with you, therefore I always said JSP (see my older threads). JSF event model is ok, but not JSP ;-) I'm taking about JSP the whole threads (see: diff between <view framework> and <view techniques>) :-)

    Yeah, therefore I hope someday that someone makes the integration of XMLC into JSF... (again see the older thread).

    Cheers,
    Lofi.
  45. ... and now we are back to the topic ;-) Why should one buy those JSP/JSF tools if you can do it NOW, easy and cheap? No need to upgrade the knowledge of those web designers. Just to fullfill the need of the tool vendors? Always to upgrade with no advantages? This is the main question, I have asked...
    Because having one system accepted as standard by tool vendors allows people to produce web applications faster as it allows the development of a very large set of re-usable components to make web application development easier. Its like under Windows when Visual Basic appeared along with VBX components. Suddenly there were thousands of components that made GUI coding fast and easy. JSF may not be the best component model, but having it as the one accepted as standard by tool vendors and a large number of developers is a real advantage.

    I also find it a very natural way to code, as its component/event model reminds me of the SWT and Swing systems I have been using for years. I don't have to deal with the rather indirect ideas of Forms and Actions (as with Struts) - I deal with components, their properties and their events: its a far more obvious way to code user interfaces.

    Finally, JSF gives you get another type of independence - display independence: The user interface shipped with the JSF reference implementation is HTML, but it does not have to be. Its possible to add libraries so that JSF components are rendered as XML, or WML or even Swing! The idea is that JSF is a general-purpose way of describing UIs.
  46. The idea is that JSF is a general-purpose way of describing UIs.
    I am not fond of XUL, but XUL seems more logical as "a general-purpose way of describing UIs" than JSF.

    Just 2c
    I also find it a very natural way to code, as its component/event model reminds me of the SWT and Swing systems I have been using for years.
    I guess you will feel home with Echo.
    ...Visual Basic appeared along with VBX components. Suddenly there were thousands of components that made GUI coding fast and easy. JSF may not be the best component model, but having it as the one accepted as standard by tool vendors and a large number of developers is a real advantage.
    JavaBeans (real ones, not just get/set datastructures ) are much more 'componentish' but even they are not terribly popular.
  47. I guess you will feel home with Echo.
    Perhaps, but what is the point? JSF works fine, and is a JSR standard.
    JavaBeans (real ones, not just get/set datastructures ) are much more 'componentish' but even they are not terribly popular.
    I was referring to GUI components, such as the Swing JComponent. This has nothing to do with EJBs.
  48. I guess you will feel home with Echo.
    Perhaps, but what is the point? JSF works fine, and is a JSR standard.
    My point is that JSF does not seem to work fine for me, especially because I have Swing experience and Delphi one( 6 year ago).
    JavaBeans (real ones, not just get/set datastructures ) are much more 'componentish' but even they are not terribly popular.
    I was referring to GUI components, such as the Swing JComponent. This has nothing to do with EJBs.I was talking about JavaBean too as they defined by beans spec (http://java.sun.com/j2se/1.4.2/docs/guide/beans/index.html ). They are NOT Enterprise beans.
  49. Web Designers..., separation of concerns[ Go to top ]

    Yes, I agree it would have been better if there was a way for non-coders to add components to JSF. But the point is not for the web designer to design the components. That is the role of the programmer.
    When u speak abt a JSF component, there is major chunk of it that is about presentation. And please help me understand that why u wud want the role of the programmer be to deal with the presentation aspect of the JSF component and not the web designer. Dont tell me that the web designer will provide the java programmer with the HTML for the component and the java programmer would then put that into the java code for the component. That is not separation of concerns. That is trying to get the job done within a flawed model. I think the very idea of using custom tags to generate presentation markup is flawed. JSF has been built around this idea and i think that is where it suffers. Of course, it seems that other approaches can be plugged in but I think the vast majority are going to stick with the JSP/custom tag approach. I personally hate using tags that generate presentation markup. Look at Spring MVC. Unlike Struts/Webwork, they have refrained from creating tags that generate presentation. I think thats wonderful and has helped not pollute Spring MVC.
  50. Web Designers..., separation of concerns[ Go to top ]

    Yes, I agree it would have been better if there was a way for non-coders to add components to JSF. But the point is not for the web designer to design the components. That is the role of the programmer.
    When u speak abt a JSF component, there is major chunk of it that is about presentation. And please help me understand that why u wud want the role of the programmer be to deal with the presentation aspect of the JSF component and not the web designer.
    I don't think that the role of the programmer is to deal with the presentation aspect of JSF, and I disagree that a major chunk of JSF is about presentation. JSF tags are mainly about functionality (for example <h:inputText/> - simply specifies a text input box). The designer is free to adjust the attributes of the JSF tags to control all aspects of presentation, formatting and style. The programmer may provide a component that can display a grid of data. Its up to the designer how the cells are formatted, how many cells are displayed, the colour, the fonts, and other CSS attributes. For example: The programmer can specify that a web form links to another page, and says to the designer 'the action you must call is "newpage"'. Its entirely up to the designer how that action is called: from a link, a button, or an image, and the designer can control the appearance, placement, various javascript events etc. As JSF is a standard, the designer can even bring in other open source or commercial components to help render the page. I don't see how simply asking the designer to put an action name (or value name) into an attribute is asking them to get involved in Java, and I don't see how the programmer providing functionality for the designer is getting involved in the design itself.

    To summmarise, the presentation markup that JSF tags produce should (if the tags are well coded) be almost entirely under the control of the designer, through the attributes of the tag.
  51. Web Designers..., separation of concerns[ Go to top ]

    <<<<JSF tags are mainly about functionality (for example <h:inputText/> - simply specifies a text input box). The designer is free to adjust the attributes of the JSF tags to control all aspects of presentation, formatting and style.>>>>

    Please refer to my earlier post. This is exactly what i have said. I have seen so many people argue abt the web designer dragging and dropping JSF components and adusting the color and styling attributes. Ur example speaks abt styling a text box. And I am speaking about building a custom JSF component. A custom JSF component can comprise of several sub-components arranged in a specific layout, there could be javascript associated with these components. Who writes this component, the Java developer or the web designer, and how?
  52. Web Designers..., separation of concerns[ Go to top ]

    Sorry for the reposts...some stuff got snipped off in the earlier post
    JSF tags are mainly about functionality (for example <h:inputText/> - simply specifies a text input box). The designer is free to adjust the attributes of the JSF tags to control all aspects of presentation, formatting and style.
    Please refer to my earlier post. This is exactly what i have said. I have seen so many people argue abt the web designer dragging and dropping JSF components and adusting the color and styling attributes. Ur example speaks abt styling a text box. And I am speaking about building a custom JSF component. A custom JSF component can comprise of several sub-components arranged in a specific layout, there could be javascript associated with these components. Who writes this component, the Java developer or the web designer, and how?
  53. Web Designers..., separation of concerns[ Go to top ]

    A custom JSF component can comprise of several sub-components arranged in a specific layout, there could be javascript associated with these components. Who writes this component, the Java developer or the web designer, and how?
    JSF components should not consist of sub-components arranged specifically. Arrangements should be able to be controlled by attributes, which can be changed by the designer. If there is javascript - that depends on what it has to do. If its core to the functionality of the component it would be the programmer. If its some optional presentation code, this could be supplied by the designer.

    Look - presentation code and Java have to meet *somewhere*. If the designer codes forms in pure HTML, then the Java developer will have to write separate code that handles the values sent in the forms and knows what form tags the designer has used. There is duplication of effort here, and two places where changes have to be made: the HTML, and the Java code. This is bad practice. With component systems like JSF, there is a component that is placed on the web page, and that is the *single* place where the structure of the web form is represented.
  54. And I am speaking about building a custom JSF component. A custom JSF component can comprise of several sub-components arranged in a specific layout, there could be javascript associated with these components. Who writes this component, the Java developer or the web designer, and how?
    Interesting question ... I've blogged my thoughts on this.

    Craig
  55. Sorry ... cut-n-paste error on the URL. The actual blog is
    here.

    Craig
  56. And I am speaking about building a custom JSF component. A custom JSF component can comprise of several sub-components arranged in a specific layout, there could be javascript associated with these components. Who writes this component, the Java developer or the web designer, and how?
    Interesting question ... I've blogged my thoughts on this.Craig
    NullPtr saying that creation of custom component should not be complex and ordinary developer should be able to create custom components on the fly easily.
    Lets take Employee Details, in Swing (Echo) I could create EmployeeDetailsPanel extends JPanel (as a collection of simple components) and then use its instances everywhere within application. For example as renderer in a JList or JTable.
    It does not seem to be that simple with JSF. Am I right?
  57. And I am speaking about building a custom JSF component. A custom JSF component can comprise of several sub-components arranged in a specific layout, there could be javascript associated with these components. Who writes this component, the Java developer or the web designer, and how?
    Interesting question ... I've blogged my thoughts on this.Craig
    NullPtr saying that creation of custom component should not be complex and ordinary developer should be able to create custom components on the fly easily.Lets take Employee Details, in Swing (Echo) I could create EmployeeDetailsPanel extends JPanel (as a collection of simple components) and then use its instances everywhere within application. For example as renderer in a JList or JTable. It does not seem to be that simple with JSF. Am I right?
    If you assume that the end results of your effort must be a *JSF component*, then it's straightforward to build something like that -- but it seems to me like the wrong way to do things.

    Using Creator, I just built a page fragment for employee details, with five or six fields and some buttons, complete with the event handlers for the buttons, in under two minutes. Adding some basic CRUD event handling logic (by copying some code clips from an existing similar app) and binding to a database table took another couple of minutes.

    Doing the JSP page by hand in a text editor would have taken 10-15 minutes (depending on how quick I am at typing JSP source code by hand) instead. The database wireup might also take longer, depending on what kind of sample code I had available to start from.

    The result in either case is a completely reusable chunk of markup (and associated event handler code in Javaa), suitable for reuse as a static or dynamic JSP include (if doing pages by hand). In Creator, the tool creates page fragments as drag-and-drop things just like JSF components, so I can even have that level of integration in a very straightforward way.

    Tell me again why I would bother to make my fragment into a JSF component? It's reusable already.

    Craig
  58. why I would bother to make my fragment into a JSF component? It's reusable already.Craig
    No, IMO it does not have to be JSF component, but should be reusable. From your description it seems reusable, but I cannot use Studio because I work on Linux kernel 2.6 ( http://swforum.sun.com/jive/thread.jspa?threadID=46519 ) .
    suitable for reuse as a static or dynamic JSP include
    How that will resolve form within a form if that fragment happens to be a form?
  59. why I would bother to make my fragment into a JSF component? It's reusable already.Craig
    No, IMO it does not have to be JSF component, but should be reusable. From your description it seems reusable, but I cannot use Studio because I work on Linux kernel 2.6 ( http://swforum.sun.com/jive/thread.jspa?threadID=46519 ) .
    The latest update of Creator has worked around the JVM bug that was causing this problem. Therefore, it works on 2.6 kernels now.
    suitable for reuse as a static or dynamic JSP include
    How that will resolve form within a form if that fragment happens to be a form?
    That issue is common to any technology that attempts to reuse chunks of HTML ... it is by no means specific to JSF. The basic approach with page fragments containing forms is to not nest them inside an outer form on the containing page. For use in Creator specifically (which creates a form component for you, since that is the most common use case), you have to ensure that the page fragment is not nested. In the initial version of Creator, it's easiest to do that in the JSP source -- in an upcoming version, it's a simple drag operation on the Application Outline to adjust the nesting.
  60. The latest update of Creator has worked around the JVM bug that was causing this problem. Therefore, it works on 2.6 kernels now.
    Will try.
    That issue is common to any technology that attempts to reuse chunks of HTML ... it is by no means specific to JSF.
    That does not seem to be a problem for Echo and Wings... There we work on component level, pretty much like with Swing and it somehow gets rendered and handled properly in browser...
  61. JSF Sucks![ Go to top ]

    I belive that JSF is really a bad idea.. too complex to succed.. is like EJB too coomplex too slow too hard to code...
    Its a waste of time..
    If you want some view technology thats is fast and easy to code in use Velocity instead of JSP and JSF.

    Anybody thinks that JSF is easy to write and learn?
    And is user friendly? Every click that the user does force a complete page reload, thats really sucks in terms of user friendly and perfonance...
  62. Javascript in JSF?[ Go to top ]

    I have just started using JSF and been writing simple apps using this technology. I wanted to know how to use Javascript in JSF tags. Are there code examples around?