|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 128
Messages: 128
Messages: 128
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
Facelets fits JSF like a glove
Trying to combine JSF and JSP is like trying to shoehorn a foot into a glove: it's possible, but not pleasant. This article introduces developers to Facelets' easy HTML-style templating and reusable composition components that fits JSF like a glove.
While working on a JavaServer Faces (JSF) project recently, I had the pleasure of using Facelets for the first time. What I most liked about Facelets was that it let me create reusable composition components. Being able to take a page (like a JSP) and turn it into a component has been a real boon to my JSF development ever since. My conclusion? If you're not using Facelets, you're not getting the most you can out of JSF.
The mismatch between JSF and JavaServer Pages technology is a serious problem in JSF development. The issue is how to integrate JSP's dynamic content into JSF's component-based model. JSP is singularly focused on generating dynamic output, whereas JSF requires JSP to coordinate building a component model. The disjunct occurs because that task is beyond the original intention of JSP.
Most JSF developers simply learn to navigate such problems on an ad-hoc basis, but that's kind of like duct-taping a pillow to a hammer so it won't hurt coming down on your head. Facelets is a much more comprehensive solution: a templating language that is geared toward the JSF component model.
Facelets fits JSF like a glove.
Have you tried Facelets?
Have you compared the Facelets approach to other technologies like Tapestry?
|
Threaded replies
| · |
JSFU
by
U G
on Sat Feb 25 02:17:44 EST 2006
|
|
|
Message #201852
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
RE: Spec?
Facelets does not part of JSF spec but may be part of future versions of spec.
Facelets does not supported officialy by any vendor, but as Jackob Hookom states facelets developed under Sun's guidance.
(no sign of IBM (AFAIK))
|
|
|
Message #201855
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Spec?
Are facelets part of the JSF spec? Is it support by any other vendors besides IBM?
Like many great technologies (Hibernate, Spring, Tiles, WebWork), Facelets is not part of the official spec.
I think Facelets will impact future JSF specs. (Maybe even JSP). But this is just speculation.
Facelets is very useful. And component composition is a big boon to JSF development.
|
|
|
Message #201857
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Spec?
I'm very interested in feedback (good and bad). Rick's article already seems to have encouraged some new ideas within the users lists, which is excellent. Overall, the article is very fair in highlighting Facelets features while properly explaining current limitations.
|
|
|
Message #201858
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Is Facelets production ready?
Facelets depencs on JSF 1.2 and JSP 2.1.
You can read that Faclets can work with MyFaces, but only if you use some jars from JSF 1.2/JSP 2.1 implementation from Glassfish project. Too trickly for me.
Facelets is promising technology and I will consider Facelets for new projects, but after my favorite Java EE implementation upgrades to Java EE 5.
Nebojsa
|
|
|
Message #201859
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Still too much JSP
I had hopes for this article in that it promised less JSP for JSF.
Right. Total failure on that front from what I can tell. Tags everywhere, with the added bonus of a templating syntax on top of the tag pollution.
I will not take JSF seriously until they abandon JSP and taglibs, or fix JSPs and the EL. Tapestry uses OGNL, a much better templating/data access language.
Am I the only person who hates taglibs and the EL?
|
|
|
Message #201860
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Still too much JSP
Those are not jsp tags. They are jsf tags. The syntax is similar, which you seem to have a problem with. I agree with the author in that those of us that have been doing web development with jsp and jstl with whatever framework, jsf with facelets will be easier to pick up than say something like tapestry. I inherited a tapestry app at my current job, and I don't like it. jsf seem more intuitive to me. But this is all opinion. Use whatever you are comfortable with.
As far as how good facelets it, I'll have an opinion in a couple of months. I'm starting a new application in the coming weeks, and I've decided to use jsf with with facelets.
|
|
|
Message #201861
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Is Facelets production ready?
Facelets depencs on JSF 1.2 and JSP 2.1. You can read that Faclets can work with MyFaces, but only if you use some jars from JSF 1.2/JSP 2.1 implementation from Glassfish project. Too trickly for me.Facelets is promising technology and I will consider Facelets for new projects, but after my favorite Java EE implementation upgrades to Java EE 5.Nebojsa
I don't think this is true. I've read on the user list for facelets that most seem to be using Facelets 1.0.7 with MyFaces 1.1.1...
|
|
|
Message #201863
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
and we need gloves in canada..
I found facelets when I was evaluating JSF and about to give up and go back to struts.. facelets addressed all my major concerns with JSF and made UI development fun again :)
my three favourite things about facelets are:
1) facelets makes custom component, validator and converters development quick, easy and fun.. which is the only way component-based ui technology is going to succeed
2) although tiles is good, IMO, facelet's templating is better.. (and still improving)..
3) you can mix and match jsf, jstl and plain html tags.. this is especially useful for creating custom components without writing any java code
also, I think it should be mentioned that you can't beat the support on the user dev list.. props to the facelets crew for that!
james
|
|
|
Message #201864
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: and we need gloves in canada..
I think it should be mentioned that you can't beat the support on the user dev list.. props to the facelets crew for that! james
+1 for that. I've been subscribing to the list for a couple of weeks now and find that Jacob Hookom, who is the main Facelets developer and member of the JSF expert group I believe, posts responses daily to user problems.
They are very responsive...
|
|
|
Message #201867
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Facelets fits JSF like a glove
Trying to combine JSF and JSP is like trying to shoehorn a foot into a glove If you are Java man (as in prehistoric), putting a glove on your foot is easy and might even seem natural. But for those of us who are more evolved, it is a painful experience. :) Me? I think I am beyond even needing to put gloves on my hands. ;)
|
|
|
Message #201868
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: MyFaces and Facelets
Facelets depencs on JSF 1.2 and JSP 2.1. You can read that Faclets can work with MyFaces, but only if you use some jars from JSF 1.2/JSP 2.1 implementation from Glassfish project. Too trickly for me.Facelets is promising technology and I will consider Facelets for new projects, but after my favorite Java EE implementation upgrades to Java EE 5.Nebojsa I don't think this is true. I've read on the user list for facelets that most seem to be using Facelets 1.0.7 with MyFaces 1.1.1...
You're right, Frank. I have used MyFaces and Facelets and it works just fine. It's also not a very complicated feat.
---
Kito D. Mann
Author, JavaServer Faces in Action
http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info
|
|
|
Message #201869
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: IDE Support
Facelets does not part of JSF spec but may be part of future versions of spec.Facelets does not supported officialy by any vendor, but as Jackob Hookom states facelets developed under Sun's guidance.(no sign of IBM (AFAIK))
Actually, Exadel Studio Pro has had Facelets support for some time. You can also get some IDEs to support to (unofficially) support the tags.
Hopefully we'll se others on the bandwagon soon. I've talked to people at BEA and IBM about it. (Oracle's ADF Faces, by the way, works with Facelets as well).
---
Kito D. Mann
Author, JavaServer Faces in Action
http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info
|
|
|
Message #201870
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Is Facelets production ready?
I mentioned in another post that Facelets works fine with MyFaces, but I wanted to address the topic of Facelets being production ready. The answer is definitely yes. Lots of people are using it (see the mailing list), and I'm using it for parts of JSF Central (JSP is in use as well). Facelets has been stable for quite some time.
---
Kito D. Mann
Author, JavaServer Faces in Action
http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info
|
|
|
Message #201873
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Still too much JSP
As said, it's not JSP tags at all. You're also completely free to use nothing but HTML with the jsfc attribute:
<input type="text" jsfc="h:inputText" value="#{hello.world}" />
For EL vs. OGNL, Facelets only uses the EL API - it has no dependencies on the EL syntax per se - and the EL APIs go through an ExpressionFactory that's replaceable. An OGNL fan should be able to code an ExpressionFactory that routes through OGNL, then you'd have Facelets + JSF using OGNL. (I've personally never been that concerned with this: yeah, OGNL has more features, I usually find EL sufficiently rich for my needs.)
|
|
|
Message #201874
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Is Facelets production ready?
Yep, it certainly feels production ready. One aspect not consistently mentioned is that it's also faster than JSPs, both at development and deployment time. At development, it's not producing a .class file, so there's no interminable waiting for the translation/compiler process. And at deployment time, our internal benchmarks have shown very promising improvements in performance/scalability, due to the much more optimized page assembly process (the Facelet counterpart to a JSP Tag object is cached and reused instead of recreated on each request).
|
|
|
Message #201875
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re:L Still too much JSP
I had hopes for this article in that it promised less JSP for JSF. Right. Total failure on that front from what I can tell. Tags everywhere, with the added bonus of a templating syntax on top of the tag pollution.
As someone else pointed out, Facelets supports the same tag syntax as the JSF JSP tags, but it's definitely not JSP. Facelets also supports a Tapestry-style syntax that doesn't use these tags.
I will not take JSF seriously until they abandon JSP and taglibs, or fix JSPs and the EL. Tapestry uses OGNL, a much better templating/data access language. Am I the only person who hates taglibs and the EL?
Have you looked at JSF 1.2 and JSP 2.1? We fixed all of the JSP issues that plagued previous releases. There was even a group specifically dedicated to this task. As a result of that effort, the EL has been broken out into its own package, and might be handled through a separate JSR in the future. (The EL itself has improved as well.)
Also, note that JSF _not_ require JSP, as Facelets and Struts Shale's Clay show.
---
Kito D. Mann
Author, JavaServer Faces in Action
http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info
|
|
|
Message #201877
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Series of articles about Facelets
FYI, there is a series of articles by Jacob Hookom (Facelet's creator) at JSF Central. It starts with an intro and describes different sets of features, so it's great to read if you're new to the technology.
---
Kito D. Mann
Author, JavaServer Faces in Action
http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info
|
|
|
Message #201887
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Still too much JSP
Am I the only person who hates taglibs and the EL?
No, I hate them too. It started when I discovered JSTL EL was a little different from JSF EL. That such a thing could ever happen says a lot.
|
|
|
Message #201888
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Still too much JSP
Am I the only person who hates taglibs and the EL? No, I hate them too. It started when I discovered JSTL EL was a little different from JSF EL. That such a thing could ever happen says a lot.
That was another JSP vs. JSF decision, but now the new EL-API will be a separate spec and is #{..} vs. ${..} agnostic. Example, Facelets can use either interchangably-- doesn't care. Actually, as Adam noted, Facelets doesn't care what EL implementation you use, so you could provide an OGNL or JS or C# EL implementation and use it with JSF 1.2 and Facelets. In relation to the previous TSS article on the new Script JSR, the EL API is much more robust with ELResolver chains and variable resolution for customizing concerns. You can with JSF, include a JBoss Seam variable resolver alongside a Spring variable resolver (although you may end up opening a rift in space that will consume us all).
Anyways, now that the EL-API is separate (javax.el.*), we can take a look at evolving the EL semantics w/ projections and method invocation.
|
|
|
Message #201890
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: MyFaces and Facelets
Facelets depencs on JSF 1.2 and JSP 2.1. You can read that Faclets can work with MyFaces, but only if you use some jars from JSF 1.2/JSP 2.1 implementation from Glassfish project. Too trickly for me.Facelets is promising technology and I will consider Facelets for new projects, but after my favorite Java EE implementation upgrades to Java EE 5.Nebojsa I don't think this is true. I've read on the user list for facelets that most seem to be using Facelets 1.0.7 with MyFaces 1.1.1...
You're right, Frank. I have used MyFaces and Facelets and it works just fine. It's also not a very complicated feat.---Kito D. Mann Author, JavaServer Faces in Actionhttp://www.JSFCentral.com - JavaServer Faces FAQ, news, and info
Please, give me a reference to detailed description how to setup Tomcat+MyFaces+Facelets.
Section on MyFaces setup in Facelets documentation is short:
"Apache MyFaces has it's own version of the JavaServer Faces API included in its distribution. Currently, Apache MyFaces is only up to the 1.1 specification, but has not yet passed the TCK."
After that you can read that Facelets depends on JSF 2.0 API and some parts of JSF 2.0 implementation.
There is a lot of peope on e-mail list who mention they use MyFaces, but I haven't found clear answer hot to set it up myself.
Nebojsa
|
|
|
Message #201892
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
We need a major refactoring of all this shit, especially config
I was working with a dedicated, intelligent junior Java programmer the other day to get a JAAS login page to work in a Web app that used JSF. I had read the JSF 1.1 spec and almost puked, then avoided dealing with JSF except to work minimally within it (around it, really) implementing some DHTML menus for some of our apps.
So I am trying to suss out how the hell to get the web.xml and faces-config.xml cooperating. Things like welcome pages and authentication elements in web.xml seem to have no friendly counterpart in the faces-config.xml. I noticed our TLD file sitting there in the WEB-INF. I've worked with Servlets and JSP almost since the beginning. There's this mountain of stuff that the JCP keeps dropping on us and it is all so poorly integrated, refactored, reduced.
People aren't going to give up on JSF, JSP, Myfaces, etc. No. People are just going to be forced to look elsewhere for a new solution that takes all this crap and spits out a neat, condensed framework that does the same thing. And the JCP will be forced to chase behind it and crown it the canonical solution eventually. And then, sure enough, given the oligarchic and aristocratic nature of the JCP, they'll build on it and make another big mess.
Ahh, that feels better. Screw JSF. It's a pile of crap.
|
|
|
Message #201894
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
We need a major refactoring of all this shit, especially config
Fair is fair :-) The JAAS stuff is a dissapointment, but Kito has covered how to do this in his writings on JSF.
You could say the same thing about going from a simple JDBC Rowset to a full blown ORM with lazy/proxy configuration, etc. Yeah, it can be a pain to get up and running, but people do so because it will make app maintenance easier down the road.
In applicable terms, Action frameworks are pretty lightweight to get up and running, but as your requirements ramp up within the UI and managing state, then choosing JSF/component frameworks makes more sense. I've been yanked through the coals on a different project, trying to coordinate the state of sortable tables, filtered data, with assorted forms. I did it, but it's a custom solution that with a JSF component/state management, for which I wouldn't have needed to concern myself with or anyone else's time. There's that 'drop in factor' with components in a lot of the new frameworks.
|
|
|
Message #201897
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Facelets fits JSF like a mask
Is it just me or does mixing Facelets and gloves seem wrong to you? How about "Facelets fits JSF like a mask"? Or "Facelets, like putting lipstick on a JSF"? "Facelets the facts, its JSF"?
|
|
|
Message #201898
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Spec?
Like many great technologies (Hibernate, Spring, Tiles, WebWork), Facelets is not part of the official spec.
Sorry Rick I didn't mean that it needed to be part of a spec to be useful or considered. I was just wondering where facelets stood.
I am really looking forward to JSF, but am not very happy with the JSP implementation of it currently, so I'm hoping that a better implementation comes a long soon. Facelets may be what I'm looking for. I will have to give them a try.
|
|
|
Message #201905
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Still too much JSP
Am I the only person who hates taglibs and the EL? No, I hate them too. It started when I discovered JSTL EL was a little different from JSF EL. That such a thing could ever happen says a lot.
I think the most anoying thing about taglibs , el and markup templates in general is that they break OO semantics. I dont mean to be negative about facelets but I prefer to work with a GUI API that generates HTML. What is wrong with that, why do we use templates? Is eclipse build with markup templates? Or are am i just an api person and are most developers template people?
|
|
|
Message #201906
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
portlets? creator? oscache?
Does anybody know if Facelets works seemlessly with portlets? How about IDE support from Netbeans or Creator? Creator has a great visual editor - it'd be fantastic if it could generate facelets markup.
Finally, is it possible to reuse existing JSP libraries such as OSCache?
/me heads over to join the mailing list
|
|
|
Message #201907
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Still too much JSP
Am I the only person who hates taglibs and the EL? No, I hate them too. It started when I discovered JSTL EL was a little different from JSF EL. That such a thing could ever happen says a lot.
I think the most anoying thing about taglibs , el and markup templates in general is that they break OO semantics. I dont mean to be negative about facelets but I prefer to work with a GUI API that generates HTML. What is wrong with that, why do we use templates? Is eclipse build with markup templates? Or are am i just an api person and are most developers template people?
http://www.jsfcentral.com/articles/facelets_3.html
|
|
|
Message #201908
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Is Facelets production ready?
Like a recent politician, I am going to say the following: It depends on what you mean by production ready.
I've had some issues working with older versions of MyFaces (1.1.1). It seems to work with the latest version of Facelets, you need to work with the latest nightly build of MyFaces.
You can use Facelets (not recent version) with MyFaces 1.1.1, but then you don't get some of the bug fixes in the latest release.
I am using MyFaces 1.1.1 and Facelets 1.0.7 in app that should go into production in March. It works well enough for our needs.
|
|
|
Message #201909
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
portlets? creator? oscache?
Does anybody know if Facelets works seemlessly with portlets? How about IDE support from Netbeans or Creator? Creator has a great visual editor - it'd be fantastic if it could generate facelets markup.Finally, is it possible to reuse existing JSP libraries such as OSCache?/me heads over to join the mailing list
The issues is not Facelets. The issue is what Portlet JSF bridge are you going to use.
Facelets should work anywhere JSF works. I had no issues getting Facelets to work in Portlets.
|
|
|
Message #201910
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
portlets? creator? oscache?
Does anybody know if Facelets works seemlessly with portlets? How about IDE support from Netbeans or Creator? Creator has a great visual editor - it'd be fantastic if it could generate facelets markup.Finally, is it possible to reuse existing JSP libraries such as OSCache?/me heads over to join the mailing list The issues is not Facelets. The issue is what Portlet JSF bridge are you going to use.Facelets should work anywhere JSF works. I had no issues getting Facelets to work in Portlets.
I recant. Facelets should work anywhere MyFaces and JSF RI 1.2 work.
|
|
|
Message #201911
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Facelets fits JSF like a mask
Is it just me or does mixing Facelets and gloves seem wrong to you? How about "Facelets fits JSF like a mask"? Or "Facelets, like putting lipstick on a JSF"? "Facelets the facts, its JSF"?
Cute. Have you tried Facelets? Did you get a chance to read the article?
JSF is the most productive web app API that I have used. Facelets makes it a lot more productive.
We have compared older apps to newer apps with a framework (developed internally) that utilizes Facelets. We saw drastic reduction in code. Composition Components are sweet.
|
|
|
Message #201912
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Still too much JSP
Those are not jsp tags. They are jsf tags. The syntax is similar, which you seem to have a problem with. I agree with the author in that those of us that have been doing web development with jsp and jstl with whatever framework, jsf with facelets will be easier to pick up than say something like tapestry. I inherited a tapestry app at my current job, and I don't like it. jsf seem more intuitive to me. But this is all opinion. Use whatever you are comfortable with. As far as how good facelets it, I'll have an opinion in a couple of months. I'm starting a new application in the coming weeks, and I've decided to use jsf with with facelets.
It does look a bit like JSP, but it is not. There were no JSP tag files. JSF is natively supported by Facelets, you don't need taglibs. The articled focused on templates and composition components, and there is a lot more to Facelets than that.
To me, composition components are the most compelling aspect of Facelets.
You should check out the articles that Jacob wrote over at JSF central to give you a more balanced view of the technology.
Here is an example how to render an employee form from a framework that I have been working on.
<q:form crud="#{EmployeeCRUD}" focusField="lastName">
<q:fields fieldNames="firstName,lastName,phone,current,birthDate,startDate"/>
<q:checkBoxes fieldName="roles" />
<q:dropdown fieldName="department" />
<q:list fieldName="group" />
</q:form>
The above form renders Tomahawk Calendar component for birthDate and startDate. It renders related objects for editng as well. (Employee is in a department. Employee has many Roles. Employee is in a group. Etc.).
The equiv. plain JSF/JSP would be a bit verbose. The real value add of Facelets (IMO) is the ability to define composite components (fields, checkBoxes, dropDown, list, form). This means that editing the Look and Feel for fields is in one place (you can break out anytime you want and mix and match components with composite components) the same for a standard form, etc. etc.
|
|
|
Message #201918
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Facelets fits JSF like a mask
Is it just me or does mixing Facelets and gloves seem wrong to you? How about "Facelets fits JSF like a mask"? Or "Facelets, like putting lipstick on a JSF"? "Facelets the facts, its JSF"? Cute. Have you tried Facelets? Did you get a chance to read the article?JSF is the most productive web app API that I have used. Facelets makes it a lot more productive.We have compared older apps to newer apps with a framework (developed internally) that utilizes Facelets. We saw drastic reduction in code. Composition Components are sweet.
Totally agree, working with JSF after 2 or 3 years of Struts is very refreshing.
|
|
|
Message #201935
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Facelets fits JSF like a mask
And facelets of course!
Good to know. I thought you were more of a detractor. I didn't get (understand) the mask comment.
I would never guessed that you were a fan. Good to know. Thanks.
|
|
|
Message #201936
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Is Facelets production ready?
Like a recent politician, I am going to say the following: It depends on what you mean by production ready.
In my case "production ready" means "ready do decide to use Facelets in all new projects". It is stronger then "ready to use it in the specific project".
To decide to use Facelets in all new projects, you are concerned about all possible issues, but in the specific project you are not concerned about issues you can work around or resolve on ad hoc bases in this project.
I've had some issues working with older versions of MyFaces (1.1.1). It seems to work with the latest version of Facelets, you need to work with the latest nightly build of MyFaces.You can use Facelets (not recent version) with MyFaces 1.1.1, but then you don't get some of the bug fixes in the latest release.
It just desn't look like production ready IMO.
As I understand you have to put JSF 1.2 API from RI an JSF 1.1 implementation from MyFaces in the same application!
Morever you, if you dont run on JSP 2.1 enabled container, you have to add JSP 2.1 EL API and implementation from Glassfish projec on servlet 2.3 containter (JSP 2.1 depends on servlets 2.4).
It is realy too trickly for me, sory. And BTW, JSF 1.2 RI and Glassfish are in beta.
This configuration may run Facelets somehow, I will not put my business to depend on it.
Please don't misunderstand me, I like Facelets and I want to use it, but I just want to be clear abaut current state of Facelets and issues.
Early addopting of JSF was painful for me and I am not sure is Facelets solution for painless JSF or anather painful early addopting.
Also I need to reuse some JSP views and plain JSP pages even if I use Facelets.
I am using MyFaces 1.1.1 and Facelets 1.0.7 in app that should go into production in March. It works well enough for our needs.
What servlet container/app server do you use?
Nebojsa
|
|
|
Message #201937
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Facelets fits JSF like a glove
In our company, we hav walked trough many aspect of java/web applications for 6 years:
- Started with servlets
- went to jsp
- a "rapid" approach on struts
- use of the first RI of JSF
- and after all, adopt facelets
When we've started to work on Struts, JSF was coming out, so we took the choice to go ahead, and jump over Struts.
We succeed on a first project with jsf ri 1.0, and after that have developed many application on jsf myFaces.
But, we found JSF very to capitalize and reuse, with lot of "core" java development, not fitting to a rapid application development paradigm, with high productivity level.
Discovering facelets on last summer (at its born I think), I was convicted on its benefits.
We gave us a few month to study it, waiting stabilization in the release, developing some tests applications.
Documentation is light, but it's because Facelets are easy to understand...
My fear was to see this project falling down, but with Jacob's great job and all the others "gurus" contributors, I feel secured.
Now, since the beginning of the year, we use it as a base part of development tooling, in conjonction with hibernate 3, with no JSP.
A fist production project is on the run, and my conclusions are clear :
- Facelets provide less code effort.
- Facelets give ability to capitalize and reuse.
- Code architecture is more intuitive.
- Many perspectives, tooling (Exadel and others), Rich Client (XulFaces)...
I don't know if Facelets fits JSF like a glove, but it keeps my development team hands in a cold and comfortable place.
|
|
|
Message #201938
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Facelets fits JSF like a glove
I think Facelets is a great way to develop webapps ... just write your html code and your fancy js for your "cool" ui and test it.... and then just add your jsfc attributes. Developing your own component is easy too.
But there is one thing i could not figure out: How do i use Ajax with Facelets? Could not find any examples on that. Especially important for me is partial rendering of components (like http://smirnov.org.ru/en/ajax-jsf.html).
any suggestions?
|
|
|
Message #201942
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Does anybody compared facelets to shale-clay?
I did not yet used facelets, but I have been using shale-clay and it's very helpful for my project. Specially composition component like below.
<strong>In component definition XML</strong><component jsfid="inputPanel" extends="panelGrid">
<attributes>
<set name="columns" value="2"/>
<set name="styleClass" value="inputStyle" />
</attributes>
<element jsfid="ouputText">
<attributes>
<set name="value" value="@label"/>
<attributes>
</element>
<element jsfid="inputText"
id="username">
<attributes>
<set name="required" value="true"/>
<set name="value" value="#{@inputValue}"/>
<set name="validator" value="#{@inputValidate}"/>
</attributes>
</element>
</component> <strong>In html file</strong> <span jsfid="inputPanel" label="User name: " inputValue="UserManager.userName" inputValidate="ManagedBean.validate"/> @ is symbol and you can redefine symbol's value in html or component definition. You may use html as tiles like template or use jsp instead of html.Shale is under development but I think clay is very useful inspite of some minor issue:
Clay component cannot specify RendererType, so default renderer type is used. And html view show somewhat low performance compared to JSP. I like to know an advantage of facelets compared with clay.
|
|
|
Message #201950
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Facelets fits JSF like a mask
JSF is the most productive web app API that I have used. Facelets makes it a lot more productive. Isn't it a contradiction? If Facelets makes it a lot more productive then JSF can't be the most productive API :-)
|
|
|
Message #201954
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Facelets fits JSF like a mask
JSF is the most productive web app API that I have used. Facelets makes it a lot more productive. Isn't it a contradiction? If Facelets makes it a lot more productive then JSF can't be the most productive API :-)
No. Even the most productive API can be made more productive, as nothing - not even JSF - is perfect :)
|
|
|
Message #201955
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Facelets fits JSF like a mask
Isn't it a contradiction? If Facelets makes it a lot more productive then JSF can't be the most productive API :-) No. Even the most productive API can be made more productive, as nothing - not even JSF - is perfect :)
A very productive API can, the most productive API can't by definition. People tend to exaggerate.
OT: I'm dissappointed by the fact that TSS still doesn't have the post preview functionality.
|
|
|
Message #201961
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Facelets fits JSF like a mask
Is it just me or does mixing Facelets and gloves seem wrong to you? How about "Facelets fits JSF like a mask"? Or "Facelets, like putting lipstick on a JSF"? "Facelets the facts, its JSF"?
The correct understanding of what is going on here is to go back to the original requirements for JSF 1.0, which said (among other things) that it needed to be usable with or without JSP. Surprise, surprise, we actually delivered on that.
Don't miss the most critical point -- the components themselves have *NO* knowledge of what view persistence technology you are using in a particular app. The same components that work in a JSP-based app for me can work in a Facelets-based or Clay-based app for you.
Craig McClanahan
|
|
|
Message #201962
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Facelets fits JSF like a mask
Isn't it a contradiction? If Facelets makes it a lot more productive then JSF can't be the most productive API :-) No. Even the most productive API can be made more productive, as nothing - not even JSF - is perfect :)
A very productive API can, the most productive API can't by definition.
So, if a racer is the fastest, he could not improve and become faster becuase then he wouldn't be the fastest? Me thinks something be lost in the translation.
|
|
|
Message #201970
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
The fastest racer (or not?)
So, if a racer is the fastest, he could not improve and become faster becuase then he wouldn't be the fastest? Me thinks something be lost in the translation. After the racer gets faster she is still the same racer. But when we add something to an API, we get other API. An API is sort of immutable object. And if the new API is more effective than the old then the old can't have been the most effective. Maybe I'm theorizing a bit.
|
|
|
Message #201971
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Does anybody compared facelets to shale-clay?
...You may use html as tiles like template or use jsp instead of html.Shale is under development but I think clay is very useful inspite of some minor issue:Clay component cannot specify RendererType, so default renderer type is used. And html view show somewhat low performance compared to JSP. I like to know an advantage of facelets compared with clay.
There are a few things:Facelets benchmarks faster than JSP for JSF use (~14% faster) Tag properties are auto-wired to Components/Validators/Converters, throwing out the majority need to write special Tags or XML configs. It's built on the new EL API and Expressions passed to UIComponents will actually report the attribute and line number they came from (here).
I have my own opinions too on Clay's extra configuration with component/attribute/element. I prefer just explicitly fragmenting component (or composite) content and using straight EL for @XXX replacement instead.
<ui:composition>
<h:panelGrid columns="2" styleClass="inputStyle">
<#{label}
<h:inputText ... value="#{inputValue}">
<ui:insert/>
</h:inputText>
</h:panelGrid>
</ui:composition>
Can be used like:
<my:username label="me" value="#{me.name}">
<my:validateRegex pattern="\w+"/>
</my:username>
(I hope all of the formatting comes through)
|
|
|
Message #201998
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
ICEfaces = JSF + Ajax (Incl. Facelets)
<snip>...How do i use Ajax with Facelets? Could not find any examples on that. Especially important for me is partial rendering of components (like http://smirnov.org.ru/en/ajax-jsf.html). any suggestions?
There are several approaches to incorporating Ajax in JSF projects.
For example, Sun Studio Creator 2 has a set of example JSF components that incorporate Ajax: http://developers.sun.com/prodtech/javatools/jscreator/reference/fi/2/ajax.html
The ICEfaces JSF component suite uses another approach that provides many of the benefits of Ajax-enabled web applications without the need to develop in Javascript at all. Essentially, ICEfaces isolates the application developer from having to author the client-side content directly (HTML, CSS, JavaScript). Instead, applications are written using Java JSF components and supporting framework using either JSP or Facelets and standard industry IDEs. Client-side behaviors normally written in JavaScript can be configured, customized, etc. using the Java API provided by ICEfaces, exposed through the JSF components.
Key benefits are:
* Smooth, incremental page updates with in-place editing and no full page refresh.
* Asynchronous page updates driven from the application in real time. (Server-push without polling)
* Fine-grained user interaction during form entry that augments the standard submit/response loop.
* No need to author complex JavaScript or test and tailor your content for multiple browser versions, etc.
The current release is Alpha 0.3. The upcoming Beta release (late March) will add support for Facelets as well as additional rich components (Menu, AutoComplete, etc.), and "cinematic effects/animations" and Drag and Drop support.
Online demos are available here: http://www.icesoft.com/products/demos_icefaces.html
The complete ICEfaces Alpha release is also available for free download and distribution if you'd like to check it out: http://www.icesoft.com/downloadA.html
IMHO the conflux of JSF, Ajax, and Facelets is the "perfect storm" for revolutionizing rich web application development in Java.
----
Ken Fyten
ICEfaces Product Manager
ICEsoft Technologies
|
|
|
Message #202011
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
We need a major refactoring of all this shit, especially config
Here's a quick way to do authentication and annotation-driven, role-based authorization in Wicket (there are more flexible ways to do this as well):
public class MyAuthenticatedWebApplication extends AuthenticatedWebApplication
{
public static class MyAuthenticatedWebSession extends AuthenticatedWebSession
{
private boolean signedIn;
public MyAuthenticatedWebSession(AuthenticatedWebApplication application)
{
super(application);
}
public boolean authenticate(String username, String password)
{
return signedIn = username.equals("jonathan") && password.equals("jonathan");
}
public boolean isSignedIn()
{
return signedIn;
}
public Roles getRoles()
{
if (signedIn)
{
return new Roles("ADMIN");
}
return null;
}
}
protected Class< ? extends AuthenticatedWebSession> getWebSessionClass()
{
return MyAuthenticatedWebSession.class;
}
protected Class< ? extends SignInPage> getSignInPageClass()
{
return SignInPage.class;
}
public Class getHomePage()
{
return HomePage.class;
}
}
public class HomePage extends WebPage
{
}
<html>
<head>
<title>HomePage</title>
<link rel="stylesheet" type="text/css" href="style.css"/>
</head>
<body>
<h2>Welcome!</h2>
This page should be accessible to everyone.
<wicket:link><a href="AdminPage.html">Admin Page</a></wicket:link><br/>
<wicket:link><a href="SignOutPage.html">Sign Out</a></wicket:link>
</body>
</html>
@AuthorizeInstantiation("ADMIN") // Require "ADMIN" roled to instantiate this page
public class AdminPage extends WebPage
{
}
<html>
<head>
<title>AdminPage</title>
<link rel="stylesheet" type="text/css" href="style.css"/>
</head>
<body>
<h2>Welcome ADMIN!</h2>
This page should only be accessible if you are signed in as an administrator.
<wicket:link><a href="HomePage.html">Home</a></wicket:link><br/>
<wicket:link><a href="SignOutPage.html">Sign Out</a></wicket:link>
</body>
</html>
public final class SignInPage extends wicket.authentication.SignInPage
{
}
<html>
<head>
<title>SignInPage</title>
<link rel="stylesheet" type="text/css" href="style.css"/>
</head>
<body>
<h2>Sign In</h2>
<i>Username and password are both "jonathan"</i>
<span wicket:id="signInPanel"/>
</body>
</html>
public class SignOutPage extends wicket.authentication.SignOutPage
{
}
<html>
<head>
<title>SignOutPage</title>
<link rel="stylesheet" type="text/css" href="style.css"/>
</head>
<body>
<h2>Goodbye!</h2>
<wicket:link>
<a href="HomePage.html">Home</a>
</wicket:link>
</body>
</html>
|
|
|
Message #202018
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
We need a major refactoring of all this shit, especially config
Nothing would stop a developer from doing the *exact* same artifacts with JSF, because JSF works directly with POJOs. Even with the new EL and plugable property/variable resolution, you could tie in Aegis or custom ActionListeners or PhaseListeners on the global level.
I agree with the original poster though that JAAS/Realms should've been tied into JSF directly, but within the JSF API itself, you can access principle/role information agnostically from a portlet or servlet deployment (see here).
Really though, thanks Jonathan for spamming yet another thread with lots of wicket code.
Yours, Jacob
|
|
|
Message #202020
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
We need a major refactoring of all this shit, especially config
Well, sorry about the code, but frankly talking about the code doesn't make my point. The truth of the matter is you can accomplish the exact same thing in JSP or assembly language. It's a matter of expressiveness, simplicity, legibility, intuitiveness and direct applicability to the problem. I ran screaming from JSP, JSF and Tapestry not because I wanted to go build something, but because I found that these technologies didn't cut it. If you'd like to see why, please post the /complete/ code for a JSF application demonstrating authentication and role based authorization (the above code is the ENTIRE application)... maybe I'm behind the times and it will be shorter, simpler, more legible and more intuitive than the code above, but I seriously doubt it.
|
|
|
Message #202024
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Still too much JSP
I think the most anoying thing about taglibs , el and markup templates in general is that they break OO semantics. I dont mean to be negative about facelets but I prefer to work with a GUI API that generates HTML. What is wrong with that, why do we use templates? Is eclipse build with markup templates? Or are am i just an api person and are most developers template people?
No, I'm with you all the way. Have you checked out echo2?
|
|
|
Message #202033
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Still too much JSP
I think the most anoying thing about taglibs , el and markup templates in general is that they break OO semantics.
Exactly. That's what I hate about frameworks (not just web frameworks) that focus on 'declarative' instead of old skool OO programming. While the declarative way sometimes can speed up development quite a bit, you'll often end up painting yourself in the corner because framework X didn't think of supporting case Y. Or you'll end up with a mess of functionality scattered throughout files that all have different sematics (and which your IDE might not understand, refactor, etc). And to overcome that, new frameworks are being build on top of that, which in the case of facelets DO make JSF a lot nicer to work with, but are imo still an admission of weakness in the first place. Stacking more frameworks makes it harder to understand what is happening under the hood, and it gets you more possible points of failure.
I dont mean to be negative about facelets but I prefer to work with a GUI API that generates HTML.
If you want to generate HTML, there's nothing wrong with templates imo. Let's you keep close to the source of things, and if you don't use that, you have to come up with abstractions (like a layout mechanism) which might distract you from your intended end result. However, sounds like Echo is a framework you'll like.
Or are am i just an api person and are most developers template people?
I don't think most developers are. It just seems like a lot of framework builders think it is the developer's holy grail to cancel out actual programming from the development process :)
|
|
|
Message #202034
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Still too much JSP
I don't think most developers are. It just seems like a lot of framework builders think it is the developer's holy grail to cancel out actual programming from the development process :)
This has been going on since LISP was in vogue back in the 1970s. There's this balancing act between code and data. Data-driven code can be really useful at times. But when you take it too far, you wind up making the data into code again (and usually a weaker version of the code too). The right balancing point to my eye seems to be making an extensible code-based framework where a few very specific and very limited problems are extended to be data driven.
|
|
|
Message #202035
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Still too much JSP
Like any feature, data-driving something should be use-case based and need-driven.
|
|
|
Message #202036
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Still too much JSP
And to overcome that, new frameworks are being build on top of that, which in the case of facelets DO make JSF a lot nicer to work with, but are imo still an admission of weakness in the first place. Stacking more frameworks makes it harder to understand what is happening under the hood, and it gets you more possible points of failure.
I don't think you really understand what JSF is. It's more of a platform than a framework. Not to play with terms but you are right in saying that there is a lot of plugability and flexability. The goal of this JSR is quite emense and overwhelming at times, but it's point is to provide a foundation that developers and vendors and use off the shelf or build upon. I look at what wicket is doing and what clay does, and I see a lot of similarities in that I can, with JSF, construct a component model in Java code and expose it via the binding attribute of all JSF components. Essentially, wickets scaffolding objects could be wrapped over JSF just as easily as JBoss Seam can delegate injection lifecycles and state coordination within the JSF platform.
In summary, I do like the focus that wicket presents, but a lot of the ideas could be implemented as a Java-centric facade on top of JSF as a platform and as part of the JEE 5 spec.
|
|
|
Message #202039
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Still too much JSP
I've obviously got my own personal issues going on here, but I'd like someone out there to understand why this concept just fundamentally doesn't work for me, even if they don't necessarily agree with me fully.
I believe that programming is a linguistic enterprise and that the whole point of building platforms and frameworks is not to provide mathematical abstractions by committee which are infinitely extensible and toolable, but to provide simple, highly refined abstractions that fully solve the problem at hand by leveraging language and what people already know about the world.
From my perspective, a really good /anything/ in programming tells a story and functions to a very high degree in terms of specific, carefully chosen language. That seems to have gotten lost somewhere along the way in programming... or maybe only dimly recognized in the first place.
The result for me as a programmer of today's corporate, committee-driven process is something like reading a novel written by the marketing team at a publishing company.
I would never be satisfied with Wicket written in JSF for this reason (if that's what you're suggesting). It's like saying "we've got this great drama", why don't you add some funny bits and ship it as a comedy? For me, a big part of Wicket has been trying to make the packages and classes and methods of the framework lead the programmer through the story of building a web application. It's not for me to say whether we accomplished this or not, but that is what we have been trying to do. I really do not get the same sense about JSF (just for example). Why that is, I don't precisely know. But for a counter-example, look at the collections classes. This is great stuff to me because it's so well thought out as a story. How things are organized and named and how things work forms a consistent and detailed narrative which anyone can pick up on immediately (at any scale). I wish other stuff in Java could be more like this. More like the old days when Java was new and telling a story with the JDK that made so much more sense than the available alternatives. We were going to take over the universe. What happened?
|
|
|
Message #202040
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Still too much JSP
More like the old days when Java was new and telling a story with the JDK that made so much more sense than the available alternatives. We were going to take over the universe. What happened?
We did take over.
|
|
|
Message #202042
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Still too much JSP
I don't think you really understand what JSF is. It's more of a platform than a framework.
I don't think you really understand how most developers are totaly not intersted in whether JSF is a framework or a platform when reading a line like: 'JavaServer Faces technology simplifies building user interfaces for JavaServer applications', which is the first line of SUN's description of JSF.
I look at what wicket is doing and what clay does, and I see a lot of similarities in that I can, with JSF, construct a component model in Java code and expose it via the binding attribute of all JSF components. Essentially, wickets scaffolding objects could be wrapped over JSF just as easily as JBoss Seam can delegate injection lifecycles and state coordination within the JSF platform.In summary, I do like the focus that wicket presents, but a lot of the ideas could be implemented as a Java-centric facade on top of JSF as a platform and as part of the JEE 5 spec.
I was deliberatly not mentioning Wicket in this thread, sorry it ended up here.
But... it is very interesting that you say that. In fact some people - including me - looked at whether/ how we could integrate with JSF. Not that anyone on the lists asked for it, but just to play nicely with the rest of java land. My conclusion was that the JSF is highly procedural in nature, and thus not a very good match with Wicket.
If you think we crappy programmers again didn't understand a thing about JSF, and you or someone else has a bit of spare time, please check out this feature request to investigate JSF interoperability. If you can write that within a month, I'll never bitch about JSF again :)
|
|
|
Message #202043
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Still too much JSP
More like the old days when Java was new and telling a story with the JDK that made so much more sense than the available alternatives. We were going to take over the universe. What happened? We did take over.
And who's helping that? 'You' didn't make my job nicer nor did you help me develop faster, more robust etc. Exactly those things that an API like collections did for me.
|
|
|
Message #202044
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Still too much JSP
More like the old days when Java was new and telling a story with the JDK that made so much more sense than the available alternatives. We were going to take over the universe. What happened? We did take over.
And who's helping that? 'You' didn't make my job nicer nor did you help me develop faster, more robust etc. Exactly those things that an API like collections did for me.
As someone who switched from Struts to JSF, I certainly found that JSF made my job nicer and helped me develop a lot faster. I am about to take a look at Facelets, and I expect - from the reports I have heard - that it will improve things even more.
Java makes even more sense than the alternatives these days than it did many years ago. I remember the time when it was was dead slow, and with buggy implementations on platforms such as Linux. Java when new was barely usable, as I remember things.
|
|
|
Message #202047
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Still too much JSP
My conclusion was that the JSF is highly procedural in nature, and thus not a very good match with Wicket.If you think we crappy programmers again didn't understand a thing about JSF, and you or someone else has a bit of spare time, please check out this feature request to investigate JSF interoperability. If you can write that within a month, I'll never bitch about JSF again :)
Heheh, if I didn't have so much on my plate right now, I might just take you up on that, hmmm.... ;-)
I am kind of struck by the comment that JSF is procedural. I have to disagree-- request/action frameworks feel more procedural than what our component frameworks are doing. I know we discussed this in Kito's W.A.G, but the 5 steps of MVC are common to all frameworks. You have components that encapsulate/participate in all phases of MVC, not just rendering. The lifecycle/controller of JSF only interacts with the top most root element of the view, allow it and all of its children to manage their own state and behavior. To me, this feels very OO. You could grab instances of JSF components and when you validate, you just call validate on them-- when you render, you just call render on them.
|
|
|
Message #202048
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Still too much JSP
I believe that programming is a linguistic enterprise and that the whole point of building platforms and frameworks is not to provide mathematical abstractions by committee which are infinitely extensible and toolable, but to provide simple, highly refined abstractions that fully solve the problem at hand by leveraging language and what people already know about the world.
Yes totally! I believe components are the building blocks of that functionality. We take known pieces of knowledge and development and then compose them into higher level concepts that ease development. You can have experts from EJB3 or from some vendor provide you with a foundation of components from which to compose applications. Spring does the same with all of their API's beans that simplify the JEE stack. JSF's role as a spec seeks to gather knowledge under a common interface.
....I would never be satisfied with Wicket written in JSF for this reason (if that's what you're suggesting). It's like saying "we've got this great drama", why don't you add some funny bits and ship it as a comedy? For me, a big part of Wicket has been trying to make the packages and classes and methods of the framework lead the programmer through the story of building a web application.
Again, I really am fond of the Java-centric approach for development. But, I still have intimate knowledge of the fact that JSF component models can be composed out within java code too. Providing a foundation of contracts in Java, and using the binding attribute of JSF, you can have 'page' POJOs with properties that programatically compose your dynamic bits.
-- Jacob
|
|
|
Message #202053
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Faclets vs Tapestry
The problem I see with facelets is the tag based approach.
<title><ui:insert name="title">Default title</ui:insert></title>
Although the code above would render correctly on a browser without any J2EE engine, it will cause problems with HTML editors unlike the attribute based approach of Tapestry which would get ignored and kept.
I would still avoid JSP or any other tag based approach to user interface development unless libraries have been set up to match the needs of an industry solution rather than a low level MVC framework. The reason is developers would have to maintain two sets of source files one from the HTML developers that have to get signed off and the transformed to JSP/JSF set.
Sure there might be tools that allow WYSIWYG JSP writing but you'd be imposing tool restriction on non-Java developers. Its better to use whatever tool does the job best.
|
|
|
Message #202055
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Faclets vs Tapestry
There are a couple options here:Simply use EL <title>#{title}</title> instead of spans Use <span jsfc="h:outputText" value="#{foo}"/> Use a Facelets TagDecorator to automatically translate <input type="text" value="#{bean.var}"/> to <h:inputText value="#{bean.var}"/> at compile time
|
|
|
Message #202056
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Faclets vs Tapestry
One other option, in light of the wicket thread:<span jsfc="ui:component" binding="#{page.menu}"/> and then have a 'getMenu()' method on a backing bean that returns a UIComponent model that's constructed programmatically, separate from the markup completely
|
|
|
Message #202057
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Still too much JSP
Again, I really am fond of the Java-centric approach for development. But, I still have intimate knowledge of the fact that JSF component models can be composed out within java code too. Providing a foundation of contracts in Java, and using the binding attribute of JSF, you can have 'page' POJOs with properties that programatically compose your dynamic bits.-- Jacob
I have no doubt that you can do almost anything in JSF (or JSP for that matter). The truth is, you can create really nice OO programs in C if you follow the right discipline. The trouble I have with JSF isn't that it can't do the job, but rather that the narrative isn't compelling and powerful and intuitive to me. It doesn't hide the parts and concepts I don't want to be bothered with by maximally leveraging what I already know. A framework is great when it makes complex things look easy because of all the hard work and abstracting and refactoring that went into telling a great story.
Now I could try to make some big long argument by zeroing in on dozens of qualitative issues that rub me the wrong way just on the surface of JSF (although I'm no JSF guru), but the bottom line is that I know enough to know I don't like it and it's a value judgement in the end. For me, the root problem is that JSF just doesn't tell the story of web application development in a conservative, expressive, powerful, intuitive way.
Why should I need 'intimate knowledge' of JSF to make components and models work? Shouldn't that be blindlingly obvious and intuitive in the API itself? Wouldn't 'extends' be a good way to create new components? Wouldn't setModel() be a good way to set the model on a component? And so on... Shouldn't the code itself tell the story in a way that obviates much of the need for documentation? Want to write a Wicket web application? public class MyWebApplication extends WebApplication { }. Could anyone fail to understand that? (I'm not suggesting wicket is ideal, just that we really put a HUGE amount of work into making our story as obvious and as simple and as powerful as possible. This meant a lot of /cutting/ and refactoring of code, btw)
JSF DOES solve a certain class of problems for a certain class of people. What rubs me the wrong way is that some JSF advocates seem to think that just because their story is COMPLETE and WELL KNOWN, it ought to be good enough for the rest of us. It's not! Some of us want to hear a simpler story! One that moves US rather than vice versa. I'm reminded of this quote:
"Poor Faulkner. Does he really think big emotions come from big words? He thinks I don't know the ten-dollar words. I know them all right. But there are older and simpler and better words, and those are the ones I use."
-- Ernest Hemingway
|
|
|
Message #202059
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Still too much JSP
Jonathan, I understand your points, but let me compare a couple things then for everyone else, using the Wicket GuestBook Example:
In JSF, we work with plain old POJOs, test anything you want within a static main or a local JUnit without mocks. The logical extension of 'WebPage' isn't necessary with JSF. While abstraction/delegation can always occur, it's not necessary with JSF since the wiring/ioc logic is externally configured, promoting re-use. JSF provides a blank sheet to compose your Java code (or story) however you want in simple bean terms-- you decide how to scale complexity-- as simple of a story as you want without complicating your Java with component knowledge or semantics.
Instead of tying to 'onSubmit', you just provide a public method that returns an Object-- String, Enum, etc to control flow. So I could just have public String addComment() as my action method on my POJO bean, disregarding the 1:1 relationship between forms and actions. Within a given view/form, I can have N actions/events for various CRUD requirements.
On to wicket documents. How does Guestbook.html, with id decoration any different than what Tapestry or Facelets can do? What logic can I optionally include or coordinate in that document without declaring or matching the UI with the Java code? Many have mentioned the compositional capabilities of Facelets and since components can/are defined in the document, you have the ability to re-use pieces of the UI independent of assertions within a page based Java model. IMHO, JSF has a *true* component model for this reason. Rick's article has a great example of this where a whole series of CRUD components for the UI work directly off of the same beans you wrote 8 months ago for use with Hibernate.
Please don't get me wrong. I think the facade that Wicket provides is a great 'story', but JSF and Wicket have different goals. Just like Spring provides hand-holding bean wrappers for JEE artifacts and concerns, I see no reason why someone couldn't publish the same for JSF, although I'm not sure the need is really there given that there are no APIs asserted on your Java model.
|
|
|
Message #202060
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JSFU
Java server faces are disgusting.
I still have not seen one problem they solve from a coding perspective, from a usability perspective or a standards perspective, I just dont get it.
Its wannabe abstraction theory that noone needs, wants or will adopt.
JSF is the JDO of Java UI Frameworks: Dead and deader.
Leave it alone already unless you are willing to send me a link to a really hot app written in JSF. It doesnt exist and never will.
Bye see ya later dont bother me with this crap again SUN.
|
|
|
Message #202061
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
A real boon to your development
Mr Hightower,
Could you post a link to this "real boon to your development" that rocks the Java application space?
Or is that just aa quote from the forward to some new book you plan to write?
|
|
|
Message #202064
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
TSS spoiler alert!
I have had conversations with folks who espouse unproven weak technology in industry rags. Emails and phone calls.
And when I cut through the chaff of the new technology argument in the face of common sense if they are honest they say,
"Well, I said it because I was paid to say it."
So when you click on the headliners link I guess you have your answer as to whether its really been a "boon to his development" or not.
Someone post me a link of one HOT PRODUCTION java web app using JSF. Ill file the lame sample JSF apps in the same bucket with the bank account example and the pet store.
|
|
|
Message #202065
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Still too much JSP
Heheh, if I didn't have so much on my plate right now, I might just take you up on that, hmmm.... ;-)
And I wasn't even kidding. If it is possible to create such an integration without too many sacrifices, that'd be awesome. In the end, it's all about choice for developers. Let us hear when you have more time then :)
|
|
|
Message #202067
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Still too much JSP
I think the facade that Wicket provides is a great 'story', but JSF and Wicket have different goals. Just like Spring provides hand-holding bean wrappers for JEE artifacts and concerns, I see no reason why someone couldn't publish the same for JSF, although I'm not sure the need is really there given that there are no APIs asserted on your Java model.
You shouldn't make the mistake of assuming that Wicket is hardwired to web server technology simply because we provide a WebPage abstraction that directly and intuitively solves the problems of 99.9% of our audience. Wicket is about programmatic manipulation of markup in general. The wicket.markup.html package and wicket.protocol.http package are just the present focus of things. To dismiss Wicket as a facade that provides a mere layer of hand-holding above something that is somehow JSF-like is to misunderstand its essential nature. There is a lot more to Wicket than meets the eye... by design.
If other people decide for themselves (and not due to FUD and marketing) that JSF is the best story for them, more power to them. Everyone has their own aesthetics and needs and I'm all for more stories. I just urge readers to be literate and make an informed decision.
|
|
|
Message #202069
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Still too much JSP
Yeah, I took a long stare at JSF one afternoon and could not figure out how to integrate it with Wicket in either direction. I'm not entirely sure if it's even possible without major modifications to one framework or the other.
Wicket is very listener-oriented and event driven and the details of request processing and response generation are intentionally buried in the framework implementation details for HTTP/HTML. In fact, in Wicket 1.2, the whole request-processing/response-generating strategy is actually abstracted out and replaceable, so it's OO all the way down and you're not tied to any specific strategy if a new markup protocol comes along (I've had some interesting thoughts about what this might mean, but that's another story). JSF, on the other hand, seems to have a more explicit model where the sequence of request processing is part of the component contract (please correct me if I'm wrong). So, the two things don't seem to me like they actually meet at all because the approaches are so wildly different.
|
|
|
Message #202070
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Still too much JSP
Instead of tying to 'onSubmit', you just provide a public method that returns an Object-- String, Enum, etc to control flow. So I could just have public String addComment() as my action method on my POJO bean, disregarding the 1:1 relationship between forms and actions. Within a given view/form, I can have N actions/events for various CRUD requirements.
I've read this several times now and I still don't understand what you're getting here with JSF except for a tooling hook. The addComment() or equivalent method is in the business layer in a good app. The fact that a form onSubmit() method calls it doesn't hardwire the two things into a 1:1 relationship! You can call the methods in the business layer from anywhere. Right? In fact, a well-coded onSubmit() handler in Wicket is typically going to be something like a single line call into the busines layer to persist the object. A very simple, readable line that you can put anywhere and which everyone will understand at first glance. And if you want more submit buttons that do fancy crud things to objects in the form, you just override onSubmit() on each form button... this is even highly reusable since you can provide stock buttons for something like a listview which do the crud operations no matter what is in the list. In fact, ListView actually includes methods that get moveUpLink, moveDownLink and removeLink components for the list that you can place anywhere you want (this may not be exactly how you want this done, but it's nice free functionality). I'm just totally lost as to why the JSF approach is better, except that it's easier to tool. The abstraction you're talking about, since it is not focused, actually makes the problem harder to solve (for me without tools, anyway).
|
|
|
Message #202072
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
TSS spoiler alert!
I guess you have your answer as to whether its really been a "boon to his development" or not.Someone post me a link of one HOT PRODUCTION java web app using JSF.
I can't give you a link, as it isn't up yet, but come back in a few months - I have a major JSF website in production right now.
|
|
|
Message #202075
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Still too much JSP
request/action frameworks feel more procedural than what our component frameworks are doing. One can create and use components with action frameworks or even with plain JSP. All depends on your definition of component.
|
|
|
Message #202079
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
A real boon to your development
Mr Hightower, Could you post a link to this "real boon to your development" that rocks the Java application space?Or is that just aa quote from the forward to some new book you plan to write?
There are no plans for a book. My book writing days are over. It is a lot of work and most of it is fairly tedious. I want to start a OS project.
There are some early stage planning for a white paper and a OS project. These will cover productivety improvements gain by using Facelets.
I took this week off (mostly) to contemplate belly button lint. I am fairly burnt out. I should have some more concrete ideas about the white paper and OS project next week. We have several meetings to disucss these things next week.
I have been working with JSF (moslty contract work) for customers for the past two years (almost). I find JSF more productive (for richer web apps) than Struts. I find Facelets a good way to get reuse at the UI tier.
I'll have more to say at a later date (week to a month).
Wicket seems interesting as does RIFE. I am fairly open minded.
For now Facelets and JSF (not to mention Hibernate, Spring and AspectJ) has a firm grip on my interests.
|
|
|
Message #202080
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Facelets fits JSF like a mask
JSF is the most productive web app API that I have used. Facelets makes it a lot more productive. Isn't it a contradiction? If Facelets makes it a lot more productive then JSF can't be the most productive API :-)
The statement was fairly subjective to begin with. Notice the use of I. It is an opinion. My opinion. JSF was the most productive web API that I ever used, and now with Facelets it is even more productive.
A runner can be the fastest runner. Next year he can run again and run an even faster race. Being the "most" is transitive at best.
Rome was the most powerful empire. It is not any longer.
|
|
|
Message #202081
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Is Facelets production ready?
Like a recent politician, I am going to say the following: It depends on what you mean by production ready. In my case "production ready" means "ready do decide to use Facelets in all new projects". It is stronger then "ready to use it in the specific project".To decide to use Facelets in all new projects, you are concerned about all possible issues, but in the specific project you are not concerned about issues you can work around or resolve on ad hoc bases in this project.
We have decided to use it on all new application (for now anyway). We are using Facelets 1.0.7 and MyFaces 1.1.1. When MyFaces 1.1.2 comes out we will evaluate it with the latest version of Facelets and likely adopt it.
I've had some issues working with older versions of MyFaces (1.1.1). It seems to work with the latest version of Facelets, you need to work with the latest nightly build of MyFaces.You can use Facelets (not recent version) with MyFaces 1.1.1, but then you don't get some of the bug fixes in the latest release. It just desn't look like production ready IMO.
Then don't use it. I don't agree. The value out weigh the issues for us. Facelets is fairly stable. It is more stable (it seems) than many of the JSF implementations.
I am using MyFaces 1.1.1 and Facelets 1.0.7 in app that should go into production in March. It works well enough for our needs. What servlet container/app server do you use?Nebojsa
Tomact 5.5.x.
|
|
|
Message #202082
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Facelets fits JSF like a mask
Isn't it a contradiction? If Facelets makes it a lot more productive then JSF can't be the most productive API :-) No. Even the most productive API can be made more productive, as nothing - not even JSF - is perfect :)
A very productive API can, the most productive API can't by definition. People tend to exaggerate.OT: I'm dissappointed by the fact that TSS still doesn't have the post preview functionality.
If you read what I wrote, I said the most productive API that I used--this is a subjective statement for sure but not an exageration by any means. This is a personal opinion based on the web APIs that I have used. This statement is not much of an exageration as it relates a personal experience and opinion.
|
|
|
Message #202083
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Facelets fits JSF like a mask
JSF is the most productive web app API that I have used. Facelets makes it a lot more productive. Isn't it a contradiction? If Facelets makes it a lot more productive then JSF can't be the most productive API :-)
No it is clearly not a contradiction. The fastest runner can always run even faster in another race.
|
|
|
Message #202084
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Still too much JSP
Am I the only person who hates taglibs and the EL? No, I hate them too. It started when I discovered JSTL EL was a little different from JSF EL. That such a thing could ever happen says a lot.
I think the most anoying thing about taglibs , el and markup templates in general is that they break OO semantics. I dont mean to be negative about facelets but I prefer to work with a GUI API that generates HTML. What is wrong with that, why do we use templates? Is eclipse build with markup templates? Or are am i just an api person and are most developers template people?
In theory you could build JSF without any markup language. I still prefer templates for document oriented things.
|
|
|
Message #202085
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Blah blah blah!
I have had conversations with folks who espouse unproven weak technology in industry rags. Emails and phone calls.And when I cut through the chaff of the new technology argument in the face of common sense if they are honest they say,"Well, I said it because I was paid to say it."
Blah blah blah! I am getting ripped off. Where is my money? I never got paid to say JSF was cool or Facelets or Spring or Hibernate.
Everything is a conspiracy these days. It is one thing to be skeptical. It is quite another to live in a closet with alluminum foil on your head to block the evil gamma rays that the government is using to control your brain.
Make a point why you feel JSF and/or Facelets sucks and then see how quickly Jacob and/or Steve (and/or Kito) rip it apart.
I'd go with the conspiracy theory if I was you too. It is much safer to do that than opine about the technology where you will get shredded.
So let me get this straight you don't like JSF and you don't like Faclets. So what do you like?
I am sure there are not shortcommings or tradeoffs with it. eh?
|
|
|
Message #202093
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
A real boon to your development
Holy cow! OS as in Operating System or Open Source?
Open Source. OS seems to be a common abreviation these days and given the context, I was not expecting any confusion.
But then again one can never guess the reading comprehension abilities of the audience.
Thanks for the chance to clarify.
:o)
|
|
|
Message #202099
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Wicket seems verbose to me
http://wicket.sf.net/
I went through some of the examples in the Wicket documentation. It seems a bit verbose compared to JSF. This is just a cursory look. I will admit Wicket does seem cool.
I am pretty big on the idea of web components. I wouldn't mind working on a project that used Wicket, Echo2, Tapestry, and JSF. There seems to be more JSF projects available. I have no problems getting work doing JSF.
I helped put an app into production mere months after JSF was released.
|
|
|
Message #202100
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Wicket seems verbose to me
http://wicket.sf.net/ I went through some of the examples in the Wicket documentation. It seems a bit verbose compared to JSF. This is just a cursory look. I will admit Wicket does seem cool. I am pretty big on the idea of web components. I wouldn't mind working on a project that used Wicket, Echo2, Tapestry, and JSF. There seems to be more JSF projects available. I have no problems getting work doing JSF.I helped put an app into production mere months after JSF was released.
I wouldn't mind working on a project that used Wicket, Echo2, Tapestry, or JSF.
I forget "or" and just put "and". It would be strange project indeed if it used all of those at the same time.
My point....
I've spent a lot of time trying to make Struts do things it was never designed to do. Those same things are child's play in JSF as they would likely be in Echo2, Wicket, and/or Tapestry.
Any component oriented development would be more preferable (to me) than Struts. This is not to say never to working wtih Struts, but it would not be my choice.
|
|
|
Message #202103
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Component based frameworks
Any component oriented development would be more preferable (to me) than Struts. This is not to say never to working wtih Struts, but it would not be my choice.
Same here.
|
|
|
Message #202104
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
A real boon to your development
Well, I figured you meant Open Source, but it is actually somewhat ambiguous and my first scan picked up Operating System.
I wonder what a facelets OS would mean... it's funny how mistakes or ambiguities can occasionally lead to big ideas...
|
|
|
Message #202105
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Component based frameworks
Any component oriented development would be more preferable (to me) than Struts. This is not to say never to working wtih Struts, but it would not be my choice. Same here.
"Would you like fries with that?" would be better than Struts.
|
|
|
Message #202108
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Component based frameworks
Any component oriented development would be more preferable (to me) than Struts. This is not to say never to working wtih Struts, but it would not be my choice. Same here.
"Would you like fries with that?" would be better than Struts.
That's pretty funny. :o)
|
|
|
Message #202109
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Component based frameworks
Any component oriented development would be more preferable (to me) than Struts. This is not to say never to working wtih Struts, but it would not be my choice. Same here.
"Would you like fries with that?" would be better than Struts.
I guess the upside is that contract would last longer. Just as long as the customer understands that. :)
|
|
|
Message #202114
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Component based frameworks
Any component oriented development would be more preferable (to me) than Struts. This is not to say never to working wtih Struts, but it would not be my choice. Same here.
"Would you like fries with that?" would be better than Struts.
I guess the upside is that contract would last longer. Just as long as the customer understands that. :)
I didn't think of that. I am losing money by doing JSF. Heheh. :)
|
|
|
Message #202116
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Challenge accepted
I have a knack for spotting failed technology. I just do. And your right it is easy to just say that and move on.
But thats where common sense meets geek sense meets marketing blah. And you can say IBM isnt paying you to write about it. But I believe someone is which isnt to say that its bull. But I think your gushing over nothing is about as rational as my negative rant. Because "its better than struts" doesnt cut it.
Theres lots of thing I dont have to write a whitepaper on to know that I should avoid. But if you insist on a think off I will shred your shredders, because I dont even have to blink twice to know junk when I see it.
I will intentionally waste my time and discover the beauty of JSF and report back when Im over it, if you promise to stop espousing marketecture when I show you what a hoax it is.
I have seen the JSF stuff and I think comparing JSF to struts is totally unfair. A good programmer can write struts in an hour. Its just a map of forwards. The taglibs are a convenience. The fact that you guys are still talking about struts as a baseline is kinda silly.
|
|
|
Message #202117
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Challenge accepted
The fact that you guys are still talking about struts as a baseline is kinda silly.
If you consider that the majority of new java web applications are still written in Struts, it's not so silly I think. I agree Struts and JSF are way apart when it comes to the implementation, but that's not something an end user typically cares about.
|
|
|
Message #202118
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Apps arent written in struts
Just because we have agreed to use struts as a view controller for so long doesnt mean that apps are "written in" struts.
|
|
|
Message #202119
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
build me a swing app with it
No knowledge of the UI?
Wasnt JSF supposed to be able to do fat client and web equally well when it was ahem..."introduced"?
Show me a swing app and a web app using the same components.
|
|
|
Message #202127
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Challenge accepted
I have a knack for spotting failed technology Do you do palm readings too? Can you look at RoR's palm and see its future? Is it rosy? ;)
|
|
|
Message #202128
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Component based frameworks
I didn't think of that. I am losing money by doing JSF. Heheh. :) Well, there is no way you can be good consultant then, right? :) lol.
|
|
|
Message #202129
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Wicket seems verbose to me
Any component oriented development would be more preferable (to me) than Struts. This is not to say never to working wtih Struts, but it would not be my choice.
And what prevents you from using components in Struts?
Or what does in mean component in your terms?
Marina
http://www.servletsuite.com
|
|
|
Message #202130
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Wicket seems verbose to me
Any component oriented development would be more preferable (to me) than Struts. This is not to say never to working wtih Struts, but it would not be my choice. And what prevents you from using components in Struts?
Or what does in mean component in your terms?
Marina
http://www.servletsuite.com
Action-oriented frameworks, or all MVC frameworks, cover the same 5 steps in some form or another: decode, validate, update, invoke, encode. Encode is basically rendering the view. JSF's true component framework-- they are self contained, participate in all MVC steps, and are relationally agnostic (UIComponent<->UIComponent). We're not just talking about rendering. In terms of something similar in the MVC realm-- take WebWorks' Action Chaining to the next level where you have a root action (or UIViewRoot) that gets a request event, and then the process perculates through a series of succeeding actions in the chain (or child UIComponents) to participate in updating, validation, behavior invocation, and rendering. Basically, we aren't just talking about rendering stuff to the screen.
|
|
|
Message #202131
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Challenge was not accepted
I have a knack for spotting failed technology. I just do. And your right it is easy to just say that and move on. But thats where common sense meets geek sense meets marketing blah. And you can say IBM isnt paying you to write about it. But I believe someone is which isnt to say that its bull. But I think your gushing over nothing is about as rational as my negative rant. Because "its better than struts" doesnt cut it.Theres lots of thing I dont have to write a whitepaper on to know that I should avoid. But if you insist on a think off I will shred your shredders, because I dont even have to blink twice to know junk when I see it.I will intentionally waste my time and discover the beauty of JSF and report back when Im over it, if you promise to stop espousing marketecture when I show you what a hoax it is.I have seen the JSF stuff and I think comparing JSF to struts is totally unfair. A good programmer can write struts in an hour. Its just a map of forwards. The taglibs are a convenience. The fact that you guys are still talking about struts as a baseline is kinda silly.
How is the challege accepted? This is the same blah blah blah.
I think I can sum up your thoughts in one sentence: "I am smart. You are dumb. JSF sucks.".
Did I get it?
Is there more?
But what framework or method do you espouse?
What do you claim is better and why?
|
|
|
Message #202147
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Wicket seems verbose to me
Any component oriented development would be more preferable (to me) than Struts. This is not to say never to working wtih Struts, but it would not be my choice. And what prevents you from using components in Struts?Or what does in mean component in your terms?Marinahttp://www.servletsuite.com
Well just to make the problem a little bit more accessible, you can make components, use program a taglib, but as soon as you want to do more than rendering you have to program a framwork for providing component hooks back into the action, as soon as you have more complicated stuff, you have to add hooks which provide an event system on top of the single event system action. And guess what, you just have duplicated the effort JSF has done for you already.
|
|
|
Message #202149
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Wicket seems verbose to me
JSF's true component framework-- they are self contained, participate in all MVC steps, and are relationally agnostic (UIComponent<->UIComponent). We're not just talking about rendering. In terms of something similar in the MVC realm-- take WebWorks' Action Chaining to the next level where you have a root action (or UIViewRoot) that gets a request event, and then the process perculates through a series of succeeding actions in the chain (or child UIComponents) to participate in updating, validation, behavior invocation, and rendering. Basically, we aren't just talking about rendering stuff to the screen.
it could be true for any JavaBean. It is not against JSF. I am just confused with the term "true" component. Does it mean in your explanation that non-JSF is not "true"? It sounds so :(
|
|
|
Message #202150
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Wicket seems verbose to me
Well just to make the problem a little bit more accessible, you can make components, use program a taglib, but as soon as you want to do more than rendering you have to program a framwork for providing component hooks back into the action, as soon as you have more complicated stuff, you have to add hooks which provide an event system on top of the single event system action. And guess what, you just have duplicated the effort JSF has done for you already.
In my view the component must be framework agnostic. The component != framework. And we should not mix that.
|
|
|
Message #202152
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Wicket seems verbose to me
In my view the component must be framework agnostic. The component != framework. And we should not mix that.
To reply to both of your comments, components in JSF terms, are composed by relationship, not by type. This allows you to evaluate the view in whole or in part since they are self-contained objects within the system, sharing a common contract of integration and composed independently of chosen tools (straight java, JSP, facelets, clay, etc). This really echos the signifigance of JSF's component model.
For your point above, your business components are agnostic of the framework, ideally suited within JSF-- since they do work with POJOs and JSF's UIComponents instead act upon your model instead of requiring your model to act upon them. So with JSF, you aren't mixing 'that'.
|
|
|
Message #202160
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Wicket seems verbose to me
Any component oriented development would be more preferable (to me) than Struts. This is not to say never to working wtih Struts, but it would not be my choice. And what prevents you from using components in Struts?Or what does in mean component in your terms?Marinahttp://www.servletsuite.com
Well just to make the problem a little bit more accessible, you can make components, use program a taglib, but as soon as you want to do more than rendering you have to program a framwork for providing component hooks back into the action, as soon as you have more complicated stuff, you have to add hooks which provide an event system on top of the single event system action. And guess what, you just have duplicated the effort JSF has done for you already.
Come on. Reinventing the wheel is fun! :o)
|
|
|
Message #202161
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Challenge was not accepted
I have a knack for spotting failed technology. I just do. And your right it is easy to just say that and move on. But thats where common sense meets geek sense meets marketing blah. And you can say IBM isnt paying you to write about it. But I believe someone is which isnt to say that its bull. But I think your gushing over nothing is about as rational as my negative rant. Because "its better than struts" doesnt cut it.Theres lots of thing I dont have to write a whitepaper on to know that I should avoid. But if you insist on a think off I will shred your shredders, because I dont even have to blink twice to know junk when I see it.I will intentionally waste my time and discover the beauty of JSF and report back when Im over it, if you promise to stop espousing marketecture when I show you what a hoax it is.I have seen the JSF stuff and I think comparing JSF to struts is totally unfair. A good programmer can write struts in an hour. Its just a map of forwards. The taglibs are a convenience. The fact that you guys are still talking about struts as a baseline is kinda silly. How is the challege accepted? This is the same blah blah blah. I think I can sum up your thoughts in one sentence: "I am smart. You are dumb. JSF sucks.".Did I get it?Is there more?But what framework or method do you espouse?What do you claim is better and why?
And by one sentence... I meant three short sentences.
DOH!
|
|
|
Message #202164
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Wicket seems verbose to me
Well just to make the problem a little bit more accessible, you can make components, use program a taglib, but as soon as you want to do more than rendering you have to program a framwork for providing component hooks back into the action, as soon as you have more complicated stuff, you have to add hooks which provide an event system on top of the single event system action. And guess what, you just have duplicated the effort JSF has done for you already. In my view the component must be framework agnostic. The component != framework. And we should not mix that.
Impossible, due to the fact, that HTML neither knows components nor events, nor a binding so that you can influence that stuff on a backend side.
The problem is you have to rely on something as soon as you have a non stateful non event aware protocol underneath.
To give you an example classical windowing toolkits. X comes closest, no components, there is no component model which does not need a framework underneath. In windows you have that but only because the components are covered to a big degree by Windows and also the event system, but as soon as you need components, you already run into different frameworks.
Good thinking, but show me the possibility of having a framework agnostic component model in HTML it is not possible unless you go for a framework and provide hooks from every framework there is into this component framework.
You cannot go for components without some kind of binding into the backend and without adding a decent event system, to the one event system html has.
|
|
|
Message #202172
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Put facelet in Maven repository
Jacob,
I'm trying to standardize my project build management and I would really appreciate if you could you put facelet in the maven 2 repository on ibiblio ? (i tried myself, but i don't know the versions of the dependencies)...
|
|
|
Message #202187
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Wicket seems verbose to me
Impossible, due to the fact, that HTML neither knows components nor events, nor a binding so that you can influence that stuff on a backend side.
HTML is a presentation stuff. You should use HTTP here, is not it? And because we are talking about web development it is correct to rely on HTTP.
Anything you are doing in JSF (or whatever do you use) for the web will be covered by HTTP at the end of the deal.
|
|
|
Message #202190
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Put facelet in Maven repository
Jacob, I'm trying to standardize my project build management and I would really appreciate if you could you put facelet in the maven 2 repository on ibiblio ? (i tried myself, but i don't know the versions of the dependencies)... Big +1 for my corporation!
|
|
|
Message #202191
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Wicket seems verbose to me
Impossible, due to the fact, that HTML neither knows components nor events, nor a binding so that you can influence that stuff on a backend side. HTML is a presentation stuff. You should use HTTP here, is not it? And because we are talking about web development it is correct to rely on HTTP.Anything you are doing in JSF (or whatever do you use) for the web will be covered by HTTP at the end of the deal.
I much prefer a framework that hide the protocol detail for me. I taught we all agreed the Context design pattern is a very good practice. Especially, if a new Http version appears in the future. Who knows?
By the way, Oracle has developped a telnet renderkit so Http is not always the protocol used in the end with JSF.
|
|
|
Message #202194
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Wicket seems verbose to me
I much prefer a framework that hide the protocol detail for me. I taught we all agreed the Context design pattern is a very good practice.
right, that is what framework is for. But "hide" does not mean "dismiss" or "eliminate".
Especially, if a new Http version appears in the future. Who knows?By the way, Oracle has developped a telnet renderkit so Http is not always the protocol used in the end with JSF. ja,ja - web 3.0 :)
|
|
|
Message #202195
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Put facelet in Maven repository
Jacob, I'm trying to standardize my project build management and I would really appreciate if you could you put facelet in the maven 2 repository on ibiblio ? (i tried myself, but i don't know the versions of the dependencies)... Big +1 for my corporation!
+1 for me too.
|
|
|
Message #202474
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Wicket 1.2 Follow-up
In fact, in Wicket 1.2, the whole request-processing/response-generating strategy is actually abstracted out and replaceable, so it's OO all the way down and you're not tied to any specific strategy if a new markup protocol comes along (I've had some interesting thoughts about what this might mean, but that's another story).
Just curious what markup/protocols you had in mind? Markup targetting different devices or semantic XML markup?
Also like to mention that I appreciated your comments on targetting data-driven solutions to specific well-defined problems, and the larger point about expressiveness / programming narratives. Well put.
|
|
|
Message #202479
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Wicket 1.2 Follow-up
I'm really not sure. The world right now is very HTTP/HTML. You could, of course, do something with existing markup or existing protocols. But this does not interest me very much.
My thought right now is more towards a new definition of what a browser is. You could create a very interesting Java browser by having markup tags defined by Swing/Java2D Sprocket-like components. But these components would have a basis in the server as well. In such a world, you've got Wicket components that are actually emanating very sophisticated sprockets on the client and the browser is really just a big Sprocket factory.
In a somewhat bigger version of this vision, the gap between client and server actually disappears and the markup floats around on the network along with its sprockets (which can be installed via something like OSGi) and that markup actually knows how to seek out and connect securely to Wicket components that might be running (or might start up!) anywhere. The markup may require Java code (either sprockets or backing components) in a Jini-like way, but it's just a markup file. The binding to the "client" interactivity and the "server" components occurs at the time it's needed. So there's no fixed server. Just markup that you can browse to or email or load from a file and once you have the network you've got interactivity (with a little encryption and a lookup mechanism).
|
|
|
Message #203307
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Facelets fits JSF like a glove
Trying to combine JSF and JSP is like trying to shoehorn a foot into a glove: it's possible, but not pleasant. This article introduces developers to Facelets' easy HTML-style templating and reusable composition components that fits JSF like a glove.While working on a JavaServer Faces (JSF) project recently, I had the pleasure of using Facelets for the first time. What I most liked about Facelets was that it let me create reusable composition components. Being able to take a page (like a JSP) and turn it into a component has been a real boon to my JSF development ever since. My conclusion? If you're not using Facelets, you're not getting the most you can out of JSF.The mismatch between JSF and JavaServer Pages technology is a serious problem in JSF development. The issue is how to integrate JSP's dynamic content into JSF's component-based model. JSP is singularly focused on generating dynamic output, whereas JSF requires JSP to coordinate building a component model. The disjunct occurs because that task is beyond the original intention of JSP.Most JSF developers simply learn to navigate such problems on an ad-hoc basis, but that's kind of like duct-taping a pillow to a hammer so it won't hurt coming down on your head. Facelets is a much more comprehensive solution: a templating language that is geared toward the JSF component model.Facelets fits JSF like a glove.Have you tried Facelets?Have you compared the Facelets approach to other technologies like Tapestry?
Thanks for the feedback on the Facelets article.
There will be another article on Facelets due to the interest.
Thanks again....
Rick Hightower (linked in)
JSF, Spring, and Hibernate training and consulting
|
|
|
| New content on TheServerSide.comNew content on TheServerSide.comNew content on TheServerSide.com |
|
|
Reza Rahman continues to explore the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(January 21, Article)
Ted Neward is an independent consultant specializing in high-scale enterprise systems, and an authority in Java and .NET technologies. He is the author and co-author of several books, including Effective Enterprise Java. At TheServerSide Java Symposium in March, he will be presenting sessions on pragmatic architecture, ECMAScript and Scala.
(January 15, Article)
Now that Oracle is absorbing Sun Microsystems, there mixed views on what should come of the Java Community Process (JCP). While some say Oracle should become the new steward of Java and keep the JCP much as it was, others argue that it may be time to open-source this widespread language.
(November 24, Article)
Reza Rahman explores the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(November 2, Article)
SAML is an XML-based standard for exchanging authentication and authorization data between security domains. The single most important problem that SAML was created to solve is the Web browser Single Sign-On problem. Many organizations are debating whether to stay with version 1.1 or move to 2.0. This article makes observations about both options.
(September 28, Article)
Joe Ottinger takes a look at how people learn, and applies it to the practice of programming. He notes that understanding how people learn is an essential part of working in a programming team.
(September 22, Article)
Stephen Maryka gave us an article about the Asynchronous Web and posed a number of questions that get examined like an approach to delivering Asynchronous Web capabilities through extensions to existing Java EE technologies.
(July 14, Article)
JavaServer Faces Flex goal is to provide users capability in creating standard Flex components, part of flexSDK which is open sourced through MPL license, as normal JSF components. This article by Ji Hoon Kim will provide an overview of creating a simple multilingual JSF page consisting of JSF Flex tags.
(June 29, Article)
In this session Jeff explores the key characteristics of successful SOA projects. He covers some of the patterns, and anti-patterns, tool sets, and strategies that he himself learned the hard way. Last, he provides a strategy and blueprint for achieving a high likelihood of success in your SOA project.
(June 23, Tech Talk)
Ari Zilka, CTO of Terracotta, Inc., talks about the new features in Terracotta 3.1, announced during JavaOne and available now.
(June 15, Tech Talk)
In this Tech Talk, Josh Long explores an integration challenge using Spring Integration and walks through the implementation, employing and expanding on the basic patterns of Enterprise Application Integration to tie together components into a function integration solution, and then demonstrates how Spring Integration helps address the integration requirements.
(June 15, Tech Talk)
In this Tech Talk, David Geary teaches you: The basics of Google Web Toolkit; How to implement Ajax-enabled applications in Java; Internationalization; Hooking into the browser history mechanism; Remote procedure calls.
(June 4, Tech Talk)
Jon Kern discusses the best architecture/technical solutions and ensure that they are repeated by all developers. By tackling the architecture up-front in a serial manner, subsequent parallel development will be much more manageable and predictable.
(May 28, Tech Talk)
This keynote describes the frustrations of modern knowledge workers in their quest to actually get some work done, and solutions for how to guard yourself against all those distractions. Neal Ford talks about environments, coding, acceleration, automation, and avoiding repetition as ways to defeat the misguided attempts to sap your ability to produce good work.
(May 26, Tech Talk)
Gil demonstrates how new, aggressive uses of already abundant compute capacity by common applications offer competitive value for application designers.
(May 21, Tech Talk)
Chris Keene introduces WaveMaker as a new way to automate the ability to generate Hibernate classes in order to more quickly bring OR mapping into an application.
(May 19, Article)
Mastering EJB was one of the original and most influential EJB books in the industry. Mastering EJB III now returns with two new expert co-authors, updated for EJB 2.1 and 30% new chapters including security, integration, best practices, open source, and more.
(Book PDF Download)
The Application Server Matrix is a detailed listing of J2EE vendors and their application server products, with information on latest version numbers, J2EE spec support and licensing, pricing, platform support, and links to product downloads and reviews.
(Application Server Comparison Matrix)
|
|
