Need more flexible history & backButton

[GoogleCodeExporter]

The current iUI history mechanism is not very flexible.  For example, it 
assumes that any link clicked 
is a forward navigation and that hitting the back button should return to the 
page the link was on.  
This is not always the case.

There are other cases, as well where a more flexible mechanism is needed.  
Please add any 
additional use cases or requests to this Issue rather than creating a new one.

Original issue reported on code.google.com by msgilli...@gmail.com on 6 Oct 2009 at 11:36

[GoogleCodeExporter]

I have a situation where I go from A to B to C to B to C.  In this case the 
back 
button receives the wrong text when the "C to B" step occurs.  My solution was 
to 
change the following:

                else if (link == $("backButton"))
                {
-                       history.back();
+                       iui.showPageById(pageHistory[pageHistory.length-2]);
                }
                else if (link.getAttribute("type") == "submit")
                {

This way at least the button does what it says it does. 

Original comment by robert.j...@gmail.com on 9 Oct 2009 at 2:20

[GoogleCodeExporter]

Robert, can you provide more detail on the problem you saw?  What version of 
iUI? Had you made any changes 
to iui.js before the one you show?  Do you have a link to a page that will show 
the problem?

I tried to reproduce it with Music sample and navigated using the A to B to C 
to B to C which would be: "Music 
to Artists to Beatles to Artists to Beatles"
and it seemed to work properly, meaning after C to B ("Beatles" to "Artist") 
the back button  displays "Music"

Thanks for your help!

Original comment by msgilli...@gmail.com on 9 Oct 2009 at 6:39

[GoogleCodeExporter]

I am using the latest from: http://bitbucket.org/msgilligan/iui/

Yes the back button displays "Music" but selecting it likely takes you back to 
Beatles 
instead of to Music (history.back() should take you back to where you came from 
which 
is from Beatles).

Basically a conflict between page hierarchy and page history.

Original comment by robert.j...@gmail.com on 9 Oct 2009 at 7:09

[GoogleCodeExporter]

Robert: You're using the latest from bitbucket -- cool!  In my testing 
selecting Music does take me to Music (not 
Beatles) and in this simple case there is no conflict between hierarchy and 
history.  That's why I was asking for 
details.  There are cases where hierarchy and history don't match, which is one 
of the reasons I created this 
issue.  However, to the best of my knowledge, the case you mention (at least in 
it's simplest form) is not one of 
them.

Original comment by msgilli...@gmail.com on 9 Oct 2009 at 7:45

[GoogleCodeExporter]

Sorry, now that I have dug into it more it is one of the details that I did not 
mention 
that makes my case special.  When I go from C to B I am not always using the 
back 
button to make this move.  Sometimes I use "iui.showPageById" and whenever I do 
this my 
history and hierarchy get out of sync.

Original comment by robert.j...@gmail.com on 9 Oct 2009 at 9:02

[GoogleCodeExporter]

Thanks, Robert.  I'm seeing the exact same thing on a project that I'm working 
on.  I'm going to use your patch, 
but in order to address all the issues around navigation, I think bigger 
changes are needed.  That's why this Issue  
has a fairly open-ended summary.

Original comment by msgilli...@gmail.com on 13 Oct 2009 at 9:20

[GoogleCodeExporter]

Sounds good.  What I did works well for something pretty simple but anything 
more 
complicated would benefit from a more flexible history system.

Original comment by robert.j...@gmail.com on 13 Oct 2009 at 9:45

[GoogleCodeExporter]

One more thing, since you want to remove the current page from the stack, 
shouldn't you use the following code 
instead:

            pageHistory.pop();
            iui.showPageById(pageHistory[pageHistory.length-1]);

(I'm considering renaming pageHistory to navStack to make it's function and 
meaning more clear.)

Original comment by msgilli...@gmail.com on 13 Oct 2009 at 10:00

[GoogleCodeExporter]

I think that it gets removed anyways because you are going backwards and the 
splice 
will remove it in showPageById.  However the code that you propose makes things 
clearer 
and may avoid bugs in the future.

Original comment by robert.j...@gmail.com on 13 Oct 2009 at 10:18

[GoogleCodeExporter]

Yeah, splice should pull it out.  I definitely want to reorganize this code.  
Thanks.

Original comment by msgilli...@gmail.com on 14 Oct 2009 at 4:46

[GoogleCodeExporter]

Yeah, the splice  should remove  it.  Thanks.

Original comment by msgilli...@gmail.com on 14 Oct 2009 at 5:00

[GoogleCodeExporter]

I had an issue when navigating through a PaginatedList<T> in ASP.NET/C#, so 
what I
did was just added 

else if (link.getAttribute("backwards")) // Links with 'backwards' attribute 
will
slide backwards
{
   link.setAttribute("selected", "progress");
   iui.showPageByHref(link.href, null, "GET", null, unselect, true);
}

to the click event listener and added a new property 'backwards' to the
showPageByHref and insertPages functions. This allows me to control the sliding
direction by adding an attribute of 'backwards' to links.

Original comment by CoolCri...@gmail.com on 5 Nov 2009 at 4:56

Attachments:

• iui.js

[GoogleCodeExporter]

I needed tighter control of the back button for a Student Information System 
application I'm developing. 
Example: I select the roster of students for a teacher's class, then provide 
buttons for moving from one 
student to the "next" or "previous". To preserve the hierarchy I want the 
"back" button to remain as a link back 
to the roster list of the class.

I implemented a concept of "parentID" pretty successfully... when I explicitly 
want to define the "parent" of the 
selected page, I add a parentID attribute... <ul id="roster" 
parentID="schedule".....>

I added the following to the updatePage function:
    var parentID = page.getAttribute('parentID');
    if (parentID)
    {
        var parentPage = $(parentID);
        backButton.innerHTML = parentPage.title;
        backButton.href = '#' + parentID;       
    }

I also added a line to just after if(backButton) that always resets the 
button's href back to "#"

I did have to implement the "backlink" mods to preserve the backwards sliding 
of the button.

This way if I define a parentid the backButton's behavior is more tightly 
controlled, but in the absence of a 
parentid attribute, it functions in the normal "history.back()" way.

Original comment by rogersp...@yahoo.com on 11 Nov 2009 at 2:05

[GoogleCodeExporter]

Issue 228 has been merged into this issue.

Original comment by msgilli...@gmail.com on 9 Jan 2012 at 6:47