Re: JSF and highly dynamic apps (was Re: Struts-BSF, Struts-Scripting [was Re: Proposal: Javascript-to-Java object conversions]]])
On Tue, 2 Nov 2004 21:43:41 -0800, Martin Cooper [EMAIL PROTECTED] wrote: This is a really interesting statement. Perhaps I'm wrong, but I've always thought the whole point of JSF was visual components. Yet the statement above clearly indicates that JSF goes well beyond that charter, and clearly suggests that there are facets of JSF that should not be a part of that JSR. FWIW, here is IBM's take on how to build rich web applications using JSF components plus a framework for sending data back and forth: http://www-106.ibm.com/developerworks/websphere/library/techarticles/0411_hasson/0411_hasson.html?ca=dnp-344 Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
FacesClient Components [Was Re: JSF and highly dynamic apps (was Re: Struts-BSF, Struts-Scripting [was Re: Proposal: Javascript-to-Java object conversions]]])]
Now that looks pretty cool! It's fee-based, though, right? Anyone taken a look at it? cheers, David |-+ | | Craig McClanahan | | | [EMAIL PROTECTED]| | | om | | || | | 11/04/2004 12:50 | | | PM | | | Please respond to| | | Struts | | | Developers List | | || |-+ ---| | | | To: Struts Developers List [EMAIL PROTECTED], Martin Cooper [EMAIL PROTECTED] | | cc: | | Subject: Re: JSF and highly dynamic apps (was Re: Struts-BSF, Struts-Scripting[was Re: Proposal: | |Javascript-to-Java object conversions]]]) | ---| On Tue, 2 Nov 2004 21:43:41 -0800, Martin Cooper [EMAIL PROTECTED] wrote: This is a really interesting statement. Perhaps I'm wrong, but I've always thought the whole point of JSF was visual components. Yet the statement above clearly indicates that JSF goes well beyond that charter, and clearly suggests that there are facets of JSF that should not be a part of that JSR. FWIW, here is IBM's take on how to build rich web applications using JSF components plus a framework for sending data back and forth: http://www-106.ibm.com/developerworks/websphere/library/techarticles/0411_hasson/0411_hasson.html?ca=dnp-344 Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSF and highly dynamic apps (was Re: Struts-BSF, Struts-Scripting [was Re: Proposal: Javascript-to-Java object conversions]]])
On Sun, 31 Oct 2004 23:00:41 -0700, Craig McClanahan [EMAIL PROTECTED] wrote: On Sun, 31 Oct 2004 21:30:22 -0600, Eddie Bush [EMAIL PROTECTED] wrote: Unless Martin is incorrect about the way JSF handles requests, I'm inclined to believe (despite the fact JSF will be a part of the next specification) we might want to consider using something else under the covers in our next major era of Struts. I love the idea of adherance to specifications, don't get me wrong ... so long as it is pragmatic to do so. Repeat after me ... the parts of JSF that Shale proposes to depend on have NOTHING to do with visual components This is a really interesting statement. Perhaps I'm wrong, but I've always thought the whole point of JSF was visual components. Yet the statement above clearly indicates that JSF goes well beyond that charter, and clearly suggests that there are facets of JSF that should not be a part of that JSR. Shale purports to depend on the parts of JSF that are unrelated to visual components, while visual components are the raison d'etre for JSF. So what, exactly, is the connection between JSF and Shale? And why does Shale need to be linked to JSF? -- Martin Cooper Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
JSF and highly dynamic apps (was Re: Struts-BSF, Struts-Scripting [was Re: Proposal: Javascript-to-Java object conversions]]])
I hear what you're saying, Craig. However, I still feel that JSF doesn't buy me much when building highly dynamic apps. Some points to consider: * Since one of the goals of such apps is to minimise the number of full page refreshes, relatively little of the app can be constructed using tools such as Java Studio Creator. For example, if I need a tabbed pane where working within the tabs and switching between tabs do not cause page refreshes, then JSF might help me put that component on the page initially, but it does nothing for me with respect to user interaction with that pane. The latter is the bulk of my development effort, not the initial page layout. * As you mentioned, partial page refresh functionality is going to require a back channel that to some extent replaces what JSF would give me if I used a full page refresh scheme instead. This distinctly lessens the value of JSF to me, when much of my app is going to need to use this back channel, and so cannot take advantage of JSF. * The types of components I need in my apps today do not exist. So in order to use JSF tools, I have to build all my own JSF components first. Given how little of my development is going to be spent on initial page creation, that seems like a lot of work for not much value. * We don't have the concept of page authors as distinct from developers. We have user interaction designers, but they're not the kind of people who would use a tool like Creator. In fact, no company I've worked at has those types of people, and I've seen many people say the same thing on the Struts lists over the years. I don't doubt that they exist - I just have not personally encountered them, and obviously I'm not alone. ;-) Combine the above with the comments I've seen from people like Hans Bergsten and Adam Winer - both EG members - regarding the issues with using JSF in JSP pages, and JSF really doesn't look attractive to me right now. (Hans's comments are here http://www.onjava.com/pub/a/onjava/2004/06/09/jsf.html and I saw a similar comment from Adam about the need for custom view handlers in a mail message somewhere. I don't have that reference handy right now.) I actually want to be wrong about this. ;-) I would really like to be able to use a standard framework like JSF to build my apps, rather than having to do my own thing. However, I'm just not seeing how JSF would give me enough of a benefit to make it worth the cost. Just to be clear, I'm certainly not saying that JSF has no value. I do see that, if the components are there to use, and you're not building a highly dynamic app (or, if you are, you also have a lot of distinct pages to construct and a page designer person doing that), JSF would help you get there faster. Unfortunately, that's not the case for me, and probably for many people building next generation web apps. -- Martin Cooper On Sat, 30 Oct 2004 14:54:16 -0700, Craig McClanahan [EMAIL PROTECTED] wrote: On Sat, 30 Oct 2004 11:03:29 -0700, Martin Cooper [EMAIL PROTECTED] wrote: To my knowledge, anyway, JSF is page oriented, relies on a page's component tree for rendering / processing, and does not provide for a client-side component to communicate back to its server-side partner without serialising and deserialising the page tree along with it. That pretty much breaks the partial page rendering scheme right there, unless you have the client and server parts of your components communicate with each other out of band as it were, which kinda defeats the purpose of having a component based framework. There's more than one purpose for a server side component based framework, and more than one way to deal with client side scripting. One of the most important features of components on the server side is so that tools can know enough about a component that it's possible to create a high quality user experience at design time. For instance, when a page author manipulates a tool on a graphical design surface (as in Sun Java Studio Creator, for example), the tool has to know what properties are available, what the legal values for each property are (or, alternatively, provide type-specific property editors for complex things), and ... among other things ... how to persist the user's choice in code (either as attributes of a JSP tag, or initializations in an XML file, or perhaps some generated Java code in a backing bean class). JSF provides sufficient infrastructure to make this fairly straightforward. The standard JSF components don't do anything particular in terms of client side scripting (with minor exceptions). That doesn't mean a component can't do so -- it just means that (for JSF 1.0/1.1 at least) JSF doesn't provide you any particular help. It's pretty straightforward to think about some sort of a panel component that does layout management, with label and field components you can drop on it -- and some more complicated things ike a tree control or a sortable table
Re: JSF and highly dynamic apps (was Re: Struts-BSF, Struts-Scripting [was Re: Proposal: Javascript-to-Java object conversions]]])
Martin, you make an interesting comment that I think ties into this discussion (loosely ;) ) that is worth mentioning... A lot of the tools us architects and developers use these days really only make sense in cases where you have a separation of activities in terms of page authors and developers. I echo your experience in that no organization I've ever worked in has had this separation. I know that such places exist, but my experience (and having talked to others) leads me to believe they are not the usual state of things. I personally have a dislike of taglibs in general. It's not that I won't use them and it's not that I don't recognize the benefit in some cases, but I truly believe that we use them way too much. If your in one of those organizations where you have page developers vs. back-end developers, then taglibs make total sense. In the types of organizations you and I seem to have had experience in though, they don't really buy you as much as some claim. In fact, I think they hinder you many times. I mean, if I write scriplets (assuming I do so in a resonably clear way and try and minimize it as much as possible), I find that to be easier to understand that having to go off and look at some tag handler source code. All the code in one place, namely the JSP, in other words. JSF struck me in the same way... It didn't seem that the added complexity was going to buy me much, if anything. My point, which I think I made before in this thread, is simply that a lot of the relatively recent developments that are billed as making our lives so much easier and less complex in fact do just the opposite. Rather than constantly trying to reinvent or improve upon the wheel, people should spend more time understanding what capabilities they already have without adding all the outside stuff. -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com Martin Cooper wrote: I hear what you're saying, Craig. However, I still feel that JSF doesn't buy me much when building highly dynamic apps. Some points to consider: * Since one of the goals of such apps is to minimise the number of full page refreshes, relatively little of the app can be constructed using tools such as Java Studio Creator. For example, if I need a tabbed pane where working within the tabs and switching between tabs do not cause page refreshes, then JSF might help me put that component on the page initially, but it does nothing for me with respect to user interaction with that pane. The latter is the bulk of my development effort, not the initial page layout. * As you mentioned, partial page refresh functionality is going to require a back channel that to some extent replaces what JSF would give me if I used a full page refresh scheme instead. This distinctly lessens the value of JSF to me, when much of my app is going to need to use this back channel, and so cannot take advantage of JSF. * The types of components I need in my apps today do not exist. So in order to use JSF tools, I have to build all my own JSF components first. Given how little of my development is going to be spent on initial page creation, that seems like a lot of work for not much value. * We don't have the concept of page authors as distinct from developers. We have user interaction designers, but they're not the kind of people who would use a tool like Creator. In fact, no company I've worked at has those types of people, and I've seen many people say the same thing on the Struts lists over the years. I don't doubt that they exist - I just have not personally encountered them, and obviously I'm not alone. ;-) Combine the above with the comments I've seen from people like Hans Bergsten and Adam Winer - both EG members - regarding the issues with using JSF in JSP pages, and JSF really doesn't look attractive to me right now. (Hans's comments are here http://www.onjava.com/pub/a/onjava/2004/06/09/jsf.html and I saw a similar comment from Adam about the need for custom view handlers in a mail message somewhere. I don't have that reference handy right now.) I actually want to be wrong about this. ;-) I would really like to be able to use a standard framework like JSF to build my apps, rather than having to do my own thing. However, I'm just not seeing how JSF would give me enough of a benefit to make it worth the cost. Just to be clear, I'm certainly not saying that JSF has no value. I do see that, if the components are there to use, and you're not building a highly dynamic app (or, if you are, you also have a lot of distinct pages to construct and a page designer person doing that), JSF would help you get there faster. Unfortunately, that's not the case for me, and probably for many people building next generation web apps. -- Martin Cooper On Sat, 30 Oct 2004 14:54:16 -0700, Craig McClanahan [EMAIL PROTECTED] wrote: On Sat, 30 Oct 2004 11:03:29 -0700, Martin Cooper [EMAIL PROTECTED] wrote: To my
Re: JSF and highly dynamic apps (was Re: Struts-BSF, Struts-Scripting [was Re: Proposal: Javascript-to-Java object conversions]]])
I haven't found much need to utilize scriplets since the JSTL came along. Indeed, I feel pages are much cleaner and a great deal more legible if taglibs are used. I rarely, if ever, use anything except the JSTL though. One notable exception is Struts' own taglibs. I make other exceptions from time to time, but there's got to be significant justification for doing so :-) I echo Martin's sentiment on the assignment of responsibilities too though. In fact, within the organization I work for, we actually act as support for our own applications. There is a level-1 support tier, but all they really do is log tickets that we handle. Unless Martin is incorrect about the way JSF handles requests, I'm inclined to believe (despite the fact JSF will be a part of the next specification) we might want to consider using something else under the covers in our next major era of Struts. I love the idea of adherance to specifications, don't get me wrong ... so long as it is pragmatic to do so. Kind Regards, Eddie Bush - Original Message - From: Frank W. Zammetti [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Sunday, October 31, 2004 7:03 PM Subject: Re: JSF and highly dynamic apps (was Re: Struts-BSF, Struts-Scripting [was Re: Proposal: Javascript-to-Java object conversions]]]) Martin, you make an interesting comment that I think ties into this discussion (loosely ;) ) that is worth mentioning... A lot of the tools us architects and developers use these days really only make sense in cases where you have a separation of activities in terms of page authors and developers. I echo your experience in that no organization I've ever worked in has had this separation. I know that such places exist, but my experience (and having talked to others) leads me to believe they are not the usual state of things. I personally have a dislike of taglibs in general. It's not that I won't use them and it's not that I don't recognize the benefit in some cases, but I truly believe that we use them way too much. If your in one of those organizations where you have page developers vs. back-end developers, then taglibs make total sense. In the types of organizations you and I seem to have had experience in though, they don't really buy you as much as some claim. In fact, I think they hinder you many times. I mean, if I write scriplets (assuming I do so in a resonably clear way and try and minimize it as much as possible), I find that to be easier to understand that having to go off and look at some tag handler source code. All the code in one place, namely the JSP, in other words. JSF struck me in the same way... It didn't seem that the added complexity was going to buy me much, if anything. My point, which I think I made before in this thread, is simply that a lot of the relatively recent developments that are billed as making our lives so much easier and less complex in fact do just the opposite. Rather than constantly trying to reinvent or improve upon the wheel, people should spend more time understanding what capabilities they already have without adding all the outside stuff. -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com Martin Cooper wrote: I hear what you're saying, Craig. However, I still feel that JSF doesn't buy me much when building highly dynamic apps. Some points to consider: * Since one of the goals of such apps is to minimise the number of full page refreshes, relatively little of the app can be constructed using tools such as Java Studio Creator. For example, if I need a tabbed pane where working within the tabs and switching between tabs do not cause page refreshes, then JSF might help me put that component on the page initially, but it does nothing for me with respect to user interaction with that pane. The latter is the bulk of my development effort, not the initial page layout. * As you mentioned, partial page refresh functionality is going to require a back channel that to some extent replaces what JSF would give me if I used a full page refresh scheme instead. This distinctly lessens the value of JSF to me, when much of my app is going to need to use this back channel, and so cannot take advantage of JSF. * The types of components I need in my apps today do not exist. So in order to use JSF tools, I have to build all my own JSF components first. Given how little of my development is going to be spent on initial page creation, that seems like a lot of work for not much value. * We don't have the concept of page authors as distinct from developers. We have user interaction designers, but they're not the kind of people who would use a tool like Creator. In fact, no company I've worked at has those types of people, and I've seen many people say the same thing on the Struts lists over the years. I don't doubt that they exist - I just have not personally encountered
Re: JSF and highly dynamic apps (was Re: Struts-BSF, Struts-Scripting [was Re: Proposal: Javascript-to-Java object conversions]]])
On Sun, 31 Oct 2004 21:30:22 -0600, Eddie Bush [EMAIL PROTECTED] wrote: Unless Martin is incorrect about the way JSF handles requests, I'm inclined to believe (despite the fact JSF will be a part of the next specification) we might want to consider using something else under the covers in our next major era of Struts. I love the idea of adherance to specifications, don't get me wrong ... so long as it is pragmatic to do so. Repeat after me ... the parts of JSF that Shale proposes to depend on have NOTHING to do with visual components Thus, any arguments over whether JSF adequately helps you build rich web interfaces (it doesn't yet -- that was out of scope for 1.0) are not relevant to the Shale decision. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
