Re: [OT] JSF Interface Design - Is it Truly Limited?
On 11/14/05, Mike Duffy <[EMAIL PROTECTED]> wrote: > > Thx Craig. > > --- > In JSF 1.0/1.1 it is pretty much OK, but there are interoperability issues > trying to put elements inside another JSF component. Most of those > issues have been dealt with in JSF 1.2. However, even there you're *much* > better off designing components that render the elements for you, so > you don't have to deal with all the complexity. > --- > > What if your tags are simply being used for the style and layout of > labels and fields within > a form or for the formatting and display of textual information? There are > cases where it's just > a one time deal for a specific app and it is not a custom component. Is it > good practice to use > tags in that instance? Technically, it'll work fine if you put the elements *outside* rather than *inside* JSF components that try to do their own child management. That's where you run into interop problems. Philosophically, whether this is a "best practice" or not depends on your viewpoint on the issue of whether components should render *all* the markup, or only the dynamic parts. The advantage of the "all" case is you have things like icky browser-dependent code buried in your component renderers instead of in your HTML pages, so you never have to remember to add it to every page. The disadvantage is that you need to have a component available to render the outer element with sufficient flexibility to let you specify the styles you want, and that you might be restricted in choice of tools to develop the pages (although there are lots of tools that know how to deal with JSP custom tags, and therefore JSF component tags, quite gracefully). To me personally, those restrictions don't seem like too high a price to pay for letting the component developers have to worry about all the nitty gritty details, letting me focus on my application design. Mike Craig --- Craig McClanahan <[EMAIL PROTECTED]> wrote: > > > On 11/14/05, Mike Duffy <[EMAIL PROTECTED]> wrote: > > > > > > There is a difference between specifying CSS attributes and creating a > > > liquid CSS design. The > > > later involves a complete separation of style and content where a web > page > > > or JSP becomes a series > > > of tags that flow; a single style sheet can be used to change > the > > > look and feel of the > > > entire application. In a liquid CSS design, tables are only used for > > > displaying tabular data. > > > > > > In the "old days", complex web interfaces were based on an elaborate > > > layout of tables, nested > > > tables and nested tables within nested tables. In liquid CSS design, > the > > > creation of complex web > > > interfaces is much simpler and far more elegant. If you look at a page > > > created with nested tables > > > and another created with liquid CSS design there is a definite > aesthetic > > > difference. Also, > > > because s are easily manipulated, rich interfaces based on AJAX > are > > > much easier to create > > > using tags. > > > > > > In JSF, if the layout is restricted to panel grids and panel groups, > the > > > design will be table > > > based. In theory, the advantage of this approach is that multiple > > > renderers (HTML, Swing, etc.) > > > can make the application functional in different contexts. > > > > > > Not true. You are free to create JSF components that output tags > with > > appropriate style class names, rather than using things like panel > group. > > Indeed, a library of components organized around this metaphor would > likely > > be quite popular. > > > > Don't presume anything about the power of JSF from the limitations of > the > > standard components. They are basically there so you can write "Hello, > > World" apps without having to write a JSF component first. Instead, the > > promise is that you can enable different styles of component development > > (including your "liquid CSS" approach) on top of a standard API that > allows > > us all to share our components with each other. (And a similar "liquid > > JavaScript" approach might offer an even more flexible way to allow > > customization of dynamically rendered HTML without modifying the source > > pages at all.) > > > > In a JSF page, the tag can contain and other HTML tags. > So in > > > theory, you could > > > have a JSF application that encompasses liquid CSS design. I'd like to > ask > > > a question of the JSF > > > experts who monitor this list: Is it considered "bad form" to use > > > > tags within the > > > tag? > > > > > > In JSF 1.0/1.1 it is pretty much OK, but there are interoperability > issues > > trying to put elements inside another JSF component. Most of those > > issues have been dealt with in JSF 1.2. However, even there you're > *much* > > better off designing components that render the elements for you, > so > > you don't have to deal with all the complexity. > > > > Like many of the subscribers to this list, I have been struggling with > the > > > decision of whet
Re: [OT] JSF Interface Design - Is it Truly Limited?
Thx Craig. --- In JSF 1.0/1.1 it is pretty much OK, but there are interoperability issues trying to put elements inside another JSF component. Most of those issues have been dealt with in JSF 1.2. However, even there you're *much* better off designing components that render the elements for you, so you don't have to deal with all the complexity. --- What if your tags are simply being used for the style and layout of labels and fields within a form or for the formatting and display of textual information? There are cases where it's just a one time deal for a specific app and it is not a custom component. Is it good practice to use tags in that instance? Mike --- Craig McClanahan <[EMAIL PROTECTED]> wrote: > On 11/14/05, Mike Duffy <[EMAIL PROTECTED]> wrote: > > > > There is a difference between specifying CSS attributes and creating a > > liquid CSS design. The > > later involves a complete separation of style and content where a web page > > or JSP becomes a series > > of tags that flow; a single style sheet can be used to change the > > look and feel of the > > entire application. In a liquid CSS design, tables are only used for > > displaying tabular data. > > > > In the "old days", complex web interfaces were based on an elaborate > > layout of tables, nested > > tables and nested tables within nested tables. In liquid CSS design, the > > creation of complex web > > interfaces is much simpler and far more elegant. If you look at a page > > created with nested tables > > and another created with liquid CSS design there is a definite aesthetic > > difference. Also, > > because s are easily manipulated, rich interfaces based on AJAX are > > much easier to create > > using tags. > > > > In JSF, if the layout is restricted to panel grids and panel groups, the > > design will be table > > based. In theory, the advantage of this approach is that multiple > > renderers (HTML, Swing, etc.) > > can make the application functional in different contexts. > > > Not true. You are free to create JSF components that output tags with > appropriate style class names, rather than using things like panel group. > Indeed, a library of components organized around this metaphor would likely > be quite popular. > > Don't presume anything about the power of JSF from the limitations of the > standard components. They are basically there so you can write "Hello, > World" apps without having to write a JSF component first. Instead, the > promise is that you can enable different styles of component development > (including your "liquid CSS" approach) on top of a standard API that allows > us all to share our components with each other. (And a similar "liquid > JavaScript" approach might offer an even more flexible way to allow > customization of dynamically rendered HTML without modifying the source > pages at all.) > > In a JSF page, the tag can contain and other HTML tags. So in > > theory, you could > > have a JSF application that encompasses liquid CSS design. I'd like to ask > > a question of the JSF > > experts who monitor this list: Is it considered "bad form" to use > > tags within the > > tag? > > > In JSF 1.0/1.1 it is pretty much OK, but there are interoperability issues > trying to put elements inside another JSF component. Most of those > issues have been dealt with in JSF 1.2. However, even there you're *much* > better off designing components that render the elements for you, so > you don't have to deal with all the complexity. > > Like many of the subscribers to this list, I have been struggling with the > > decision of whether or > > not to make the jump to JSF. After reading the Geary/Hortstmann book and > > many articles > > (http://www.jamesholmes.com/JavaServerFaces/), and reviewing the work > > being done on Shale > > (http://struts.apache.org/shale/), I think it is time. The promise of JSF > > is real. > > > Yep :-). > > As someone who started out mapping form fields by using CGI and Perl, I am > > very thankful for the > > contributions made by those who created and maintained Struts. I sincerely > > hope that Struts can > > find a good home in the country where it can run and play in the warm > > sunshine. > > > > Mike > > > Craig > __ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] JSF Interface Design - Is it Truly Limited?
On 11/14/05, Mike Duffy <[EMAIL PROTECTED]> wrote: > > There is a difference between specifying CSS attributes and creating a > liquid CSS design. The > later involves a complete separation of style and content where a web page > or JSP becomes a series > of tags that flow; a single style sheet can be used to change the > look and feel of the > entire application. In a liquid CSS design, tables are only used for > displaying tabular data. > > In the "old days", complex web interfaces were based on an elaborate > layout of tables, nested > tables and nested tables within nested tables. In liquid CSS design, the > creation of complex web > interfaces is much simpler and far more elegant. If you look at a page > created with nested tables > and another created with liquid CSS design there is a definite aesthetic > difference. Also, > because s are easily manipulated, rich interfaces based on AJAX are > much easier to create > using tags. > > In JSF, if the layout is restricted to panel grids and panel groups, the > design will be table > based. In theory, the advantage of this approach is that multiple > renderers (HTML, Swing, etc.) > can make the application functional in different contexts. Not true. You are free to create JSF components that output tags with appropriate style class names, rather than using things like panel group. Indeed, a library of components organized around this metaphor would likely be quite popular. Don't presume anything about the power of JSF from the limitations of the standard components. They are basically there so you can write "Hello, World" apps without having to write a JSF component first. Instead, the promise is that you can enable different styles of component development (including your "liquid CSS" approach) on top of a standard API that allows us all to share our components with each other. (And a similar "liquid JavaScript" approach might offer an even more flexible way to allow customization of dynamically rendered HTML without modifying the source pages at all.) In a JSF page, the tag can contain and other HTML tags. So in > theory, you could > have a JSF application that encompasses liquid CSS design. I'd like to ask > a question of the JSF > experts who monitor this list: Is it considered "bad form" to use > tags within the > tag? In JSF 1.0/1.1 it is pretty much OK, but there are interoperability issues trying to put elements inside another JSF component. Most of those issues have been dealt with in JSF 1.2. However, even there you're *much* better off designing components that render the elements for you, so you don't have to deal with all the complexity. Like many of the subscribers to this list, I have been struggling with the > decision of whether or > not to make the jump to JSF. After reading the Geary/Hortstmann book and > many articles > (http://www.jamesholmes.com/JavaServerFaces/), and reviewing the work > being done on Shale > (http://struts.apache.org/shale/), I think it is time. The promise of JSF > is real. Yep :-). As someone who started out mapping form fields by using CGI and Perl, I am > very thankful for the > contributions made by those who created and maintained Struts. I sincerely > hope that Struts can > find a good home in the country where it can run and play in the warm > sunshine. > > Mike Craig
Re: [OT] JSF Interface Design - Is it Truly Limited?
There is a difference between specifying CSS attributes and creating a liquid CSS design. The later involves a complete separation of style and content where a web page or JSP becomes a series of tags that flow; a single style sheet can be used to change the look and feel of the entire application. In a liquid CSS design, tables are only used for displaying tabular data. In the "old days", complex web interfaces were based on an elaborate layout of tables, nested tables and nested tables within nested tables. In liquid CSS design, the creation of complex web interfaces is much simpler and far more elegant. If you look at a page created with nested tables and another created with liquid CSS design there is a definite aesthetic difference.Also, because s are easily manipulated, rich interfaces based on AJAX are much easier to create using tags. In JSF, if the layout is restricted to panel grids and panel groups, the design will be table based. In theory, the advantage of this approach is that multiple renderers (HTML, Swing, etc.) can make the application functional in different contexts. In a JSF page, the tag can contain and other HTML tags. So in theory, you could have a JSF application that encompasses liquid CSS design. I'd like to ask a question of the JSF experts who monitor this list: Is it considered "bad form" to use tags within the tag? Like many of the subscribers to this list, I have been struggling with the decision of whether or not to make the jump to JSF. After reading the Geary/Hortstmann book and many articles (http://www.jamesholmes.com/JavaServerFaces/), and reviewing the work being done on Shale (http://struts.apache.org/shale/), I think it is time. The promise of JSF is real. As someone who started out mapping form fields by using CGI and Perl, I am very thankful for the contributions made by those who created and maintained Struts. I sincerely hope that Struts can find a good home in the country where it can run and play in the warm sunshine. Mike --- Ted Husted <[EMAIL PROTECTED]> wrote: > On 11/14/05, pc leung <[EMAIL PROTECTED]> wrote: > > Ronald, > > > > I am a bit confused that MyFaces and Shale both implements JSF. > > Why you need to use both? why not use one of them? > > What about Struts-Faces? It integrates Struts and JSF. > > Do you consider it? > > > MyFaces implements JSR 127 (JavaServer Faces), and now the community > is also offering added-value components. > > Struts Shale *does not* implement JSR 127. Shale requires that you > provide a JSF implementations, such as MyFaces or the Sun Reference > Implementation. > > Shale builds on JSF to provide "front controller" features that many > of us are accustom to using, along with many other goodies like > integration with Commons Valdiator, Spring dependency injection, a > testing framework, and a dialog (wizard) manager. > > For more see the Struts Shale homepage. > > * http://struts.apache.org/shale/index.html > > Struts Faces can be a convenient bridge to help existing application > use JSF along side conventional server pages. But, if you are > developing a new application, and want to use JSF, you'd be better off > trying Shale. > > -Ted.. > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > __ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] JSF Interface Design - Is it Truly Limited?
On 11/14/05, pc leung <[EMAIL PROTECTED]> wrote: > Ronald, > > I am a bit confused that MyFaces and Shale both implements JSF. > Why you need to use both? why not use one of them? > What about Struts-Faces? It integrates Struts and JSF. > Do you consider it? MyFaces implements JSR 127 (JavaServer Faces), and now the community is also offering added-value components. Struts Shale *does not* implement JSR 127. Shale requires that you provide a JSF implementations, such as MyFaces or the Sun Reference Implementation. Shale builds on JSF to provide "front controller" features that many of us are accustom to using, along with many other goodies like integration with Commons Valdiator, Spring dependency injection, a testing framework, and a dialog (wizard) manager. For more see the Struts Shale homepage. * http://struts.apache.org/shale/index.html Struts Faces can be a convenient bridge to help existing application use JSF along side conventional server pages. But, if you are developing a new application, and want to use JSF, you'd be better off trying Shale. -Ted.. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] JSF Interface Design - Is it Truly Limited?
Ronald, I am a bit confused that MyFaces and Shale both implements JSF. Why you need to use both? why not use one of them? What about Struts-Faces? It integrates Struts and JSF. Do you consider it? On 11/14/05, Ronald Holshausen <[EMAIL PROTECTED]> wrote: > I use Shale, Tiles and MyFaces. The main reason for moving over is > that JSF is being pushed by Sun as the standard for J2EE user > interfaces, and is getting picked up by some of the big companies like > Oracle, so I think it will gain a lot of momentum and support from > most vendors. I also like the fact that your backing java beans don't > need to implement any interfaces or extend base classes, which leaves > your presentation java code more independent of the JSF APIs. > > On 14/11/05, pc leung <[EMAIL PROTECTED]> wrote: > > Ronald > > > > I am also thinking of switching to JSF. Do you use Shale, MyFaces or Sun > > JSF? > > Any reasons your company starts to use JSF as I am standing at the > > cross road of Struts and JSF? > > > > Thanks > > > > > > > > On 11/14/05, Ronald Holshausen <[EMAIL PROTECTED]> wrote: > > > Hi Mike, > > > > > > I have switched from struts to JSF for our companies product > > > development, as I can say that JSF is totally CSS oriented. Each > > > control has a CSS class as a property, and a lot of the tomahawk > > > components provide their own base CSS classes by default (have a look > > > at the tabbed pane from tomahawk as an example). > > > > > > I agree with you about the mock-ups. With our development, the process > > > starts with the graphic artists who do the demos and new product > > > concepts in pure html and CSS with tools like Dreamweaver, etc. Then > > > the developers convert the HTML to JSPs and write the backing java. > > > This works the same with struts and JSF. > > > > > > Have a look at the clay component from shale, as this supports this > > > type of development process more fully as you could then use the > > > generated HTML from the graphic artists directly, just add some ids > > > much like Tapestry does. > > > > > > On 12/11/05, Gary VanMatre <[EMAIL PROTECTED]> wrote: > > > > > I know there are some leading edge JSF and Shale gurus who monitor > > > > > this list. I > > > > > have a basic > > > > > question: Can rich web application interfaces be created in JSF? > > > > > > > > > > I've looked at MyFaces and Tomahawk (http://myfaces.apache.org/). The > > > > > source > > > > > code that can be > > > > > found in the examples at http://www.irian.at/myfaces/home.jsf is > > > > > perplexing. I > > > > > see data tables, > > > > > panel groups, and panel grids for the page layout. I do not see > > > > > standards based > > > > > CSS design. I > > > > > don't see how you could create rich web application interfaces with > > > > > externalized > > > > > styles using JSF > > > > > components. > > > > > > > > > > I know the concept is that JSF components can be "rendered" for > > > > > different > > > > > viewing devices; > > > > > however, I'm not sure the creators of JSF really thought through the > > > > > process of > > > > > how most web > > > > > applications are created. I think the usual case is that a mock up of > > > > > the web > > > > > interface is > > > > > created by marketing execs and web designers, then that mock up is > > > > > "wired" by > > > > > software engineers > > > > > (in our case we use Struts for the wiring). CSS design is very > > > > > advanced (see: > > > > > http://www.csszengarden.com/). It is unrealistic to think companies > > > > > are going > > > > > to retrain their > > > > > web designers on a new technology that is less capable then the one > > > > > they are > > > > > currently using. > > > > > > > > > > As a specific example, the use of such tags in JSF as, > > > > > " > > > > " is > > > > > horrible. > > > > > > > > > > I think JSF has missed the mark. Rather than tossing out Struts I > > > > > think Sun > > > > > should have enhanced > > > > > Struts by creating a simple process for plugging in web components > > > > > (perhaps some > > > > > sort of enhanced > > > > > Tiles strategy) and they should have also enhanced Struts by adding a > > > > > better > > > > > page flow process > > > > > (similar to Spring WebFlow). > > > > > > > > > > > > > I think that if you take a better look at JSF, you might see Struts, > > > > Spring and a reusable visual component framework. To see this you have > > > > to look beyond the basic semantics. So, maybe a forward is called a > > > > navigation rule and validation is component based verses form based. > > > > > > > > I've always seen Struts as building blocks for the rest of the > > > > application. It provides the foundation, a starting point. Each shop > > > > seems to pick and choose different extension points to exploit. > > > > JSF provides the same model where extension points in the framework are > > > > configured via a configuration file. The framework guts can be swapped > >
Re: [OT] JSF Interface Design - Is it Truly Limited?
I use Shale, Tiles and MyFaces. The main reason for moving over is that JSF is being pushed by Sun as the standard for J2EE user interfaces, and is getting picked up by some of the big companies like Oracle, so I think it will gain a lot of momentum and support from most vendors. I also like the fact that your backing java beans don't need to implement any interfaces or extend base classes, which leaves your presentation java code more independent of the JSF APIs. On 14/11/05, pc leung <[EMAIL PROTECTED]> wrote: > Ronald > > I am also thinking of switching to JSF. Do you use Shale, MyFaces or Sun JSF? > Any reasons your company starts to use JSF as I am standing at the > cross road of Struts and JSF? > > Thanks > > > > On 11/14/05, Ronald Holshausen <[EMAIL PROTECTED]> wrote: > > Hi Mike, > > > > I have switched from struts to JSF for our companies product > > development, as I can say that JSF is totally CSS oriented. Each > > control has a CSS class as a property, and a lot of the tomahawk > > components provide their own base CSS classes by default (have a look > > at the tabbed pane from tomahawk as an example). > > > > I agree with you about the mock-ups. With our development, the process > > starts with the graphic artists who do the demos and new product > > concepts in pure html and CSS with tools like Dreamweaver, etc. Then > > the developers convert the HTML to JSPs and write the backing java. > > This works the same with struts and JSF. > > > > Have a look at the clay component from shale, as this supports this > > type of development process more fully as you could then use the > > generated HTML from the graphic artists directly, just add some ids > > much like Tapestry does. > > > > On 12/11/05, Gary VanMatre <[EMAIL PROTECTED]> wrote: > > > > I know there are some leading edge JSF and Shale gurus who monitor this > > > > list. I > > > > have a basic > > > > question: Can rich web application interfaces be created in JSF? > > > > > > > > I've looked at MyFaces and Tomahawk (http://myfaces.apache.org/). The > > > > source > > > > code that can be > > > > found in the examples at http://www.irian.at/myfaces/home.jsf is > > > > perplexing. I > > > > see data tables, > > > > panel groups, and panel grids for the page layout. I do not see > > > > standards based > > > > CSS design. I > > > > don't see how you could create rich web application interfaces with > > > > externalized > > > > styles using JSF > > > > components. > > > > > > > > I know the concept is that JSF components can be "rendered" for > > > > different > > > > viewing devices; > > > > however, I'm not sure the creators of JSF really thought through the > > > > process of > > > > how most web > > > > applications are created. I think the usual case is that a mock up of > > > > the web > > > > interface is > > > > created by marketing execs and web designers, then that mock up is > > > > "wired" by > > > > software engineers > > > > (in our case we use Struts for the wiring). CSS design is very advanced > > > > (see: > > > > http://www.csszengarden.com/). It is unrealistic to think companies are > > > > going > > > > to retrain their > > > > web designers on a new technology that is less capable then the one > > > > they are > > > > currently using. > > > > > > > > As a specific example, the use of such tags in JSF as, > > > > " > > > " is > > > > horrible. > > > > > > > > I think JSF has missed the mark. Rather than tossing out Struts I think > > > > Sun > > > > should have enhanced > > > > Struts by creating a simple process for plugging in web components > > > > (perhaps some > > > > sort of enhanced > > > > Tiles strategy) and they should have also enhanced Struts by adding a > > > > better > > > > page flow process > > > > (similar to Spring WebFlow). > > > > > > > > > > I think that if you take a better look at JSF, you might see Struts, > > > Spring and a reusable visual component framework. To see this you have > > > to look beyond the basic semantics. So, maybe a forward is called a > > > navigation rule and validation is component based verses form based. > > > > > > I've always seen Struts as building blocks for the rest of the > > > application. It provides the foundation, a starting point. Each shop > > > seems to pick and choose different extension points to exploit. > > > JSF provides the same model where extension points in the framework are > > > configured via a configuration file. The framework guts can be swapped > > > with a side of a configuration files. JSF expands on this by providing > > > an API for building visual components that have characteristics of event > > > oriented programming in a request response architecture. The component > > > API is a starting point. > > > > > > The fact that the reference implementation delivers a number of vanilla > > > components is a strength but maybe a weakness. The component API should > > > be seen as building blocks and not as ab
Re: [OT] JSF Interface Design - Is it Truly Limited?
I downloaded it, and went through their docs online, but I haven't had a chance to play with it yet :-( On 14/11/05, Bernhard Slominski <[EMAIL PROTECTED]> wrote: > > Have a look at the clay component from shale, as this supports this > > type of development process more fully as you could then use the > > generated HTML from the graphic artists directly, just add some ids > > much like Tapestry does. > > > Did you take a look at Facelets? It's something like Tapestry for JSF. > Allows you to work with plain HTML tags. > > Bernhard > > - > 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: [OT] JSF Interface Design - Is it Truly Limited?
Ronald I am also thinking of switching to JSF. Do you use Shale, MyFaces or Sun JSF? Any reasons your company starts to use JSF as I am standing at the cross road of Struts and JSF? Thanks On 11/14/05, Ronald Holshausen <[EMAIL PROTECTED]> wrote: > Hi Mike, > > I have switched from struts to JSF for our companies product > development, as I can say that JSF is totally CSS oriented. Each > control has a CSS class as a property, and a lot of the tomahawk > components provide their own base CSS classes by default (have a look > at the tabbed pane from tomahawk as an example). > > I agree with you about the mock-ups. With our development, the process > starts with the graphic artists who do the demos and new product > concepts in pure html and CSS with tools like Dreamweaver, etc. Then > the developers convert the HTML to JSPs and write the backing java. > This works the same with struts and JSF. > > Have a look at the clay component from shale, as this supports this > type of development process more fully as you could then use the > generated HTML from the graphic artists directly, just add some ids > much like Tapestry does. > > On 12/11/05, Gary VanMatre <[EMAIL PROTECTED]> wrote: > > > I know there are some leading edge JSF and Shale gurus who monitor this > > > list. I > > > have a basic > > > question: Can rich web application interfaces be created in JSF? > > > > > > I've looked at MyFaces and Tomahawk (http://myfaces.apache.org/). The > > > source > > > code that can be > > > found in the examples at http://www.irian.at/myfaces/home.jsf is > > > perplexing. I > > > see data tables, > > > panel groups, and panel grids for the page layout. I do not see standards > > > based > > > CSS design. I > > > don't see how you could create rich web application interfaces with > > > externalized > > > styles using JSF > > > components. > > > > > > I know the concept is that JSF components can be "rendered" for different > > > viewing devices; > > > however, I'm not sure the creators of JSF really thought through the > > > process of > > > how most web > > > applications are created. I think the usual case is that a mock up of the > > > web > > > interface is > > > created by marketing execs and web designers, then that mock up is > > > "wired" by > > > software engineers > > > (in our case we use Struts for the wiring). CSS design is very advanced > > > (see: > > > http://www.csszengarden.com/). It is unrealistic to think companies are > > > going > > > to retrain their > > > web designers on a new technology that is less capable then the one they > > > are > > > currently using. > > > > > > As a specific example, the use of such tags in JSF as, > > > " > > " is > > > horrible. > > > > > > I think JSF has missed the mark. Rather than tossing out Struts I think > > > Sun > > > should have enhanced > > > Struts by creating a simple process for plugging in web components > > > (perhaps some > > > sort of enhanced > > > Tiles strategy) and they should have also enhanced Struts by adding a > > > better > > > page flow process > > > (similar to Spring WebFlow). > > > > > > > I think that if you take a better look at JSF, you might see Struts, Spring > > and a reusable visual component framework. To see this you have to look > > beyond the basic semantics. So, maybe a forward is called a navigation > > rule and validation is component based verses form based. > > > > I've always seen Struts as building blocks for the rest of the application. > > It provides the foundation, a starting point. Each shop seems to pick and > > choose different extension points to exploit. > > JSF provides the same model where extension points in the framework are > > configured via a configuration file. The framework guts can be swapped > > with a side of a configuration files. JSF expands on this by providing an > > API for building visual components that have characteristics of event > > oriented programming in a request response architecture. The component API > > is a starting point. > > > > The fact that the reference implementation delivers a number of vanilla > > components is a strength but maybe a weakness. The component API should be > > seen as building blocks and not as absolute offering. I don't think that > > Struts would have lead as many projects to success if the developers could > > not have seen how to take advantage of is swappable parts. > > > > > One of the most promising projects for web application frameworks is a > > > project > > > named, "Clarity" > > > (http://www.jsfcentral.com/listings/A6020?link). The goal of this project > > > is to > > > consolidate and > > > enhance existing frameworks. I hope this is the path to nirvana. > > > > > > I like the JSF concept of pluggable components. My major problem with JSF > > > is > > > the design strategy > > > that states an application is a collection of components and these > > > components > > > have renderers for > > > dif
Re: [OT] JSF Interface Design - Is it Truly Limited?
Hi Mike, I have switched from struts to JSF for our companies product development, as I can say that JSF is totally CSS oriented. Each control has a CSS class as a property, and a lot of the tomahawk components provide their own base CSS classes by default (have a look at the tabbed pane from tomahawk as an example). I agree with you about the mock-ups. With our development, the process starts with the graphic artists who do the demos and new product concepts in pure html and CSS with tools like Dreamweaver, etc. Then the developers convert the HTML to JSPs and write the backing java. This works the same with struts and JSF. Have a look at the clay component from shale, as this supports this type of development process more fully as you could then use the generated HTML from the graphic artists directly, just add some ids much like Tapestry does. On 12/11/05, Gary VanMatre <[EMAIL PROTECTED]> wrote: > > I know there are some leading edge JSF and Shale gurus who monitor this > > list. I > > have a basic > > question: Can rich web application interfaces be created in JSF? > > > > I've looked at MyFaces and Tomahawk (http://myfaces.apache.org/). The source > > code that can be > > found in the examples at http://www.irian.at/myfaces/home.jsf is > > perplexing. I > > see data tables, > > panel groups, and panel grids for the page layout. I do not see standards > > based > > CSS design. I > > don't see how you could create rich web application interfaces with > > externalized > > styles using JSF > > components. > > > > I know the concept is that JSF components can be "rendered" for different > > viewing devices; > > however, I'm not sure the creators of JSF really thought through the > > process of > > how most web > > applications are created. I think the usual case is that a mock up of the > > web > > interface is > > created by marketing execs and web designers, then that mock up is "wired" > > by > > software engineers > > (in our case we use Struts for the wiring). CSS design is very advanced > > (see: > > http://www.csszengarden.com/). It is unrealistic to think companies are > > going > > to retrain their > > web designers on a new technology that is less capable then the one they are > > currently using. > > > > As a specific example, the use of such tags in JSF as, > > " > " is > > horrible. > > > > I think JSF has missed the mark. Rather than tossing out Struts I think Sun > > should have enhanced > > Struts by creating a simple process for plugging in web components (perhaps > > some > > sort of enhanced > > Tiles strategy) and they should have also enhanced Struts by adding a better > > page flow process > > (similar to Spring WebFlow). > > > > I think that if you take a better look at JSF, you might see Struts, Spring > and a reusable visual component framework. To see this you have to look > beyond the basic semantics. So, maybe a forward is called a navigation rule > and validation is component based verses form based. > > I've always seen Struts as building blocks for the rest of the application. > It provides the foundation, a starting point. Each shop seems to pick and > choose different extension points to exploit. > JSF provides the same model where extension points in the framework are > configured via a configuration file. The framework guts can be swapped with > a side of a configuration files. JSF expands on this by providing an API for > building visual components that have characteristics of event oriented > programming in a request response architecture. The component API is a > starting point. > > The fact that the reference implementation delivers a number of vanilla > components is a strength but maybe a weakness. The component API should be > seen as building blocks and not as absolute offering. I don't think that > Struts would have lead as many projects to success if the developers could > not have seen how to take advantage of is swappable parts. > > > One of the most promising projects for web application frameworks is a > > project > > named, "Clarity" > > (http://www.jsfcentral.com/listings/A6020?link). The goal of this project > > is to > > consolidate and > > enhance existing frameworks. I hope this is the path to nirvana. > > > > I like the JSF concept of pluggable components. My major problem with JSF is > > the design strategy > > that states an application is a collection of components and these > > components > > have renderers for > > different devices. I suppose that you could try to wrap CSS design around > > "" tags if you > > are creating a web application, but this seems contrary to the JSF model. > > > > Please share some guiding thoughts. Especially, if you have a link to some > > cool > > example pages > > created with JSF, I'd like to see them. > > > You might take a look at the Shale "rolodex" usecases. You will see some fun > CSS action delivered using a JSF view. It's all done using only two custom > component
Re: [OT] JSF Interface Design - Is it Truly Limited?
> I know there are some leading edge JSF and Shale gurus who monitor this list. > I > have a basic > question: Can rich web application interfaces be created in JSF? > > I've looked at MyFaces and Tomahawk (http://myfaces.apache.org/). The source > code that can be > found in the examples at http://www.irian.at/myfaces/home.jsf is perplexing. > I > see data tables, > panel groups, and panel grids for the page layout. I do not see standards > based > CSS design. I > don't see how you could create rich web application interfaces with > externalized > styles using JSF > components. > > I know the concept is that JSF components can be "rendered" for different > viewing devices; > however, I'm not sure the creators of JSF really thought through the process > of > how most web > applications are created. I think the usual case is that a mock up of the web > interface is > created by marketing execs and web designers, then that mock up is "wired" by > software engineers > (in our case we use Struts for the wiring). CSS design is very advanced (see: > http://www.csszengarden.com/). It is unrealistic to think companies are going > to retrain their > web designers on a new technology that is less capable then the one they are > currently using. > > As a specific example, the use of such tags in JSF as, > " " is > horrible. > > I think JSF has missed the mark. Rather than tossing out Struts I think Sun > should have enhanced > Struts by creating a simple process for plugging in web components (perhaps > some > sort of enhanced > Tiles strategy) and they should have also enhanced Struts by adding a better > page flow process > (similar to Spring WebFlow). > I think that if you take a better look at JSF, you might see Struts, Spring and a reusable visual component framework. To see this you have to look beyond the basic semantics. So, maybe a forward is called a navigation rule and validation is component based verses form based. I've always seen Struts as building blocks for the rest of the application. It provides the foundation, a starting point. Each shop seems to pick and choose different extension points to exploit. JSF provides the same model where extension points in the framework are configured via a configuration file. The framework guts can be swapped with a side of a configuration files. JSF expands on this by providing an API for building visual components that have characteristics of event oriented programming in a request response architecture. The component API is a starting point. The fact that the reference implementation delivers a number of vanilla components is a strength but maybe a weakness. The component API should be seen as building blocks and not as absolute offering. I don't think that Struts would have lead as many projects to success if the developers could not have seen how to take advantage of is swappable parts. > One of the most promising projects for web application frameworks is a > project > named, "Clarity" > (http://www.jsfcentral.com/listings/A6020?link). The goal of this project is > to > consolidate and > enhance existing frameworks. I hope this is the path to nirvana. > > I like the JSF concept of pluggable components. My major problem with JSF is > the design strategy > that states an application is a collection of components and these components > have renderers for > different devices. I suppose that you could try to wrap CSS design around > "" tags if you > are creating a web application, but this seems contrary to the JSF model. > > Please share some guiding thoughts. Especially, if you have a link to some > cool > example pages > created with JSF, I'd like to see them. > You might take a look at the Shale "rolodex" usecases. You will see some fun CSS action delivered using a JSF view. It's all done using only two custom components and a few JSF extension points, the rest is vanilla RI. http://svn.apache.org/builds/struts/nightly/struts-shale/ > Thx. > > Mike > Gary > > > __ > Yahoo! FareChase: Search multiple travel sites in one click. > http://farechase.yahoo.com > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] >
Re: [OT] JSF Interface Design - Is it Truly Limited?
> -Original Message- > From: Mike Duffy [mailto:[EMAIL PROTECTED] > Sent: Friday, November 11, 2005 4:47 PM > To: Struts Users Mailing List > Subject: [OT] JSF Interface Design - Is it Truly Limited? > > > I know there are some leading edge JSF and Shale gurus who > monitor this list. I would hope so too, but wouldn't you get more responses with a JSF-specific list? Anyway, you did send this to the Struts list, so I'm gonna respond even though I'm not a JSF guru. > I have a basic > question: Can rich web application interfaces be created in JSF? I've seen demos, so my guess the answer is "yes". > I've looked at MyFaces and Tomahawk > (http://myfaces.apache.org/). The source code that can be > found in the examples at http://www.irian.at/myfaces/home.jsf > is perplexing. I see data tables, panel groups, and panel > grids for the page layout. I do not see standards based CSS > design. I don't see how you could create rich web > application interfaces with externalized styles using JSF components. Well, you changed the qualifiers now. Earlier the question was just "Can I?" Now it's "Can I, with externalized styles?" Anyway, JSF is a component-oriented framework, and a higher level of abstraction than Struts. Because of that, it's not surprising that you lose some lower-level control. I guess you'd just have to be careful with which set of components you use. Choose those that'll give you access to the lower-level functions that matter to you. > I know the concept is that JSF components can be "rendered" > for different viewing devices; however, I'm not sure the > creators of JSF really thought through the process of how > most web applications are created. I think the usual case is > that a mock up of the web interface is created by marketing > execs and web designers, then that mock up is "wired" by > software engineers (in our case we use Struts for the > wiring). CSS design is very advanced (see: > http://www.csszengarden.com/). It is unrealistic to think > companies are going to retrain their web designers on a new > technology that is less capable then the one they are currently using. I think the target was "corporate developers", but I'm not sure if this was the target for JSF or for Creator (the IDE). Again, I think it's a matter of what your components allow you to do. > As a specific example, the use of such tags in JSF as, > "" is horrible. Well, it's a higher level of abstraction. It's like, when in your Action, you need to call getServlet().someMethod(), whereas before you just called someMethod() directly from your servlet method. Is this a poor metaphor? I think it's pretty close. The higher the level you go to, the farther could get from low-level things you used to take for granted. > Please share some guiding thoughts. Especially, if you have > a link to some cool example pages created with JSF, I'd like > to see them. I remember liking the ICEfaces demos (http://www.icesoft.com/products/demos_icefaces.html), but it turns out they "look" close to other JSF widgets I've seen. Well, I tend to think that components will allow me to control style values. I guess I'll have to see. Right now though, I'm thinking innocent till proven guilty. > Thx. > > Mike Like I said, I'm not a guru. I'm just sharing an opinion. Hubert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] JSF Interface Design - Is it Truly Limited?
On 11/11/05, Mike Duffy <[EMAIL PROTECTED]> wrote: > I know the concept is that JSF components can be "rendered" for different > viewing devices; > however, I'm not sure the creators of JSF really thought through the process > of how most web > applications are created. I think the usual case is that a mock up of the > web interface is > created by marketing execs and web designers Who creates mockups for desktop app? For Windows, MacOS or Linux? Why do you think things should be different for browser-based apps? Only because webapps [still] use HTML and HTML is used by "web designers"? >, then that mock up is "wired" by software engineers > (in our case we use Struts for the wiring). CSS design is very advanced (see: > http://www.csszengarden.com/). It is unrealistic to think companies are > going to retrain their > web designers on a new technology that is less capable then the one they are > currently using. Why an accounting app should look like an exercise in computer art? Michael. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] JSF Interface Design - Is it Truly Limited?
On 11/11/05, Mike Duffy <[EMAIL PROTECTED]> wrote: > > > I know there are some leading edge JSF and Shale gurus who monitor this > list. I have a basic > question: Can rich web application interfaces be created in JSF? Sure it can. CSS based or AJAX based, or whatever you want. But the key issue that you are raising is the design of the *components* being used, not the architecture of the server side APIs. Just as an example, the component set that comes with Creator 2 ( http://developer.sun.com/jscreator) is all theme sensitive, with the look and feel driven primarily by CSS stylesheets. This was accomplished by having the renderers emit a standard CSS style class name, without the developer having to do anything special. You select which theme to use by selecting one of the available theme jars, and you're done. The main promise of a common API for building components is that folks would start creating rich component libraries to the same API, so we (as app developers) can choose components that meet our requirements, from more than one source. That is already starting to happen, thanks to the fact that some (smart :-) component developers are indeed adopting JSF, and migrating their existing component models to support the new API as well. Craig
