HashRouting: Routing, navigation with URL Hash

Show and Tell
12

Ok, so here is the summary of the things I didn’t know and I finally understand (with the exception of the last two items, it’s still dark over there).

Summary

  • some background about how URLs work usually out there and in Anvil with this module:

    == How the URL is commonly used ==
[   specifies document content on server side    ] [scroll position or other info used on the client side]
[   domain   ] [  path   ] [    query string     ] [ hash  ]
sub.domain.com/path1/path2?key1=value1&key2=value2#id_of_tag

== How the URL is managed by Anvil with this routing module ==
[never changes] [ managed by the routing module ]
[   domain   ]  [ page  ] [ anvil query string  ]
sub.domain.com/#form_name?key1=value1&key2=value2

  • window.history - a javascript object containing the list of URLs visited

  • state - a generic javascript object that can be associated to each URL in window.history and contains info about the state of the page

  • hash - the text following # on the URL

  • self.url_patterns - must be defined on the main module to tell the router module which pages are valid

  • pattern - a text identifying a form (usually similar to the form name)

  • table - used to get a row from the server and populate form.item when the user navigates back to a previously visited page

  • keys - this is sometimes a list and sometimes a key?

  • properties - is this the same as the **properties defined in the form?

While looking at how the routing module works, I kept thinking that the whole thing seems unnecessarily complex. Perhaps my vision is oversimplified because I haven’t used it yet, please let me know if I am missing something. Here are the three things I kept thinking about:

  • The automatic population of item is not necessary
    • The form already knows how to do it because all the required info is in the hash (which makes my third point useless)
    • It makes both the decorator and form code more complex: the decorator needs to manage the form item and the form needs to check if the decorator has already taken care of it
    • One generic server function that loads one row from one table is seldom enough (never in my experience)
    • I would use window.history for the minimum (only the URL) and cache the forms in a global Python dictionary, using the URL as a key; it is faster to get the form back from the global cache dictionary than transforming some data, saving it in the history state, then getting the history state back, transforming it back to Python format and telling the form to use it to rebuild itself
  • I don’t see the added value of self.url_patterns
    • I would like to use a simpler @routing.route('article') decorator in front of every form that should be managed
    • When the app starts and imports all the forms, a global dictionary should be populated automatically as the decorators are executed (rather than explicitly defining self.url_patterns inside the main form)
  • I would like to add the management of the query_close event
    • If an app uses this routing module, then all the form management should be done via this module (no more get_open_form().content_panel.add_component())
    • The routing module knows when a form is about to be unloaded, so it can (try to) call its query_close event and decide whether to interrupt the process of closing this form and navigating to the new one
    • The query_close event should be called when:
      • The app navigates to another form
      • The URL changes for any other reason
      • The browser tab/window is closed

Today I had no time to spend on it, but I will eventually find the time to play with it.
Thanks again for showing us this module and for your help.

1 Like