11 Replies Latest reply on Dec 5, 2011 4:55 PM by freemarket

    Suggestion for component id addressing

    dan.j.allen

      While watching Jay's talk at JBossWorld on RichFaces, I had an idea for what I think is a cleaner way of doing dynamic component id addressing.

       

      Currently, if you want to reference the id of a table cell, you might do something like:

       

      #{rich:rowKeys(collection, 'tableId')}:cellId

       

      The use of the EL + an EL function is a bit too verbose for my taste. Instead, we could build on the use of the @ token to reference canonical elements (e.g., @form, @this, @body, etc) and allow it to accept parameters.

       

      @rowKeys(collection, 'tableId'):cellId

       

      While on the one hand we are introducing yet another expression syntax, it's already understood that the @ token is a dynamic element and we are simply parameterizing it. And truthfully, we are bending EL anyway to support the first syntax, so we might as well do the bending in the right place.

       

      On a related note, as surprising as it may seem, JSF 2 does not support sub-paths on canonical tokens. For instance:

       

      @form:username

       

      Why on earth they didn't think of that I have no idea. But it would be nice to see that implemented in RichFaces if possible. If it's too high level, we can hack it into Seam Faces. I think it requires overriding the Ajax behavior renderer. Ah, I suppose it could be supported in a4j:ajax then.

        • 1. Re: Suggestion for component id addressing
          nbelaevski

          Hi Dan,

           

          Thanks for the suggestion! I've created https://jira.jboss.org/browse/RFPL-662 task to review it just after M1.

          • 2. Re: Suggestion for component id addressing
            dan.j.allen

            Cool! Thanks Nick!

            • 3. Re: Suggestion for component id addressing
              ilya_shaikovsky

              Nick already implemented something like render="repeat:#{tableView.rowsList}:componentId" support for repeat. seems notation even more clear that all proposed before. Need just to list all restrictions if present and see how it works for us.

              • 4. Re: Suggestion for component id addressing
                nbelaevski

                Discussed and decided to use:

                 

                table:@rowKeys(cccc):id
                #{rowKeys('table', keys}:id

                table:@rowKeys(bean.keys):id

                • 5. Suggestion for component id addressing
                  nbelaevski

                  Another syntax options:

                   

                  table@rows(bean.keys) - should be qualified with @row/@treeNode automatically

                  table@rows(bean.keys):cellId - particular column update

                   

                  The same with additional separator

                   

                  table:@rows(bean.keys)

                  table:@rows(bean.keys):cellId

                  table:* - possible, but IMO doesn't make sense to support

                  table:*:cellId

                  • 6. Suggestion for component id addressing
                    jbalunas

                    Personally I'm between both for different reasons. 

                     

                    The extra separator is really just following convention of using a ":" to mark boundaries, while the "table@rows()" looks a bit cleaner to me.

                     

                    I don't feel strongly about this, but all things being equal we should follow conventions.  Especially if following convention is as simple as a ":".  If you reference a component like "form:componentId" you should reference the dynamic rows with "table:@rows(...)".  In this case the "@" is simply shorthand for dynamic ids.

                    • 7. Suggestion for component id addressing
                      jbalunas

                      Please get any comments or thoughts on component addressing in before the team meeting tomorrow.  I would like to finalize this by then.

                       

                      Thanks,

                      Jay

                      • 8. Re: Suggestion for component id addressing
                        nbelaevski

                        After additional discussion with Alex we've decided to remove support for wildcard matching (using '*' symbol). Also I'm being biased to use conventions variant:

                         

                        table:@rows(bean.expression):cell

                         

                        One more thing: how complex can be EL-expression inside @rows(...) be? The problem there is that they can contain symbols like ' ', ',' or '(' and this is conflicting with ID parsing. Example (strings 'y(1)' & 'x(1)' are application-dependent identifier strings used as argument for getKeys(...) function):

                         

                        render="table:@rows(bean.getKeys('y(1)', 1)):cell tree:@rows(bean.getKeys('x(1)', value)):cell"

                         

                        To keep it simple I'm going to implement very basic variant that does not support such EL-expressions and then we can improve the implementation. Thoughts?

                        • 9. Re: Suggestion for component id addressing
                          jbalunas

                          Nick and I just talked and he is going post some examples of the simple use cases support, so we can understand it better.

                           

                          So we'll go with the additional separator format, and for now support only basic EL in the method.

                          • 10. Suggestion for component id addressing
                            ilya_shaikovsky

                            I discussed the same simple variant with Nick already so have nothing to add. Completelly agree that simple variant without parametrized methodExpressions and * in patters is the best what we should do for now in order to keep it simple, functional and stable in first version. And I like table:@rows..:id pattern as it corresponds to real client id in tables adressing.

                            • 11. Re: Suggestion for component id addressing
                              freemarket

                              Do you have any suggestions for what component id syntax would be appropriate for R/F 3.3.3.Final to achieve partial table update (row or cell)?