ICEmobile
  1. ICEmobile
  2. MOBI-260

Identify Improvements in component implementation strategies for multple platforms.

          Details

          • Type: Task Task
          • Status: Closed
          • Priority: Major Major
          • Resolution: Fixed
          • Affects Version/s: 1.1 Beta, Spring 1.0 Alpha
          • Fix Version/s: 1.2 Beta
          • Component/s: Faces, Spring
          • Labels:
            None
          • Environment:
            ICEmobile development for JSF and Spring-MVC

            Description

            Porting the existing JSF components to a Spring-MVC based was harder than it ought to have been.

             Reverse engineering the markup is not great because it's not clear which fields are missing, given the current configuration. Reverse engineering the rendering code is not ideal because the Tag structure isn't mapped one-to-one to the same functional blocks as a JSF renderer. Comparing the actual output with the intended output repeatedly as a development process is very slow.

            Here is the output from the JSF accordion Renderer. This is easier than the Tabset, but still complicated:

            <div id="ACCID" class="mobi-accordion" data-opened="tab1">
                            
              <section id="tab1" class="open">
                <div class="handle" onclick="ice.mobi.accordionController.toggleClient('ACCID', this, false);">
                  <div class="pointer">&#9658;</div>First drop down item
                </div>
                <input name='submitB' class='mobi-button mobi-button-important' type='submit' value='Button 1'/>
              </section>
              <section id="tab2" class="closed">
                <div class="handle" onclick="ice.mobi.accordionController.toggleClient('ACCID', this, false);">
                  <div class="pointer">&#9658;</div>Second drop down item
                </div>
                <input name='submitC' class='mobi-button mobi-button-important' type='submit' value='Button 2'/>
              </section>
              <section id="tab3" class="closed">
                <div class="handle" onclick="ice.mobi.accordionController.toggleClient('ACCID', this, false);">
                  <div class="pointer">&#9658;</div>Third drop down item
                </div>
                <input name='submitA' class='mobi-button mobi-button-important' type='submit' value='Button 3'/>
              </section>
                            
            </div>
            <span id="ACCID_script">
              <script type="text/javascript"> ice.mobi.accordionController.initClient('ACCID',{ autoheight: true, maxheight: '0'});</script></span>

              Issue Links

              depends on

              Improvement - An improvement or enhancement to an existing feature or task. MOBI-307 JSP Resource Loading and Consolidation Strategy

              • Major - Major loss of function.
              • Resolved

                Activity

                Ascending order - Click to sort in descending order
                Greg Dick created issue -
                Greg Dick made changes -
                Field Original Value New Value
                Assignee Steve Maryka [ steve.maryka ] Greg Dick [ greg.dick ]
                Hide
                Permalink
                Greg Dick added a comment -

                The CSS holds both rendering paths to a standard. The markup generated must have the same structure, classes, and ids. Given that, why not document it? Given the markup below, see the notes section.

                <div id="CLIENTID" class="mobi-accordion" data-opened="tab1">
                <section id="tab1" class="open">
                <div class="handle" onclick="ice.mobi.accordionController.toggleClient('CLIENTID', this, false);">
                <div class="pointer">►</div> TITLE 1
                </div>
                <input name='submitB' class='mobi-button mobi-button-important' type='submit' value='Button 1'/>
                </section>
                <section id="tab2" class="closed">
                <div class="handle" onclick="ice.mobi.accordionController.toggleClient('CLIENTID', this, false);">
                <div class="pointer">►</div>TITLE2
                </div>
                <input name='submitC' class='mobi-button mobi-button-important' type='submit' value='Button 2'/>
                </section>
                ...
                </div>
                <span id="CLIENTID_script">
                <script type="text/javascript"> ice.mobi.accordionController.initClient('CLIENTID',

                { autoheight: true, maxheight: '0'}

                );</script></span>

                Notes:

                • Accordion consists of a containing DIV of class "mobi-accordion" with multiple optional <SECTION> child tags.
                • User selected SECTION has class of "open". All the rest have class = "closed"
                • Section tag has CHILD DIV with class="handle" and onclick handler for toggling client state
                • Child DIV has 2nd CHILD DIV with class="pointer" with body content the ascii code for either side arrow or down arrow.
                • After close of 2nd DIV comes optional accordion tag TITLE property Text. (and what else if not present)
                • Close first DIV and SECTION
                • Repeat
                • initClient argument description ( CLIENTID, { autoheight : true, maxHeight: '0' }

                  );

                While the argument naming is better than an unnamed argument list, I think the parameters still need more description, particularly if they have anything to do with Ajax.

                The above document took < 10 minutes to put together and would help catch inconsistencies and will help maintain the two branches of the components if we need to upgrade them in the future.

                The Accordion tag uses a string id (to identify the sections) with an autoincrementing integer end, "tab1", "tab2" (1 based) while the Tabset indexes into the sibling pool with a numeric 0-based selection index. I don't know why they're different and perhaps there's a great reason for it, but it would make reverse engineering the javascript easier if I knew what the algorithm was.

                Show
                Greg Dick added a comment - The CSS holds both rendering paths to a standard. The markup generated must have the same structure, classes, and ids. Given that, why not document it? Given the markup below, see the notes section. <div id="CLIENTID" class="mobi-accordion" data-opened="tab1"> <section id="tab1" class="open"> <div class="handle" onclick="ice.mobi.accordionController.toggleClient('CLIENTID', this, false);"> <div class="pointer">►</div> TITLE 1 </div> <input name='submitB' class='mobi-button mobi-button-important' type='submit' value='Button 1'/> </section> <section id="tab2" class="closed"> <div class="handle" onclick="ice.mobi.accordionController.toggleClient('CLIENTID', this, false);"> <div class="pointer">►</div>TITLE2 </div> <input name='submitC' class='mobi-button mobi-button-important' type='submit' value='Button 2'/> </section> ... </div> <span id="CLIENTID_script"> <script type="text/javascript"> ice.mobi.accordionController.initClient('CLIENTID', { autoheight: true, maxheight: '0'} );</script></span> Notes: Accordion consists of a containing DIV of class "mobi-accordion" with multiple optional <SECTION> child tags. User selected SECTION has class of "open". All the rest have class = "closed" Section tag has CHILD DIV with class="handle" and onclick handler for toggling client state Child DIV has 2nd CHILD DIV with class="pointer" with body content the ascii code for either side arrow or down arrow. After close of 2nd DIV comes optional accordion tag TITLE property Text. (and what else if not present) Close first DIV and SECTION Repeat initClient argument description ( CLIENTID, { autoheight : true, maxHeight: '0' } ); While the argument naming is better than an unnamed argument list, I think the parameters still need more description, particularly if they have anything to do with Ajax. The above document took < 10 minutes to put together and would help catch inconsistencies and will help maintain the two branches of the components if we need to upgrade them in the future. The Accordion tag uses a string id (to identify the sections) with an autoincrementing integer end, "tab1", "tab2" (1 based) while the Tabset indexes into the sibling pool with a numeric 0-based selection index. I don't know why they're different and perhaps there's a great reason for it, but it would make reverse engineering the javascript easier if I knew what the algorithm was.
                Hide
                Permalink
                Ted Goddard added a comment -

                Potentially impacts both JSF and JSP substantially, so deferring to 1.2 beta.

                Show
                Ted Goddard added a comment - Potentially impacts both JSF and JSP substantially, so deferring to 1.2 beta.
                Ted Goddard made changes -
                Fix Version/s 1.2 Beta [ 10344 ]
                Philip Breau made changes -
                Link This issue depends on MOBI-307 [ MOBI-307 ]
                Hide
                Permalink
                Philip Breau added a comment -

                Core rendering classes address this.

                Show
                Philip Breau added a comment - Core rendering classes address this.
                Philip Breau made changes -
                Status Open [ 1 ] Closed [ 6 ]
                Resolution Fixed [ 1 ]

                  People

                  • Assignee:
                    Greg Dick
                    Reporter:
                    Greg Dick
                  • Votes:
                    0 Vote for this issue
                    Watchers:
                    1 Start watching this issue

                    Dates

                    • Created:
                      Updated:
                      Resolved: