Showing posts with label jsf. Show all posts
Showing posts with label jsf. Show all posts
Monday, December 11, 2006
JSF to XHTML to SVG or PDF
I haven't looked at JSF since 2004 where I thought it would be cool to combine Swing and JSF. Coming back to JSF after nearly two years I came across, Combine JSF Facelets and the Flying Saucer XHTML Renderer which takes XHTML content and rendered it using Swing this is then transformed into an image, PDF or SVG. In the past I've used iReport and directly iText to generate reports (PDF and Excel). The thing at the back of my mind is always, this seems to be reproducing a lot of what HTML does and people only really want PDF because it prints well and Excel because they have macros. Until there are macros built into browsers to do manipulation of data that is.
Tuesday, January 20, 2004
Combine Two Technologies
Like putting a clock in an existing product I keep thinking of combining an XML Swing library with JSF. It would be nice to use JSF as a way to provide the abstraction for differing rendering technologies (this was the first thing I thought when I saw JSF). This interview had some interesting bits of information on this:
"One of the unique things about Faces is that it allows you to have separate classes for rendering a UI component. So a simple text box can consist of a UIInput component, which represents the concept of collecting user input, and a Text renderer, which knows how to display a textbox in HTML. You can create separate renderers for different types of clients -- one for HTML, one for SVG, and one for WML, for example...the third-party component market will continue to grow, not just with HTML components (which will be first), but also components and renderers that support other devices and richer clients."
"There's a sample in the current Faces early access release of XUL instead of JSP, but I think more work needs to be done to prove that other display technologies can really be first-class citizens."
"JavaServer Faces is also a good technology for thin client applications that aren't HTML-based. I've mentioned WML, but you could also write a Java applet application, or some other non-browser client that works with JSF. We'll see these types of applications evolve over time.
Personally, I think fat clients are great for some applications, like RSS News Readers. But web applications are great for other things, and JSF is a good way to build those types of applications. "
The latest download includes XUL in the non-JSP examples.
"One of the unique things about Faces is that it allows you to have separate classes for rendering a UI component. So a simple text box can consist of a UIInput component, which represents the concept of collecting user input, and a Text renderer, which knows how to display a textbox in HTML. You can create separate renderers for different types of clients -- one for HTML, one for SVG, and one for WML, for example...the third-party component market will continue to grow, not just with HTML components (which will be first), but also components and renderers that support other devices and richer clients."
"There's a sample in the current Faces early access release of XUL instead of JSP, but I think more work needs to be done to prove that other display technologies can really be first-class citizens."
"JavaServer Faces is also a good technology for thin client applications that aren't HTML-based. I've mentioned WML, but you could also write a Java applet application, or some other non-browser client that works with JSF. We'll see these types of applications evolve over time.
Personally, I think fat clients are great for some applications, like RSS News Readers. But web applications are great for other things, and JSF is a good way to build those types of applications. "
The latest download includes XUL in the non-JSP examples.
Subscribe to:
Posts (Atom)