Discussions

News: Sun's JSF implementation released under the CDDL

  1. Roger Kitain has announced in "Open JavaServer Faces" that Sun's implementation of JSF has been released under the OSI-approved CDDL.

    Meanwhile, Ed Burns has posted that the proposed final drafts of JSF 1.2 and JSP 2.1 specifications have been published - most changes are related to minor defects, but a few features were added and clarified as well.
  2. <sarcasm>
    Yey !!! Sun's poor reference implementation has been released under open source!!!
    </sarcasm>
  3. <sarcasm>Yey !!! Sun's poor reference implementation has been released under open source!!!</sarcasm>

    What's your definition and criteria for "poor"?
  4. Just that it does not seem "finished" or "slick". The devil is always in the details.

    Just an example, when we use the HtmlSelectManyCheckbox and the description is long, well it wraps under the check box. It looks so horrendous, we stopped using it and shifted to using dataTables... (well, this one thing could have been fixed by now, but it will not be hard to find lots more like this one).

    Anyways, i still feel it is a Reference Implementation(Just a POC) which "SHOULD NOT" be sent into production.

    Why did we do it then? (I would have loved to use Myfaces) Well, we were using IBM's implementation because of "Corporate Policy" and it turned out to be a cheap wrapper over Sun's...

    Quite hilarious !!!
  5. Just an example, when we use the HtmlSelectManyCheckbox and the description is long, well it wraps under the check box. It looks so horrendous, we stopped using it and shifted to using dataTables... (well, this one thing could have been fixed by now, but it will not be hard to find lots more like this one).

    Your visual issues with the structual markup are just that... visual issues, the structual markup is probably cleaner with the RI. Ever heard of CSS? I actually fought with the EG over how much structual markup they were using to dictate the 'visual' look at rendering. This isn't 1997.
  6. Well, this is exactly what I am taking about(People usually jump at the chance of pointing out a solution to one example problem), I am not talking about one visual issue.

    Take the more important data handling issue. In the faces specification, it is never mentioned how many times the getters of the model beans are invoked. It is never also mentioned that you should not go to the database in the getters, so, if a developer codes a database access in the getters, the RI invokes it multiple times, voila...

    This and other reasons are why myfaces's components cache the data (please be aware i am NOT talking about object state caching which is a totally different topic).
  7. Well, this is exactly what I am taking about(People usually jump at the chance of pointing out a solution to one example problem), I am not talking about one visual issue.

    Funny, that's all that is mentioned in your post, and there was a solution presented for the one issue that you posted.
    Take the more important data handling issue. In the faces specification, it is never mentioned how many times the getters of the model beans are invoked. It is never also mentioned that you should not go to the database in the getters, so, if a developer codes a database access in the getters, the RI invokes it multiple times, voila...This and other reasons are why myfaces's components cache the data (please be aware i am NOT talking about object state caching which is a totally different topic).

    Well, then here is a way that MyFaces can distinguish itself from Suns implementation.

    As a corallary, however, does the specification mention that the getters are necessarily supposed to be idempotent? That it is, in fact, "legal" for the framework to cache these calls?

    If you have a getter calling the database, then it is most certainly possible that the results of the getters can change throughout its lifetime. This cache system you mention would break that behavior, as it caches at some point within the lifecycle and thus the same app under the different frameworks would give different results. Which result it correct? Who "assumed" the right way?

    What I imagine Sun did is work on the tacit idiom that most getters are simply that, getters, and that very few of them engage in expensive calculations. If during testing the developer discovers that an inordinate amount of time is spent in an objects getters, I would place the burden of optimizing that on the bean developer, not the framework.

    But that's just IMHO and all, I have no experience with either.
  8. As a corallary, however, does the specification mention that the getters are necessarily supposed to be idempotent? That it is, in fact, "legal" for the framework to cache these calls?If you have a getter calling the database, then it is most certainly possible that the results of the getters can change throughout its lifetime. This cache system you mention would break that behavior, as it caches at some point within the lifecycle and thus the same app under the different frameworks would give different results. Which result it correct?

    Again, the fact that myfaces caches is just not for performance. And, if it does that, it wouldn't be too right as caching is a totally different problem. MyFaces caches so that when the view fires the event, the correct model element is accessible to the controller even if the underlying order of the model elements has changed (The RI has serious problems when the model is dynamic). All of this is in the early event stages of JSF. By the time the render response phase occurs, myfaces rightly invokes the getters to make sure the state can be loaded from the persistent medium.

    The Myfaces could correct me here as I have not used it in production yet.
  9. Well, this is exactly what I am taking about(People usually jump at the chance of pointing out a solution to one example problem), I am not talking about one visual issue.
    Funny, that's all that is mentioned in your post, and there was a solution presented for the one issue that you posted.

    Actually, there was more to the post. And the best part is, you did not have to read between the lines to get it. Here it is again:
    (well, this one thing could have been fixed by now, but it will not be hard to find lots more like this one).
  10. <sarcasm>Yey !!! Sun's poor reference implementation has been released under open source!!!</sarcasm>

    As we all (hopefully) know, one of the advantages of open source is to facilitate contributions to make better software.
    Instead of making "negative" sarcastic comments, I would encourage you (and anyone else) to jump on board and help out.