OraNA :: Oracle News Aggregator

Today I had to download Google Chrome, to work (verify) a bug. Same issue is present in Safari 3.2.1. Perhaps I should mention that both aren’t using the latest greatest WebKit as its core… So, I gave the nightly a shot… The bug wasn’t reproducibly with the nightly WebKit. Nice.

Since there is a huge G in Chrome… folks want to see fixes in there. Kinda more pressure instead of fixing a “Safari only” bug

This all is fine, sure. But it is interesting that the Chrome browser uses an older WebKit than Safari 3.2.1…

Let’s hope there is an update out soon, that bundles the G browser with the latest, greatest WebKit.

It is pretty cool to see that there is lot’s of activity on the JSF 2.0 implementation of the Apache MyFaces project. Lot’s of folks contribute via the JIRA issue tracker (filing bugs/tasks, submitting patches), or the mailing list.

Really, a good community driven effort!

Btw. it is still time to join. Just subscribe to our dev-mailing list

When using Facelets it is normal to use XHTML files to describe the view. Also in your web.xml configuration mostly you find a mapping of the FacesServlet to something like “/faces/*” or “*.faces”, so that you have URLs like:

http://myserver:port/context/coolPage.faces (or .jsf)

Now, it is easy to view the source code of the page, when the application is written with Facelets’ XHTML files. Just do the following:

http://myserver:port/context/coolPage.xhtml

You now see the page structure, what libraries are used etc. This type of “Open source” you definitely want to avoid, when using Facelets. You could write a security filter or something similar, but the soultion could be really really simple.

Use the following servlet-mapping in your web.xml:

...
  <servlet-mapping>
    <servlet-name>faces</servlet-name>
    <url-pattern>*.xhtml</url-pattern>
  </servlet-mapping>
...

No more “Open Source” of your Facelets application

Apache MyFaces Trinidad does support Mobile Application Development. There is also some documentation on this feature, here.

Let’s see if we get a (nice) demo…

If you are interested in it, join the large MyFaces community.

Enjoy!

There is a lot of buzz (not only recently) around some extra scope, that is shorter than a session and longer than a request. Such a scope is a very good scope to implement business processes or some wizard (==> step x of n). Lots of frameworks call this “conversation”, so does Orchestra or Seam. In Trinidad there is a “pageFlowScope” for this…

One of the goals of JSF 2.0 is to “standardization of the many different Dialog/Conversation/Scope/Flash ideas currently in use”. On the other hand there is the WebBeans standard, that tries to contribute some ideas of the Seam framework to the Java EE community (and some DI ideas from Google Guice).

Seam as you know has also this extra scope… and if both JSF and WebBeans would address this issue, there would be two beasts for the same story.

So, one could think that JSF should just relay on WebBeans for that kind of functionality, but that would cause a serious amount of headaches when it comes to the JSF 2.0 adoption… Similar like it was, when the JSF 1.2 hit the road (it introduced the dependency to JSP 2.1…). So if JSF 2.0 has a mandatory dependency to WebBeans it could make things harder than needed. Same would be true if other web frameworks, like wicket, want to use this. Yes, it is possible…

But again, it is huge dependency for a common feature…

So, why not adding this scope could to a more generic layer, like the servlet layer ? That would be very common for almost all (java) web frameworks How could it be standardized at Servlet level? Adding URL parameters (like jsessionid), but that wouldn’t be URL copy-paste proof when opening a tab… or cookies? Those can disabled by the browser…

Why not just adding a raw API for “conversations” to the Servlet layer? No implementation at all. JSF (and others) could (not have to) provide an implementation of this… That would mean all these framework kinda use the same (common) API, but everybody solves the issue on its own.
(sure, when this part of Servlet 3.0 there is still an issue with the adoption, but a Servlet 3.0 adoption isn’t an elephant like WebBeans)

Funny enough, the Orchestra library already has an abstract FrameworkAdapter, that provides access to all the data necessary for Orchestra to work while isolating Orchestra from the actual UI presentation framework being used.

I think it would be good if a similar thing is provided by the Servlet layer. JSF (or other web frameworks) could just offer the implementation, if they want…

I really hope conversations somehow make it into the java web land….

It has been a while, since we got the last Trinidad release (August 2008). Today, there were two new releases:

• Trinidad 1.2.10: A JSF 1.2 component library (and more)
• Trinidad 1.0.10: A JSF 1.1 component library (and more)

Both are mostly identically, however the 1.2.10 contains some more fixes that were made to the core (JSF 1.2 related).

You will find the release notes here:

• for 1.0.10
• for 1.2.10

The download page will be updated soon and the bits are already available via the maven repositories.

Have fun!