How to catch the view parameters sent with JetViews ?

Hello,

I’m new to webix and I’m trying to use Webix Jet navigation.

I’m using the following syntax to open a JetView :
this.show(“myview?id=123”);

Nevertheless, I would like the view “myview” to be built dynamically according to the parameter “id=123”.

So, I would like to catch the “id=123” parameter and then perform an Ajax request using this param “id=123” to get the JSON configuration of the view.

Is it possible to do this ?

If it’s not possible, maybe I could just build the view statically, then request the server to “feed” the view with widgets ?

Anyway, I don’t know how to catch the “id=123” sent in the JetView… and this is the starting point !

okay, I get it:

1. I can use urlChange method of the JetView to catch the url parameters “?id=123”

2. Then, I’ll perform an Ajax request to pull the server data using this id=123

3. Then, I’ll use the returned data to feed my view widgets

Is it the right way of doing things ?
I find it strange to put the process of rebuilding the UI inside the urlChange method.

I’ve just seen that the init() method also provide the url parameter, so, I guess it makes much more sense to perform the Ajax call from there, then feed the widgets with server data.

I find it hard to find the right information in a straightforward way : I’m coming from ExtJS and stackoverflow has very few entries for webix.

I really hope it will change in the future, because the product seems really good and very pragmatic.

To conclude, there are some use cases where the initial configuration depends on the url, and I think it would be useful to pass the url argument to the config() method as well, and not only to init() and urlChange().

What do you think?

Currently when sub-url, is changed the top level view is not reconstructed. For example, if you have /top/data and navigate page to /top/list the “top” view will not be reconstructed. It will be preserved as is, only the urlChange handler will be triggered

Such approach allows preserving parts of UI not affected by navigation, which improves performance and UX of the app. It is especially important if you have some complex widget in the top view and do not want to fully reconstruct|reload it on sub-view navigation.

The expected approach is to have a pure UI config returned by the config method. So it must not be affected by the id of the loaded record. And inside of urlChange handler you can place code which will fill the UI with data and adjust its state based on the url’s parameters

the init() method also provide the url parameter

Same as config, init is called only during first UI initialization, it is a good place to load some common data ( list of options for select in form for example )

would be useful to pass the url argument to the config()

Not really. If a view is not reconstructed on each URL change ( as it works now ) this will not be useful, as config will be triggered only once.

where the initial configuration depends on the url

From our experience, in such cases, the difference can be very small - in such case hiding|showing part of UI from urlChange works fine. Or it can be a really huge difference, in which case it has the sense to create two different views.

In the case when a difference is quite big, but views still share many common traits, you can create a base view and create a necessary number of subclasses, in which you can redefine necessary parts of UI|logic. Thanks to es6 syntax it is rather easy.

This is clear, I’ll try this approach. Thanks very much for your time.

In my case, my app is a flexible doc management following the old Lotus Notes concepts : a formId is stored in each record, and you cannot know what kind of ui you have to build BEFORE you have loaded the record.

So the process is:
Load the record by Id => discover its form id => get the right form json config from a repository => inject the form config at runtime.

An average app could have around 10 differents forms, with 20 to 200 fields each, depending on the use cases.

I’m really too new to Webix … I spend 10% of my thinking, 89% in the documentation, and 1% coding… This is not very efficient

By the way, only one week using your framework, and I already love its pragmatic approach.