First step with no append mode

Without append mode, we set ourselves in a "web site like" world: scenes will be called via URLs (like HTML pages) and all displayed data will be cleared out from memory when reaching a new scene.

No parameter

Without scenes in append mode, the task is easy: you just need to redirect to the expected scene. For the moment, we will focus on the code mechanics and forget about the GUI elements.

Imagine you have 2 scenes, firstScene.rsp and secondScene.rsp. The piece of code that handles the Back in your second scene can be:

[...] [...]

With parameters

One of the counterparts of not using append mode is that if you want to share and keep values (context) between scenes, you have to use URL parameters.
For instance, if let's assume you browsed to firstScene.rsp with the parameter name which value is set to John. If you want to go to secondScene.rsp (which maybe does not need this information), and then go back to firstScene.rsp, you will have to bring the parameter with you.

Here is the call to secondScene.rsp from firstScene.rsp:

[...] "/> [...]

Then the "Previous" management in secondScene.rsp would be something like:

[...] " /> [...]

Back to the real World: let's use append mode

If you are reading this, you are probably familiar with the Streamezzo append mode, and you probably systematically use it. It allows you taking advantage of elements already in memory when loading some additional content. For our purpose, this means that when browsing back and forth between scenes, you will have to take care to show, hide, update or remove data from the scene graph. From now on, we will consider ourselves building a simple search application, with a form page and a result page. As our purpose here is only to illustrate how to manage the "Back", we will not plug to a genuine database.

Here is the storyboard of the service:

The principle

The use case is that our firstScene.rsp is a simple form used to submit a search request, and the results are displayed in the secondScene.rsp scene that allows to go back to the form thanks to its "Back" button.

The firstScene.rsp brings the static form, the secondScene.rsp brings a static layout and the dynamic content (i.e. the results of the search). Note that in a genuine service, the second scene will either be splitted following the view-content paradigm or include both view and content from a list component. This is not the purpose of this tutorial, so here we will consider the result page as being atomic, with a static part and a dynamic part.

Thanks to these schemas, we can now clarify the expected behaviour of the "Back". Going from the form to the results means hiding the form data. Going back from the results to the form means hiding the results. When I say "hiding", understand "hiding from the end-user's eyes". From the service point of view, it can be anything that remove the visible data (a node can be hidden, translated, deleted...).

Note that the matter here is not to deal about client-side or server-side scenes. The static scene firstScene.rsp might actually be embedded on client, but in real life you will probably set it on server. In the latter case, the cache has to be used for faster browsing. I redirect you to the available documentation on cache for more details on that point.

Now we have that in mind, let's handle the "Previous" feature.

"Back" using URL

This is the most intuitive way to implement the "Back" if you come from the HTML pages world. It will be like what we saw previously in the first step, but here with the append mode being used. This allow us taking advantage of data already in memory, and also to keep data in memory for a later use, without having to send values in the URLs like we have seen before. That's really convenient because it eases parameters handling and simplifies the decoration management (e.g. the background image is inserted once and or all for a while in the service). But little effort is needed to manage displayed information. Do not worry, it will quickly become natural!

The following schema shows how the scene graph of the service could be set.

When browsing with append mode (from the form to the result or the opposite), the programmer has to take care of removing the displayed data.

So here, when pressing the Back button, the programmer simply needs to remove the result scene elements to display the form again. The chosen method here is to have a single insertion point ("Root"), which is really convenient as it allows replacing the previous content with the newly loaded data.

Here is the code snippet of what's interesting for our purpose in firstScene.rsp:

[...] [...] [...]

And the same for secondScene.rsp:

[...] [...] [...]

Some points to notice:

• The fact that a scene replaces the content of the Transform "Global:Root" eases the display management by replacing the results with the form when pressing "Back". Therefore the above presented schema is somewhat incorrect, as both scenes contents are never present at the same time in the scene graph.
• The parameters have disappeared from the Back action.
• This browsing induces that the scenes are processed at each call. This may seem useless, especially for the form, which is entirely static. Improving that is the purpose of our next step.

"Back" improvement using scene graph

We previously used URLs each time we wanted to browse to another scene. The fact that the form is static leads us to the fact that this page should be cached. Using cache is convenient to increase the browsing pace, but in some cases it may be not fast enough to fulfill your needs, especially to display static data. For instance, you want a smooth sliding animation between scenes, without any loading time. An elegant solution is to store everything in the scene graph.

The method in our example is to keep the form data in memory, just by hiding this data. As everything is present, it is worthless to go back to the form by calling the firstScene.rsp URL once again. Here is what could become our scene graph representation.

The goal here is to hide the form when processing the search, while keeping it in memory. Then the "Back" button will no more call the first scene, but will only have to show what has been previously hidden.

Here is what the code snippets could become. First for firstScene.rsp:

[...] [...] [...]

Then for secondScene.rsp:

[...] [...] [...]

The points to notice:

• No more URL in the Back.
• The important point now it to take care of:
  • showing and hiding the correct nodes
  • removing from memory unused data, in order to avoid the explosion of ghost nodes appended to the tree but never used once hidden.

Attachment	Size
SimpleBackTutorial.swz	581.52 KB