Discussions

News: Seam 1.2 GA is out

  1. Seam 1.2 GA is out (51 messages)

    Seam 1.2 introduces many improvements including out of the box integration with the Spring Framework, EL support in HQL/EJB-QL, entity level security, SSL redirection, simplified configuration, improvements to orchestration via pages.xml and many enhancements to seam-gen, including support for composite keys and circular associations and integration of Ajax4JSF. Many thanks to everyone who contributed to this release, and especially to Michael Youngstrom who contributed the Spring integration module documented here: http://docs.jboss.com/seam/1.2.0.GA/reference/en/html/spring.html Spring beans may now be injected into Seam components and Seam components into Spring beans. Or, existing Spring beans may be turned into a Seam component with just a single line of Spring XML. Seam's contexts may be used as Spring custom scopes. Finally, Seam's persistence context management may be used by Spring beans. Go get it here: http://labs.jboss.com/portal/jbossseam/download/index.html

    Threaded Messages (51)

  2. Fast team[ Go to top ]

    Wow that is fast, the 1.1.5 release was released just 3 weeks ago. Congratz to the Seam team. Seems (no pun intented) like a very interesting project that I would love to give a try in the near future :)
  3. 1.2.0?[ Go to top ]

    So 1.1.7 is skipped? I thought I saw the roadmap for seam and 1.1.7 was suppose to be release on 2/27. Also, the latest prod release is 1.2.0.patch1 instead of 1.2.0.GA?
  4. Re: 1.2.0?[ Go to top ]

    So 1.1.7 is skipped? I thought I saw the roadmap for seam and 1.1.7 was suppose to be release on 2/27. Also, the latest prod release is 1.2.0.patch1 instead of 1.2.0.GA?
    http://blog.hibernate.org/cgi-bin/blosxom.cgi/2007/02/27#thoughtsononedottwo
    This release was not meant to be such a big one. We had originally intended to call it 1.1.7, but when we sat down and looked at the size of the changelog since the 1.1.6 release, we realized that there were simply too many changes for a point release. So it got a very last minute rebranding ;-)
  5. 1.2.0?[ Go to top ]

    So 1.1.7 is skipped? I thought I saw the roadmap for seam and 1.1.7 was suppose to be release on 2/27. Also, the latest prod release is 1.2.0.patch1 instead of 1.2.0.GA?
    Here's the reasoning behind the verson number increment: http://blog.hibernate.org/cgi-bin/blosxom.cgi Basically, with so many people writing so much code, there were simply too many changes and new features to call this a point release. So 1.1.7 was renamed to 1.2.0. But we made a minor screw-up while incrementing the version number, and had to revise the release, hence there was a PATCH1 that came out about 6 hours after the GA. It was a very complex and stressful release this time round :-/ But I think we finally got it right...
  6. Re: 1.2.0?[ Go to top ]

    awesome, looking forward to try it out.
  7. easy selection[ Go to top ]

    One arguable strength of Ruby is the selection of frameworks is easy -> there is just one -> Rails. People like easy selections. Example: [yellow tail] wine is one of the most successful wines ever because they made selection easy -> there's just one. I hope Spring, and SEAM and Struts2 and Wicket and Grails and Tapestry and MyFramework2 work closer and bridge the gaps, because if the don't people are going to leave Java where the selection is easier.
  8. Re: easy selection[ Go to top ]

    One arguable strength of Ruby is the selection of frameworks is easy -> there is just one -> Rails.

    People like easy selections. Example: [yellow tail] wine is one of the most successful wines ever because they made selection easy -> there's just one.

    I hope Spring, and SEAM and Struts2 and Wicket and Grails and Tapestry and MyFramework2 work closer and bridge the gaps, because if the don't people are going to leave Java where the selection is easier.
    So if your one path is not working for you what then? Changing platforms dropping the entire code. There is a reason why java has so many frameworks, there are lots of angles to cover problems. If you want to go with one selection stay in the JEE realm, if not, go framework shopping. But it is not as bad as you point it out. On the weblayer there are 2-3 major frameworks, the rest of them is not too common (only occasionally used) on the orm level everyone seems to settle down to jpa as a base and in the middleware jee or spring is the choice. (or jee and spring) It is not like you have to chose between 100s of frameworks for normal usecases, but you can if you hit a wall with the predefined path. That is one reason why i hate to program in the microsoft world, you have one choice if it does not cut it you bang your head against a wall, and normally you run into this wall at one stage of a project!
  9. Re: easy selection[ Go to top ]

    That is one reason why i hate to program in the microsoft world, you have one choice if it does not cut it you bang your head against a wall, and normally you run into this wall at one stage of a project!
    At least one. And when you hit that wall (and you will if you are doing anything more than "Hello world") it will really, really, really hurt. My nose should be flat by now.
  10. Re: easy selection[ Go to top ]

    One arguable strength of Ruby is the selection of frameworks is easy -> there is just one -> Rails.
    And if you need functionality Rails does not have: * a templating language that doesn't suck * conversations * support for composite keys * proper support for constraints * persistence contexts * business process management * etc, etc, etc Then you are SOL, because there are no other choices to turn to within the same language.
    Example: [yellow tail] wine is one of the most successful wines ever because they made selection easy -> there's just one.
    An an Australian I'm offended by the mere existence of this awful wine :-) I guess what you're saying is that Rails is the yellowtail of the web framework space. Tee hee. :-)
    people are going to leave Java where the selection is easier
    How does RoR narrow the choice space? It actually widens the choice space: now you have not only one more framework to choice from, but one more whole language! And make no mistake: if Ruby ever gets truly popular in the way that Java is, then guess what people are going to start doing - writing competing web frameworks for it! The fact that there is just one web framework for Ruby after all the years of existence of the Ruby language is a sign of how generally moribund the Ruby ecosystem is.
  11. Re: easy selection[ Go to top ]

    And if you need functionality Rails does not have:

    * a templating language that doesn't suck
    ..
    Uhm, name one Java templating language that doesn't suck? :) In Rails you can use also HAML or Markaby: html do head do title action_name stylesheet_link_tag 'scaffold' end body do p flash[:notice], :style => "color: green" self << @content end end Or you can just write your own templating engine: http://beautifulpixel.com/articles/2007/01/11/write-your-own-template-handler Can you do this just as easily in Seam?
    The fact that there is just one web framework for Ruby after all the years of existence of the Ruby language is a sign of how generally moribund the Ruby ecosystem is.
    Actually there are more. For example Iowa and Why's brilliant 4k micro framework: Camping. Camping supports Active record, migrations and let's you build prototypes even faster than in rails. http://code.whytheluckystiff.net/camping/wiki You can install it with 'gem install camping', create a file named 'hello.rb', add the following: require 'camping' Camping.goes :Hello module Hello::Controllers class Index < R '/' def get 'Hello World' end end end ...Start it with 'camping hello.rb'
  12. Re: easy selection[ Go to top ]

    Uhm, name one Java templating language that doesn't suck? :)
    Uhm, regular HTML as used in Wicket, Tapestry and Facelets?
  13. Re: easy selection[ Go to top ]


    Uhm, name one Java templating language that doesn't suck? :)

    Uhm, regular HTML as used in Wicket, Tapestry and Facelets?
    Well Webmarker, Velocity, Smarty templates... HTML is a lousy templating engine, the interpreters (browsers) are too buggy, and you have a problem with reusability of template parts :-)
  14. Re: easy selection[ Go to top ]


    Uhm, name one Java templating language that doesn't suck? :)

    Uhm, regular HTML as used in Wicket, Tapestry and Facelets?


    Well Webmarker, Velocity, Smarty templates...
    HTML is a lousy templating engine, the interpreters (browsers) are too buggy, and you have a problem with reusability of template parts :-)
    Why nobody mentions FreeMarker here? ;-) Regards, Vitaliy S
  15. Re: easy selection[ Go to top ]


    Uhm, name one Java templating language that doesn't suck? :)

    Uhm, regular HTML as used in Wicket, Tapestry and Facelets?


    Well Webmarker, Velocity, Smarty templates...
    HTML is a lousy templating engine, the interpreters (browsers) are too buggy, and you have a problem with reusability of template parts :-)


    Why nobody mentions FreeMarker here? ;-)

    Regards,
    Vitaliy S
    Sorry I meant freemarker, not webmarker, and smarty is php, I overread in the hast checking the thread, that it was java templating engines only ;-). Besides that we have excellent templating mechanisms in tapestry and facelets. I personally like the way templating engines currently are heading in the java space.
  16. Re: easy selection[ Go to top ]


    Uhm, name one Java templating language that doesn't suck? :)

    Uhm, regular HTML as used in Wicket, Tapestry and Facelets?
    I don't think '<c:if' or 'jwcid="@Form"' is regular HTML ;) Yes, those work for simple examples but once you get little more complex logic in your views... How would you solve the following in Wicket, Tapestry of Facelets? Capitalize a String, get the successor, reverse it and substitute all digits with a *. <% for method in [ ['capitalize'], ['next'], ['reverse'], ['gsub', /\d/, '*'] ] %> <%= "abc001".send(*method) %> Which would result in: Abc001 abc002 100cba abc***
  17. Re: easy selection[ Go to top ]


    Uhm, name one Java templating language that doesn't suck? :)

    Uhm, regular HTML as used in Wicket, Tapestry and Facelets?


    I don't think '<c:if' or 'jwcid="@Form"' is regular HTML ;)

    Yes, those work for simple examples but once you get little more complex logic in your views...

    How would you solve the following in Wicket, Tapestry of Facelets?
    Capitalize a String, get the successor, reverse it and substitute all digits with a *.

    ><% for method in [ ['capitalize'], ['next'], ['reverse'], ['gsub', /\d/, '*'] ] %>
    <%= "abc001".send(*method) %>


    Which would result in:
    Abc001 abc002 100cba abc***
    In JSF, you would have a lot of choices: If the logic is part of accessing and adapting the model to a particular view, you would typically use a backing bean and delegate to it (or alternatively a converter if all you want to accomplish is formatting data). If your treatment is some kind of view processing logic linked to some markup (for instance a calendar) then you would normally create a new UI component to be able to reuse it elsewhere. This is what I like in JSF, complete separation of the view definition and the view processing logic contrary to your example. Of course, it's mean the actual markup rendered get split between a lot of files but I think it's not too high of a price to get such a clean separation of concerns.
  18. Re: easy selection[ Go to top ]

    If the logic is part of accessing and adapting the model to a particular view, you would typically use a backing bean and delegate to it (or alternatively a converter if all you want to accomplish is formatting data).

    If your treatment is some kind of view processing logic linked to some markup (for instance a calendar) then you would normally create a new UI component to be able to reuse it elsewhere.

    This is what I like in JSF, complete separation of the view definition and the view processing logic contrary to your example. Of course, it's mean the actual markup rendered get split between a lot of files but I think it's not too high of a price to get such a clean separation of concerns.
    That's actually the reason why I vowed never to use JSF again ;) All these specific little UI tweaks would require so much work and make everything too complex and hard to unittest. So we had to skip them although they would make the interface a lot better. You can always use indirection, but if you need something just once and it should be trivial I don't want the extra complexity.
  19. Re: easy selection[ Go to top ]

    br>
    That's actually the reason why I vowed never to use JSF again ;)
    All these specific little UI tweaks would require so much work and make everything too complex and hard to unittest.
    JSF was designed to be easy to test and well I can say they have succeeded. Never had any problem to test in the past. So much work? What you are talking about? Writing a backing bean or a converter couldn't be simpler. I would agree that writting a UI component is still too much work at the moment but once you start using a regular template language (contrary to facelet which is only a jsf definition language) like Velocity to write your component, it's get really easy.

    So we had to skip them although they would make the interface a lot better.

    You can always use indirection, but if you need something just once and it should be trivial I don't want the extra complexity.
    How complex is ${myObjet.myproperty}? The only thing you need is to make sure the object is registered to jsf as a managed bean, which means couple of xml lines or some annotations. Velocity in kind of the same way too. True "el" has some limitations but other than that I really happy with this way of working. I don't want to go back to "scriptlets".
  20. Re: easy selection[ Go to top ]

    JSF was designed to be easy to test and well I can say they have succeeded. Never had any problem to test in the past.
    How do you test your views outside of your container? How do you do an integration test scenario over multiple managed beans outside the container? Maybe it's possible, I couldn't set it up in a reasonable amount of time. I would have loved to be able to do something like the following in JSF: def test_some_scenario get "/store/index" assert_response :success assert_template "index" xml_http_request "/store/add_to_cart", :id => ruby_book.id assert_response :success cart = session[:cart] assert_equal 1, cart.items.size assert_equal ruby_book, cart.items[0].product end
    How complex is ${myObjet.myproperty}? The only thing you need is to make sure the object is registered to jsf as a managed bean, which means couple of xml lines or some annotations. Velocity in kind of the same way too.
    If it's that easy, show me the necessary code in JSF that does what my simple example above does so we can compare complexity.
  21. Re: easy selection[ Go to top ]

    How do you test your views outside of your container?
    What do you mean? There is no logic in a jsf page so what do you want to test? The output?

    How do you do an integration test scenario over multiple managed beans outside the container?
    Maybe it's possible, I couldn't set it up in a reasonable amount of time.

    I would have loved to be able to do something like the following in JSF:

    def test_some_scenario
    get "/store/index"
    assert_response :success
    assert_template "index"
    xml_http_request "/store/add_to_cart", :id => ruby_book.id
    assert_response :success
    cart = session[:cart]
    assert_equal 1, cart.items.size
    assert_equal ruby_book, cart.items[0].product
    end

    Well first of all, an integration test by definition needs the container since you want to test all the integrated pieces together no? But it doesn't mean an integration test can't be run locally without deploying the application in a pre-installed container on your desktop. You just need to test using an embeddable web container like Jetty for JSF and JBoss EJB3 for EJB3 if you are using Seam. I have done it successfully often in the past using Jetty. Here, you just need to put this code in your junit setUp() method and drop the jetty jars in your classpath: Server server = new Server(8080); server.addHandler( new WebAppContext("src/main/webapp", "/web-demo")); server.start() And you have a nice application perfectly ready for integration testing. From there, it's quite easy to replicate any user actions and test the model reaction. I don't know a lot about Ruby and its template languages but I think they probably do it the same way. Unit testing a JSF application is even easier since managed beans are Pojos and UI components don't depend directly of any objects coming from the container.


    If it's that easy, show me the necessary code in JSF that does what my simple example above does so we can compare complexity.
    Well I won't do all the String manipulations you made since I don't even know what all of these methods do and I am far from being a String manipulation specialist in Java but here how you would do this in JSF. 1) Write a custom converter import javax.faces.convert.Converter; import org.apache.commons.lang.StringUtils; public class SomeConverter implements Converter { ... public Object getAsObject(FacesContext context, UIComponent component, String value) { // transform the string and returns it } } 2) Register it in faces-config.xml (or use some extension allowing you to declare using annotations and avoiding this step) : SomeConverter SomeConverter 3) And you declare it in your web page : I find it quite simple but I guess it depends what is simple for you. Your code is shorter, all at the same place and needs less steps to be put in place but not by a big margin. On the other hand, I find the code I presented much more cleaner and easier to understand. The concerns are totally separated and so maintenance and integration of new team members is going to be a heck of a lot easier in the long term. Of course, you may not be needing all of this robustness if you are building a very simple web site but if it's the case and you still want to use Java, well use some kind of RAD tools or simpler technologies like Velocity alone.
  22. Re: easy selection[ Go to top ]

    How do you test your views outside of your container?
    What do you mean? There is no logic in a jsf page so what do you want to test? The output?
    Stuff like: I would want to make sure I shouldn't use !empty.
    Well first of all, an integration test by definition needs the container since you want to test all the integrated pieces together no?
    You can do integration testing on different levels, even add the browser. But when I'm just testing that my application doing what it's supposed to do, I don't want to test Jetty, just to be sure it's not Jetty that's causing my tests to fail. It also adds to the startup time of the tests. In Rails I can do integration testing covering multiple controllers without starting up a server. I'll usually have autotest running in the background continously running my test if I change anything. http://nubyonrails.com/articles/2006/04/19/autotest-rails So if I just add the following to a file in my tests dir my new integration test gets tested. require "#{File.dirname(__FILE__)}/../test_helper" class StoriesTest < ActionController::IntegrationTest fixtures :accounts, :ledgers, :registers, :people def test_signup_new_person get "/login" assert_response :success assert_template "login/index" post "/signup", :user_name => "bob", :password => "secret" assert_response :redirect follow_redirect! assert_response :success assert_template "ledger/index" end end
    Well I won't do all the String manipulations you made since I don't even know what all of these methods do and I am far from being a String manipulation specialist in Java but here how you would do this in JSF. 1) Write a custom converter ... 2) Register it in faces-config.xml (or use some extension allowing you to declare using annotations and avoiding this step) : ...
    And you'll have to do these both 4 times for my example (and create 4 converter classes?) resulting in at least 5 times as much code and even more extra work(especially with debugging refactoring).
    3) And you declare it in your web page :...
    You'll need to do this 4 times as well. The repetition of #{mybean.myvalue} is a clue that this isn't the most DRY solution.
  23. Re: easy selection[ Go to top ]

    And you'll have to do these both 4 times for my example (and create 4 converter classes?) resulting in at least 5 times as much code and even more extra work(especially with debugging refactoring).


    3) And you declare it in your web page :...


    You'll need to do this 4 times as well.

















    The repetition of #{mybean.myvalue} is a clue that this isn't the most DRY solution.
    No you just write one converter that do it all and combine all the operation and append all the string together. No need for 4 different converters.
  24. Re: easy selection[ Go to top ]

    You'll need to do this 4 times as well.

















    The repetition of #{mybean.myvalue} is a clue that this isn't the most DRY solution.


    No you just write one converter that do it all and combine all the operation and append all the string together. No need for 4 different converters.
    You would need 4 if you want to control the order in your view.
  25. Re: easy selection[ Go to top ]

    You'll need to do this 4 times as well.

















    The repetition of #{mybean.myvalue} is a clue that this isn't the most DRY solution.


    No you just write one converter that do it all and combine all the operation and append all the string together. No need for 4 different converters.


    You would need 4 if you want to control the order in your view.
    Well the four converters yes but not the four inputs if you use facelets, you would use a ui:repeat component.
  26. Re: easy selection[ Go to top ]

    First of all, here how you do integration tests using Seam : http://docs.jboss.com/seam/1.1GA/reference/en/html/testing.html You don't even need a container running in this case since you construct a JSF request instead of regular HttpServletRequest. Looks quite similar to your ruby example if I'm not mistaken. Of course, it's not vanilla jsf but still show that's it's not impossible. About testing a jsf page, actually I am not sure because I have never done it but I guess I would write a JUnit test. The test would construct a Seam MockFacesContext object using the constructor taking only an ExternalContext as a parameter because I want the context to parse my configuration file and retrieve the different components types my application is using. From there I would instantiate the ViewHandler implementation my application uses and call the createView method with the MockFacesContext object I've just created as the first parameter and the page name as the second parameter. Then I just need to test the state of the UIViewRoot returned by this methods and everything should works like a charm :) Jsf is very cool for that, it's really not tied to the Servlet Api excepts at the crucial integration points.
  27. Re: easy selection[ Go to top ]

    First of all, here how you do integration tests using Seam : http://docs.jboss.com/seam/1.1GA/reference/en/html/testing.html

    You don't even need a container running in this case since you construct a JSF request instead of regular HttpServletRequest.
    It's running inside a pruned down container environment. But that actually looks quiet nice. I wish I had that 6 months ago.
  28. Re: easy selection[ Go to top ]

    How do you test your views outside of your container?


    What do you mean? There is no logic in a jsf page so what do you want to test? The output?


    Stuff like:


    I would want to make sure I shouldn't use !empty.

    You should not use a c:if in a jsf page but rendered attribute. Anyway, I don't think it's worth to test this kind of stuff but you can always check if the UI component tree is what you expected once the page has been parsed. You just need to retrieve from the facescontext object.
  29. Re: easy selection[ Go to top ]

    Stuff like:


    I would want to make sure I shouldn't use !empty.

    You should not use a c:if in a jsf page but rendered attribute. Anyway, I don't think it's worth to test this kind of stuff but you can always check if the UI component tree is what you expected once the page has been parsed. You just need to retrieve from the facescontext object.
    My bad, we did indeed make a lot of use of the rendered attribute. We wound up with buggy views because we couldn't test it in an obvious way (I couldn't find any examples online when I needed them). How does checking the UI component tree work? Does it even work when you use FacesContextMock?
  30. Re: easy selection[ Go to top ]


    Uhm, name one Java templating language that doesn't suck? :)

    Uhm, regular HTML as used in Wicket, Tapestry and Facelets?


    I don't think '<c:if' or 'jwcid="@Form"' is regular HTML ;)

    Yes, those work for simple examples but once you get little more complex logic in your views...

    How would you solve the following in Wicket, Tapestry of Facelets?
    Capitalize a String, get the successor, reverse it and substitute all digits with a *.

    ><% for method in [ ['capitalize'], ['next'], ['reverse'], ['gsub', /\d/, '*'] ] %>
    <%= "abc001".send(*method) %>


    Which would result in:
    Abc001 abc002 100cba abc***
    That works for simple examples where you can live without refactoring support, type safety and all of the other benefits of programming in Java instead of a templating language. Personally, I'd rather just write Java code.
    In Wicket you would do something like this in your page or component class: add( new Label( "stringTest", getStringVariations("abc001") ) ); private String getStringVariations(String input) { List values = new ArrayList(); values.add( StringUtils.capitalize( input ) ); values.add( SomeUtilClass.next( input ) ); values.add( StringUtils.reverse( input ) ); values.add( input.replaceAll( "
    d", "*" ) ); return StringUtils.join( values, " " ); } and your template would be: preview text here Tapestry would be similar -- all of the logic would be in Java instead of the template.
  31. Re: easy selection[ Go to top ]

    How would you solve the following in Wicket, Tapestry of Facelets?
    Capitalize a String, get the successor, reverse it and substitute all digits with a *.

    ><% for method in [ ['capitalize'], ['next'], ['reverse'], ['gsub', /\d/, '*'] ] %>
    <%= "abc001".send(*method) %>


    Which would result in:
    Abc001 abc002 100cba abc***
    That works for simple examples where you can live without refactoring support, type safety and all of the other benefits of programming in Java instead of a templating language. Personally, I'd rather just write Java code.
    If you'd rather write Java code, you agree Java templating languages suck? ;) That's part of the reason why I chose my example. Because it shows I have all the power of Ruby in my templates, so I can create my views in the most simplest/DRY way possible. In Rails I can choose to solve it in my views/controllers or helpers, whatever is the cleanest for the problem. It's all Ruby. Contrary to what a lot of Java people think Rails is very flexible and allows you to solve problems in all kinds of ways (unlike for example JSF where you are stuck to the JSF lifecycle).
    In Wicket you would do something like this in your page or component class:

    add( new Label( "stringTest", getStringVariations("abc001") ) );

    private String getStringVariations(String input) {
    List values = new ArrayList();
    values.add( StringUtils.capitalize( input ) );
    values.add( SomeUtilClass.next( input ) );
    values.add( StringUtils.reverse( input ) );
    values.add( input.replaceAll( "
    d", "*" ) );
    return StringUtils.join( values, " " );
    }


    and your template would be:

    preview text here


    Tapestry would be similar -- all of the logic would be in Java instead of the template.
    I think this looks a lot cleaner than the JSF solution. Still if I add some more complexity... For example what if I want to show it as a list and define a class attribute for every item? I'm using [] because TSS can't handle . [ul] <% for method in [ ['capitalize'], ['next'], ['reverse'], ['gsub', /\d/, '*'] ] %> [li class="bullets"]<%= "abc001".send(*method) %>[/li] [/ul] Then things get a lot more complex. I guess something like: private String getStringVariations(String input) { List values = new ArrayList(); values.add("[ul][li class=\"bullets\"]"); values.add( StringUtils.capitalize( input ) ); values.add( SomeUtilClass.next( input ) ); values.add( StringUtils.reverse( input ) ); values.add( input.replaceAll( "
    d", "*" ) ); values.add("[/li][/ul]"); return StringUtils.join( values, "[/li][li class=\"bullet\"]" ); }
  32. Re: easy selection[ Go to top ]

    If you'd rather write Java code, you agree Java templating languages suck? ;)
    Haha, no, I think Java has a number of excellent choices for templating languages -- if you want some logic in your views. I don't want logic in my views, so I would rather write the layout in HTML and write the logic in Java.
    That's part of the reason why I chose my example. Because it shows I have all the power of Ruby in my templates, so I can create my views in the most simplest/DRY way possible. In Rails I can choose to solve it in my views/controllers or helpers, whatever is the cleanest for the problem. It's all Ruby. Contrary to what a lot of Java people think Rails is very flexible and allows you to solve problems in all kinds of ways (unlike for example JSF where you are stuck to the JSF lifecycle).
    Again, I don't want code in my templates. I've written enough applications in PHP to know that it leads to an unreadable, unmaintainable mess. Your examples look like a huge step backwards to me -- back to the mean old days of picking through text files trying to differentiate the code from the layout and using search and replace while crossing my fingers.

    This always seems difficult for Ruby people to understand, but I *don't want* the flexibility that it offers. The constraints of Java serve a useful purpose in terms of maintainability, refactorability and IDE support. In the long term, those (not to mention Java's numerous libraries, Unicode support, etc.) are worth more than the short-term, minor loc reduction of Ruby.
    I think this looks a lot cleaner than the JSF solution. Still if I add some more complexity...
    For example what if I want to show it as a list and define a class attribute for every item? I'm using [] because TSS can't handle <>.

    [ul]
    <% for method in [ ['capitalize'], ['next'], ['reverse'], ['gsub', /\d/, '*'] ] %>
    [li class="bullets"]<%= "abc001".send(*method) %>[/li]
    <% end %>
    [/ul]

    Then things get a lot more complex. I guess something like:

    private String getStringVariations(String input) {
    List values = new ArrayList();
    values.add("[ul][li class=\"bullets\"]");
    values.add( StringUtils.capitalize( input ) );
    values.add( SomeUtilClass.next( input ) );
    values.add( StringUtils.reverse( input ) );
    values.add( input.replaceAll( "
    d", "*" ) );
    values.add("[/li][/ul]");
    return StringUtils.join( values, "[/li][li class=\"bullet\"]" );
    }
    Well, as you said, you're now talking about a list so you would use an appropriate component rather than putting HTML into your code. It might look something like this in Wicket: add(new ListView("stringList", getStringVariations("abc001")) { public void populateItem(final ListItem item) { item.add(new Label("stringLabel", (String) item.getModelObject())); } }); private List getStringVariations(String input) { List values = new ArrayList(); values.add( StringUtils.capitalize( input ) ); values.add( SomeUtilClass.next( input ) ); values.add( StringUtils.reverse( input ) ); values.add( input.replaceAll( "
    d", "*" ) ); return values; } And the template: [ul] [li wicket:id="stringList" class="bullets"]Example label[/li] [/ul] This example doesn't begin to demonstrate the ability of Wicket to scale with complexity, but you can read about it (http://wicket.sourceforge.net/) or check out the online examples (http://www.wicket-library.com/wicket-examples/index.html) if you're interested.
  33. Re: easy selection[ Go to top ]

    Again, I don't want code in my templates. I've written enough applications in PHP to know that it leads to an unreadable, unmaintainable mess. Your examples look like a huge step backwards to me -- back to the mean old days of picking through text files trying to differentiate the code from the layout and using search and replace while crossing my fingers.


    This always seems difficult for Ruby people to understand, but I *don't want* the flexibility that it offers. The constraints of Java serve a useful purpose in terms of maintainability, refactorability and IDE support. In the long term, those (not to mention Java's numerous libraries, Unicode support, etc.) are worth more than the short-term, minor loc reduction of Ruby
    Bingo, +1 for me. In a component-oriented framework you have to think about what you want to add to your view first and then write it. For instance in JSF, you have to determine wheter is it a converter, a new component, a new component renderer, a domain model concept, .... It's the key to split the view logic from the view definition. The java people have been through the hell of scriplet so I think embedding code in your page doesn't convince most Java folks (especially if you have to cooperate with a web designer). If you just want a general template language and not deal with the complexity of a component framework fine, there is Velocity or Freemarker which allow quite a good separation. I would never recommend scriptlets seriously, they are a huge step backward. In fact, I am sure we can do as much as any ruby scriplet code you can throw the only difference is when you use a component based frameworks (and I would say in Java in general), picking the right abstraction is the key. We just solve problems in a different way than Ruby folks. It's a huge personal and maybe totally bad generalization but I think that when something is not doable in Java, usually developers think there must be a concept they didn't get or hidden somewhere. They try to rethink what they don't get in the problem since the language doesn't have that much dynamicness flexibility instead of just using one of those *extra cool zam bang* features. I don't like ruby that much even if I'd admit I don't know a lot about it (but I know SmallTalk) because it sacrifice readibility and simplicity in favor of pure powerfulness. But to me, a good programming language needs to offer a good balance between powerfulness and readibility, clarity because most of us work in team. A person who have never worked or see the code before and join the projet he needs to be able to get a grasp on it very fast. I know it's possible when you have good java code but I remember how hard it was with Smalltalk the same is true with Ruby.
  34. Re: easy selection[ Go to top ]

    Well, as you said, you're now talking about a list so you would use an appropriate component rather than putting HTML into your code. It might look something like this in Wicket:

    add(new ListView("stringList", getStringVariations("abc001")) {
    public void populateItem(final ListItem item) {
    item.add(new Label("stringLabel", (String) item.getModelObject()));
    }
    });

    private List getStringVariations(String input) {
    List values = new ArrayList();
    values.add( StringUtils.capitalize( input ) );
    values.add( SomeUtilClass.next( input ) );
    values.add( StringUtils.reverse( input ) );
    values.add( input.replaceAll( "
    d", "*" ) );
    return values;
    }


    And the template:

    [ul]
    [li wicket:id="stringList" class="bullets"]Example label[/li]
    [/ul]
    Ok, but now you had to change code at three places (template, add method and getStringVariations method), I dont' think your IDE supports that refactoring ;). And if you need to use both (the list and none list form) you'll also need the previous Java code (of course some duplication can be factored out). Or could you add the follwing with out it breaking? [table] [tr wicket:id="stringList" class="bullets"]Example label[/tr] [/table] [ol] [li wicket:id="stringList" class="bullets"]Example label[/li] [/ol] Plus you can't give the template to the designer if they want to change it to a list (or you'll have to let them access the Java code)
  35. Re: easy selection[ Go to top ]

    Ok, but now you had to change code at three places (template, add method and getStringVariations method), I dont' think your IDE supports that refactoring ;).

    And if you need to use both (the list and none list form) you'll also need the previous Java code (of course some duplication can be factored out).
    Or could you add the follwing with out it breaking?

    [table]
    [tr wicket:id="stringList" class="bullets"]Example label[/tr]
    [/table]

    [ol]
    [li wicket:id="stringList" class="bullets"]Example label[/li]
    [/ol]

    Plus you can't give the template to the designer if they want to change it to a list (or you'll have to let them access the Java code)
    Changing from a list to single value is both a change in logic and in presentation. So it makes perfect sense that you change both (Java for logic and HTML for presentation). It's fine that you prefer an approach that doesn't have this separation and provide your designers with the ability to change behavior as well, but as you can read from the opinions vented in this thread, there's quite a bunch of people - including myself - who believe that it is better to have a strict separation between logic and presentation. And it is a key design decision for Wicket to enforce this separation of concerns.
    Anyways, just choose what works best for you and understand that different things work for different projects/ people.
    As a side note (not intended as flame bait), I've heard of three different projects already that were done in RoR but where people regret their choice now and choose a Java framework for their next project (in twice of these cases Wicket). All three gave the same reasons for their change: they felt RoR was too slow and - more importantly - they were starting to have grave problems maintaining it. I don't want to name any names here, and I'm sure there are enough stories telling the opposite, but my point is that there are people out there that prefer long term advantages such as maintainability and reuse over short term advantages of having less loc and flexibility for designers.
  36. Re: easy selection[ Go to top ]

    Changing from a list to single value is both a change in logic and in presentation. So it makes perfect sense that you change both (Java for logic and HTML for presentation). It's fine that you prefer an approach that doesn't have this separation and provide your designers with the ability to change behavior as well, but as you can read from the opinions vented in this thread, there's quite a bunch of people - including myself - who believe that it is better to have a strict separation between logic and presentation. And it is a key design decision for Wicket to enforce this separation of concerns.
    I have to disagree :) Presenting the values inline, as a list or as a table is pure presentation. There is no behavoir in a list or a table. It's all just Markup Language.
    Anyways, just choose what works best for you and understand that different things work for different projects/ people.


    As a side note (not intended as flame bait), I've heard of three different projects already that were done in RoR but where people regret their choice now and choose a Java framework for their next project (in twice of these cases Wicket). All three gave the same reasons for their change: they felt RoR was too slow and - more importantly - they were starting to have grave problems maintaining it. I don't want to name any names here, and I'm sure there are enough stories telling the opposite, but my point is that there are people out there that prefer long term advantages such as maintainability and reuse over short term advantages of having less loc and flexibility for designers.
    I'm not sure what kind of maintainability problems they had (could be excessive use of scaffolding, which they shouldn't use). In my experience it's soo much easier to remove duplication in Rails (see examples above, although this was a very simple example it's the bigger cases that really show it's strength) and create higher abstractions for easier maintenence. For maintainability in Java and Ruby you'll need a good test suite, especially for bigger applications (loc is important here as well). Rails makes Unit testing so much easier than any of the Java Frameworks I have worked with (Spring Mvc, Jsf, I haven't worked with wicket, sorry :). There is also a very strong focus on testing in the Rails community (as it is in the Ruby community). Compare the very small chapter on testing for Seam: http://docs.jboss.com/seam/1.1GA/reference/en/html/testing.html With the one for Rails: http://manuals.rubyonrails.com/read/chapter/20
  37. Re: easy selection[ Go to top ]

    Changing from a list to single value is both a change in logic and in presentation. So it makes perfect sense that you change both (Java for logic and HTML for presentation). It's fine that you prefer an approach that doesn't have this separation and provide your designers with the ability to change behavior as well, but as you can read from the opinions vented in this thread, there's quite a bunch of people - including myself - who believe that it is better to have a strict separation between logic and presentation. And it is a key design decision for Wicket to enforce this separation of concerns.
    I have to disagree :)
    Presenting the values inline, as a list or as a table is pure presentation. There is no behavoir in a list or a table. It's all just Markup Language.
    No it's not, and this illustrates exactly the problem with allowing any scripting in the presentation templates.
    With such reasoning you can never draw a clear line. You think loops is all just markup language. You probably feel the same about conditionals. And whether a row should be displayed red if a property of a model object has a certain value. Or whether something is a tree or a list.
    And it is much like normal API design; if you leave it open for hacks and cutting corners, people *will* use it in the wrong way and paint themselves into the corner. I believe a separation between logic and presentation is a good (even necessary) thing and believe that scripting in templates is cutting corners and as such believe it is a good think to enforce separation.
    I'm not sure what kind of maintainability problems they had (could be excessive use of scaffolding, which they shouldn't use). In my experience it's soo much easier to remove duplication in Rails (see examples above, although this was a very simple example it's the bigger cases that really show it's strength) and create higher abstractions for easier maintenence.
    Oh, the usual argument: Ruby is an untyped language.
    My personal opinion is that Ruby is a very nice language, and I regularly use it with pleasure, but it gets in my way pretty quickly when I have to do something more complex as then I start missing the way I can explore Java code (call and type hierarchy, code completion, javadoc hovers and quickly jumping to implementations etc). It's nice you don't have to recompile all the time, but then again, it gets really old to have to do runtime tests all the time (or write unit tests) to filter out the typos you made. Anyway, that's hardly a new discussion and there seems to be as many people pro as against scripting languages for web application development.
    For maintainability in Java and Ruby you'll need a good test suite, especially for bigger applications (loc is important here as well).
    Rails makes Unit testing so much easier than any of the Java Frameworks I have worked with (Spring Mvc, Jsf, I haven't worked with wicket, sorry :).

    There is also a very strong focus on testing in the Rails community (as it is in the Ruby community).
    Wicket has excellent support for unit testing. I don't know about Ruby's (or RoRs) support for this, maybe it's even better. But having a strongly typed API helps a lot too and makes that you don't need to write a lot of tests that you probably should with a non-typed language.
    Compare the very small chapter on testing for Seam: http://docs.jboss.com/seam/1.1GA/reference/en/html/testing.html

    With the one for Rails: http://manuals.rubyonrails.com/read/chapter/20
    I have no opinion about that other than to say that it is just documentation and that Seam is just one of the Java frameworks out there. :)
  38. Re: easy selection[ Go to top ]

    I have to disagree :)

    Presenting the values inline, as a list or as a table is pure presentation. There is no behavoir in a list or a table. It's all just Markup Language.
    No it's not, and this illustrates exactly the problem with allowing any scripting in the presentation templates. With such reasoning you can never draw a clear line. You think loops is all just markup language.
    I didn't change the for loops in my examples. I could still do the following: [% stringVariations("123abc) %] [%= result %] [% end %] [ul] [% stringVariations("123abc) %] [li][%= result %][/li] [% end %] [/ul] [table] [% stringVariations("123abc) %] [tr][td][%= result %][/td][/tr] [% end %] [/table]
    You probably feel the same about conditionals. And whether a row should be displayed red if a property of a model object has a certain value.
    It depends on how complex it gets and if I'll need to reuse stuff. I'll usually choose the simplest/quickest solution, could be in the template or in a helper method or partial template, adn refactor if needed.
    Or whether something is a tree or a list.
    No, but I think whether you use a nested ordered html list or a nested html table for a tree is markup. If the result just has diferent html tags it's all markup.
    I'm not sure what kind of maintainability problems they had (could be excessive use of scaffolding, which they shouldn't use). In my experience it's soo much easier to remove duplication in Rails (see examples above, although this was a very simple example it's the bigger cases that really show it's strength) and create higher abstractions for easier maintenence.
    Oh, the usual argument: Ruby is an untyped language.
    No, it's not, it's strongly typed, even stronger than Java, (objects in a collection are strongly typed as well): The following doesn't work in Ruby p "First number in array " + [1,2,3,4,5].first => TypeError: can't convert Fixnum into String Or try doing this in Java. It will certainly compile but could give the unexpected results if you don't overwrite toString. p "SomeObject " + SomeObject.new => TypeError: can't convert SomeObject into String
    My personal opinion is that Ruby is a very nice language, and I regularly use it with pleasure, but it gets in my way pretty quickly when I have to do something more complex as then I start missing the way I can explore Java code (call and type hierarchy, code completion, javadoc hovers and quickly jumping to implementations etc). It's nice you don't have to recompile all the time, but then again, it gets really old to have to do runtime tests all the time (or write unit tests) to filter out the typos you made.
    I'm running Ruby in IntelliJ which has most features you mention and sees typos. http://www.jetbrains.com/idea/features/ruby_development.html I use Zentest in a terminal which continuously looks for changes to code and automatically runs the tests for the changed files. It's wonderful. http://www.zenspider.com/ZSS/Products/ZenTest/ So instead of having my IDE continuously compiling I have a process continuously running my tests.
    Wicket has excellent support for unit testing. I don't know about Ruby's (or RoRs) support for this, maybe it's even better. But having a strongly typed API helps a lot too and makes that you don't need to write a lot of tests that you probably should with a non-typed language.
    Again, Ruby is strongly typed. p "Object " + Object.new => TypeError: can't convert Object into String And the following compiles in Java but throws a RuntimeExcpetion: List a = new ArrayList(); a.add(new SomeObject()); for ( Iterator iter = a.iterator(); iter.hasNext(); ){ AnotherObject value = (AnotherObject )iter.next(); } Not writing tests because of the false security of static typing is what I call cutting corners.:)
  39. Re: easy selection[ Go to top ]

    Ruby is an untyped language.
    No, it's not, it's strongly typed
    Ugh, yeah, sorry about me being sloppy. I meant that Ruby is dynamically typed.
    I'm running Ruby in IntelliJ which has most features you mention and sees typos.
    http://www.jetbrains.com/idea/features/ruby_development.html
    Interesting. I've used a couple of tools for Ruby so far (including an Eclipse plugin) but found that they were very limited compared to Java editors.
    I use Zentest in a terminal which continuously looks for changes to code and automatically runs the tests for the changed files. It's wonderful.
    http://www.zenspider.com/ZSS/Products/ZenTest/
    So instead of having my IDE continuously compiling I have a process continuously running my tests.
    Your setup sounds neat. However, I'm not convinced at all that unit tests are a good replacement for static typing. Writing unit tests requires a disciplined effort, whereas static typing is enforced.
    Not writing tests because of the false security of static typing is what I call cutting corners.:)
    Fair enough :) I might be convinced if I'd ever took a live look in your kitchen. For now, I'll stick to my own recipes which have been working out pretty well since adopting Wicket.
  40. Re: easy selection[ Go to top ]

    I hope Spring, and SEAM and Struts2 and Wicket and Grails and Tapestry and MyFramework2 work closer and bridge the gaps, because if the don't people are going to leave Java where the selection is easier.
    There's a pretty simple response to this: You're wrong. Sorry, but the fact that Java has many choices as far as web frameworks is a strength, not a weakness. For the same client I have applications that use different frameworks because of the nature of the specific applications and who will be working on them. The number of choices certainly didn't hurt Java in the battle against .NET (and ASP.NET) and it won't with Ruby, either. Of course, an intelligent person would see that there is no "battle" between Java, .NET, and Ruby, but rather see the "competitors" as still more choices, each with strengths and weaknesses and each appropriate given a particular situation.
  41. easy selection[ Go to top ]

    One arguable strength of Ruby is the selection of frameworks is easy -> there is just one -> Rails.

    People like easy selections. Example: [yellow tail] wine is one of the most successful wines ever because they made selection easy -> there's just one.

    I hope Spring, and SEAM and Struts2 and Wicket and Grails and Tapestry and MyFramework2 work closer and bridge the gaps, because if the don't people are going to leave Java where the selection is easier.
    One arguable strength of Java is the selection of frameworks is easy -> there is just one -> Seam. :-) Seeya.
  42. Re: easy selection[ Go to top ]

    One arguable strength of Java is the selection of frameworks is easy -> there is just one -> Seam.

    :-)

    Seeya.
    I tried tuh tell em that yesterday, in this here posting. Yuh think they'll listen up?
  43. Re: easy selection[ Go to top ]

    One arguable strength of Ruby is the selection of frameworks is easy -> there is just one -> Rails.

    People like easy selections. Example: [yellow tail] wine is one of the most successful wines ever because they made selection easy -> there's just one.

    I hope Spring, and SEAM and Struts2 and Wicket and Grails and Tapestry and MyFramework2 work closer and bridge the gaps, because if the don't people are going to leave Java where the selection is easier.
    One flavored Kool-Aid is for kids. :)
  44. Re: easy selection[ Go to top ]

    One arguable strength of Ruby is the selection of frameworks is easy -> there is just one -> Rails.

    People like easy selections. Example: [yellow tail] wine is one of the most successful wines ever because they made selection easy -> there's just one.

    I hope Spring, and SEAM and Struts2 and Wicket and Grails and Tapestry and MyFramework2 work closer and bridge the gaps, because if the don't people are going to leave Java where the selection is easier.
    Good example. I think Yellow Tail is pretty near the bottom of my wine preference list for Shirazes . I'll take choice, please.
  45. Re: easy selection[ Go to top ]

    While Rails certainly has a lot of strengths, there are a number of areas where Rails is not an ideal framework. I tend to write code in whatever allows me to be the most productive for whatever problem I am trying to solve. Sometimes (though rarely these days) that is rails, sometimes it is grails, sometimes its seam, heck sometimes its just a plain old JSP. This whole "one framework to rule them all" kitchen sink approach is bad, just as trying to do everything in one programming language isn't always ideal. Choice is always a good thing, and in the future we will have better orchestration frameworks to allow all of these divergent systems to work well with each other.
  46. Re: easy selection[ Go to top ]

    And for the record, there IS more than ONE framework for Ruby. IOWA is one that people overlook mostly because its immature at this stage, but it is shooting for more of a Velocity Macro style of web tier integration. Nevertheless, there is more than one web framework for Ruby and people are in the process of pushing out more and more of them as Ruby gains in popularity. Just because there is one defacto framework doesn't mean there is only one, or that its the best way to do things with that language - it has simply gained considerably with respect to market acceptance.
  47. Re: Seam 1.2 GA is out[ Go to top ]

    As Gavin someday (I guess when Seam Beta just arrived) asked why he would want to have all the dependency nightmares of the Spring-IOC-that-tries-to-integrate-with-everything-Framework it is rather interesting for me to see today that Spring and Seam can walk hand in hand. Since Spring has become the choice for IOC (and nothing else!) in my company and we are searching for a non-proprietary (meaning not self-made:-)) web framework I really think this to be another interesting step for Seam. I just wonder how Seam could integrate with our organizational infrastructure but this is a thought off topic here... Great work! Stefan Schubert
  48. status of JCP[ Go to top ]

    what is the status of the standardization effort? when an initial draft of webbeans will be available ,what feature will be included and which will be sam extension?or this effort failed like the jcache and sdo(manyyyyyyyyyy years and no standard out of jcp)
  49. Re: status of JCP[ Go to top ]

    what is the status of the standardization effort? when an initial draft of webbeans will be available ,what feature will be included and which will be sam extension?or this effort failed like the jcache and sdo(manyyyyyyyyyy years and no standard out of jcp)
    So, I have a "Web Beans Update" talk at JavaOne, so whatever happens we'll need to have something to show by then ;-) We're about to start on some concalls, next week most likely.
  50. Re: Seam 1.2 GA is out[ Go to top ]

    Congratulations to Gavin and the Seam team! I'm very happy to hear that Spring integration is now available and have been looking forward to this. JSF developers interested in Seam may want to check out our product, SeamTools for Dreamweaver. (A free community edition is available for download.) http://www.jsftoolbox.com/products/seam Keep up the good work! Ian -- Ian Hlavats JavaServer Faces for Dreamweaver http://www.jsftoolbox.com
  51. Great![ Go to top ]

    Now looking forward how to switch from Seam 1.1 to Seam 1.2 in next iteration of Nuxeo EP (5.1.M1 will be released RSN, so it's more for 5.1.M2 which is targeted in a couple of weeks). S. Fermigier, CEO, Nuxeo - http://www.nuxeo.com/en/
  52. Re: Seam 1.2 GA is out[ Go to top ]

    And if Gavin wants to use composite keys: http://compositekeys.rubyforge.org/