7 Replies Latest reply on Mar 10, 2009 1:12 AM by traviskds

    toward JSF 2.0 and RichFaces 4.0: Semantic Layout


      This is a second example of what is better to drop before going forward after the issue with javascript:
      http://jboss.com/index.html?module=bb&op=viewtopic&t=148140

      The first components of Exadel VCP (pre-RichFaces lib) were designed to support old browser with lack of CSS support. So, some of them used (and use now) the table oriented layout.
      Even, the modern approach contradicts with the old one, we have to keep it in order to support the applications that already use RichFaces and have to be upgradeable without tremendous numbers of changes to be done.

      People are screaming about this issue periodically like here: http://jboss.com/index.html?module=bb&op=viewtopic&t=131119

      We suggest that RichFaces 4.0 version is a good time to clean up the layout and make it semantically right
      .

        • 1. Re: toward JSF 2.0 and RichFaces 4.0: Semantic Layout

          It is great news to hear.

          I think richfaces is a great enhancement for JSF, and tending towards semantic layout for your components will make them even better.

          Are those (with turning to jquery) the richfaces' new years resolutions ? :)
          Also, when is 4.0 due ?

          • 2. Re: toward JSF 2.0 and RichFaces 4.0: Semantic Layout
            jbalunas

            Again I agree completely :-)

            A major release like 4.0 can afford to break some VERY old backwards compatibility in favor of less cluttered components, and updated technology.

            I think that along with this should also be a review other common and specific component attributes and behavior. Striving for consistency and ease of use.

            I think a review of the required 3rd party libraries for the project would also be in order.

            All good stuff to focus on for 4.0.

            -Jay

            • 3. Re: toward JSF 2.0 and RichFaces 4.0: Semantic Layout

               

              "jbalunas@redhat.com" wrote:

              I think a review of the required 3rd party libraries for the project would also be in order.


              Jay, could you tell us more about this statement?

              • 4. Re: toward JSF 2.0 and RichFaces 4.0: Semantic Layout
                jbalunas

                 

                "SergeySmirnov" wrote:
                "jbalunas@redhat.com" wrote:

                I think a review of the required 3rd party libraries for the project would also be in order.


                Jay, could you tell us more about this statement?


                Sure - I mean that we should review the various dependencies listed in the pom.xml files. See if any are needed to be updated, centralized or if we should switch implementations to be consistent across modules or with sibling projects like Seam or others.





                • 5. Re: toward JSF 2.0 and RichFaces 4.0: Semantic Layout
                  traviskds

                  Hi,

                  Not sure if this topic is still open but a few issues that I noticed while using Richfaces (in a few seam projects) is that it does not seem to use Javascript effectively.

                  for example, in the suggestionbox. it created an iframe for each of the inputText we use in a form. So if I have 20 input texts that require a suggestionbox, then you will get 20 iframes in the page. This in turn can cause performance overhead as each iframe loads a dummy url (spacer.gif??) which means it creates more connections to the server.

                  This seems to be the same concept for the tooltip as well. Too much of code is duplicated on the page. Ideally, there should be just one component loaded per page that displays different values based on what is passed to it. The page that displays inside an iframe can change but only one iframe per page.

                  Previously I have developed my own suggestionbox (called lookupbox) using jsp/struts and I just had one iframe that gets loaded in the main template and via Javascript I call the same iframe and pass different attributes to get what I want displayed. For all this I did a customtag that was made easy for developers to add it to the page. The overall performance was very good.

                  Also with regard to the suggestionbox, (and I guess even other components), Richfaces is passing all the form fields as parameters to the server request. We can set attributes such as ajaxSingle="true" but that essentially is to prevent processing of the component tree at the server end. So when we have pages with a lot of form elements, it takes a while to make the request. I think at least there should be a attribute that will allow only the parameters you want to be sent to the server. (I was under the impression that was what the process attribute does but I was mistaken)

                  Further is Richfaces 4.0 going to still be independent of seam or is there plans to more tightly couple it? Because I think richfaces should be able to make more use of the seam javascript remoting functionality. I have not used it as yet (but plan to in the next few weeks to do my own "suggestionbox" in plain javascript). By directly using seam's javascript remoting, I am hoping to get better performance including the ability to bypass JSF itself for certain functionality on a page. (action related functionality. )

                  Maybe you'll should consider a set of richfaces components using seam JavaScript remoting and bypassing JSF itself would give developers like us more options and functionality.

                  These are some of my thoughts that I hope you will give some consideration. BTW, I also agree to that you should take the css/div/span path instead of using tables to layout the components.

                  All the best

                  Travis

                  • 6. Re: toward JSF 2.0 and RichFaces 4.0: Semantic Layout

                    The only reason for using iframe in the case you mentioned above is supporting IE6 with it stupid behaver to ignore the zindex on the relative blocks. IE7, even still having this bug, allows other variants, but IE6 is a really a show stopper of the progress.
                    RichFaces does not use iframe to load any data from server to client. Standard Ajax is enough and does not contradict with JSF paradigms anyhow.

                    Developing the component or a component composition for particular application you have a control over the use cases application might have. You can correct the application code if you need to shortcut the angles. Component of the component library must work in the undetermined number of usecases. This is a fundamental difference between the development stuff for application and for component library.

                    So, you suggest that sending the only one form element when ajaxSingle="true" is more effective and save traffic. How are you going to work with session data during this request missing the session id that is passed with form submit and storing in the form. The same for Seam conversation id. Even you take session id and conversation id, you are under the risk to miss the data that third party components relay on. Which one? I do not know. Nobody knows which third party components RichFaces should work with. The primary idea of the RichFaces was to avoid such knowledge to drop limitation aways.

                    Again, if you know your application, you can definitely simplify the stuff limiting to only use cases you have.

                    I disagree that RichFaces should tightly couple with Seam. Even the size of the Javascript might decreased, such coupling brings much more disadvantages in the feature. Significant decreasing the size of the javascript as well as css and rendering html are the targets of the RichFaces 4.0 for sure. However, the best way to go is using the the JS implementation defined as a standard for JSF 2.0. Alex Smirnov already contributed the code to the Mojarra 2.0 that will help us to implement the most optimal solution in the scope of RichFaces 4.0.

                    Travis, thank you for your very valuable feedback. Even it might seem that I disagree with your points, such feedback helps me to better to understand the end developers' vision.

                    • 7. Re: toward JSF 2.0 and RichFaces 4.0: Semantic Layout
                      traviskds

                      Hi Sergey,

                      Thank you for the prompt reply and the fact that you took the time to think of a developer's view.

                      With regard to the iframe, that was just an example. What I was trying to convey was that when you do a view source of the generated code, you see a lot of code duplication that can be moved into a single place. Take the tooltip for example. It adds the tooltip tags within the element itself. Following code was taken from the richfaces demo site.

                      <span id="j_id353" class="dr-rich-tool-tip rich-tool-tip" style="z-index: 99; visibility: hidden; display: none; left: 475px; top: 493px;">
                      <span id="j_id353content">
                      <span style="white-space: nowrap;">
                      This tool-tip content was
                      <strong>pre-rendered</strong>
                      to the page.
                      <br/>
                      The look of this tool-tip is 100% defined by skin.
                      </span>
                      </span>
                      <span id="j_id353script" style="display: none;">
                      <script id="scriptj_id353" type="text/javascript">
                      1
                      2new ToolTip({'delay':0,'hideEvent':'','showEvent':'mouseover','hideDelay':0} ,{'onshow':null,'onhide':null,'oncomplete':null} ,"j_id353","sample1","client",false,"bottom-right",false,10,10,function(event,ajaxOptions){A4J.AJAX.Submit('_viewRoot',null,event,ajaxOptions)},{'parameters':{'j_id353':'j_id353','ajaxSingle':'j_id353'} ,'actionUrl':'/richfaces-demo/richfaces/toolTip.jsf','oncomplete':function(request,event,data){;{var _toolTip = $('j_id353').component;_toolTip.toolTipContent = $('j_id353content');_toolTip.displayDiv();}},'control':this,'similarityGroupingId':'j_id353','onbeforedomupdate':function(request,showEvent,data){;{ var _toolTip = $('j_id353').component;_toolTip.toolTip.style.display = 'none'; }}} );;
                      3
                      4
                      </script>
                      </span>
                      </span>


                      Now the above code gets repeated for each of the tooltips you add to the page. Believe me our users want to add tooltips to almost all the field labels on the screen as a form of online documentation. (per field) So if I have a screen that has 25 fields, we are looking at the above code getting repeated 25 times. Isn't it better to have a javascript function where you just pass the tooltip string and it displays the tooltip accordingly. Now I know that you are actually doing that by calling the ToolTip function but for a simple use case, the amount of data passed is just too much. We should be able to have a default implementation where we set the settings in a common place and then just call the ToolTip function and pass the string and it displays the tooltip. It would be just a one liner for us. The span tags etc should get created inside the tooltip function itself.

                      With regard to sending one form element when ajaxSingle="true". once again this is just an example. It could be some other new attribute that you may want to add. You mention about the need for 3rd party components relaying on the data without even knowing what those 3rd party components are. If that is a design goal, that is fine. but shouldn't you also consider an alternate straight forward simple use cases as well. (for example, I want to get a list of cities to autosuggest for the user to pick and update the text field on the client side. (as you know, its not compulsory for the user to select from the autosuggest list. Its only a suggestion.) But it helps the user. In my apps, I have an icon where the user can click and get a list. I use the component.callSuggestion(true) function. I do this to avoid hitting the database for every keystroke after the minChars limit is achieve. Users find this a great feature and don't have to navigate to different pages to get lookup data and can use single page forms. So most of the fields I have on the screen needs to have the autosuggest feature. Hence the issue with performance.

                      With regard to tightly coupling with Seam, that suggestion was not to abandon the openness of what you have now but more of an idea of having an additional set of tags or attributes which when used takes advantage of Seam javascript remoting. (only if doing that adds a performance gain as I have still not used it and therefore cannot comment. I was thinking more like what you guys did with ajax for jsf (a4j) tags. To turn a richfaces component to be a seam javascript remoting component. Note that I am just thinking aloud and this maybe a stupid idea since I am not an expert on the richfaces design. I suspect you maybe having a lot of your users on the seam framework that justifies this but of course that is just a guess and you guys might be having a lot more users on other frameworks as well.)

                      BTW, I haven't read the JS implementation in JSF 2.0 but its great that you guys are involved in the process.

                      Also richfaces is really great. I want to give a go at some of the other stuff from exdel such as the Fiji flex components. But we need to improve performance. Specially for simple use cases as its very difficult to justify where a lookup might take 3 seconds when the same lookup can be displayed using php in sub seconds!!.

                      Also keep up the great work and thanks for listening to developers like us. I understand that my views could be one dimensional and you guys have to think of a wider audience but the fact that you guys are decent enough to at least listen means a lot and shows your commitment towards this project.