I use the tabs on a page. If I am on a tab 2 or higher and save the data record, the tabs jumps back to tab 1. Is there something wrong with my code or is there a possibility that the current tab is retained when saving?
Thanks much, Kai
Tabs and saving
Re: Tabs and saving
This is the standard behaviour. Saving in AppGini DV means posting back data to the server which returns a completely new page (=reload). So, after reloading the page you will see the default view which means: first tab is active, unless you change it on your own. You may have a look at the new .activate() function.
Using javascript you can even store your currently selected active tab (for example in localStorage) and restore the saved state on page load, but that is outside the scope of our lib and requires additional Javascript coding.
Using javascript you can even store your currently selected active tab (for example in localStorage) and restore the saved state on page load, but that is outside the scope of our lib and requires additional Javascript coding.
Kind regards,
<js />
My AppGini Blog:
https://appgini.bizzworxx.de/blog
You can help us helping you:
Please always put code fragments inside
AppGini 24.10 Revision 1579 + all AppGini Helper tools
<js />
My AppGini Blog:
https://appgini.bizzworxx.de/blog
You can help us helping you:
Please always put code fragments inside
[code]...[/code]
blocks for better readabilityAppGini 24.10 Revision 1579 + all AppGini Helper tools
Re: Tabs and saving
Thank you for the clarification. good to know that it is not because of the integration of the script. I then try to solve it myself.
Re: Tabs and saving
Hi Jan,
maybe, as you write such settings could be saved, this could be a feature (request): Return to the last tab = session/true. TRUE would always return to the last used tab (even between sessions, SESSION could limit this behavior to the current session only.
Olaf
maybe, as you write such settings could be saved, this could be a feature (request): Return to the last tab = session/true. TRUE would always return to the last used tab (even between sessions, SESSION could limit this behavior to the current session only.
Olaf
Some postings I was involved, you might find useful:
SingleEdit - Prevent concurrent edits on records; Field Permissions; Column-Value-Based-Permissions; Custom (error) message; Audit Log; Backup your database; Two Factor Authentication; Block brute force (failed) logins; Add 2nd SAVE CHANGES button; Place a search on details view
SingleEdit - Prevent concurrent edits on records; Field Permissions; Column-Value-Based-Permissions; Custom (error) message; Audit Log; Backup your database; Two Factor Authentication; Block brute force (failed) logins; Add 2nd SAVE CHANGES button; Place a search on details view
Re: Tabs and saving
Hi,
thanks for your feedback. Storing the tab-state would be useful in many scenarios, I completely agree with you. By integrating the .activate() function I have done the first step: We can do so depending on our specific needs and scenarios.
So, on the first glance I see the following todo's and challenges:
TODOs
Without digging deeper I can see the following challenges:
I hope someone else will have the knowledge and may find the time for programming, publishing and supporting her/his working solution here.
Anyway, thank you, Olaf, for your feature request!
thanks for your feedback. Storing the tab-state would be useful in many scenarios, I completely agree with you. By integrating the .activate() function I have done the first step: We can do so depending on our specific needs and scenarios.
So, on the first glance I see the following todo's and challenges:
TODOs
- on load of dv: check if user has enabled this feature
- load mru tab name (or any unique identifier) for this dv from localStorage, if exists
- activate the tab using .activate() function
- react to activation of a tab after load
- save the name (or any identifier) of the active tab in localStorage for this dv
Without digging deeper I can see the following challenges:
- similar functionality for custom tabs (top) AND children tabs (bottom)
- dv name may change when re-generating your app
- tab-name may change when changing in TABLENAME-dv.js (addTab() function)
- avoid recursion
(activate tab -> save -> update tabs -> load -> activate tab == recursion) - lazy (re-) loading of children tabs...
- when pressing refresh-button (in child-tab)
- after modal-dialog closes
- activation of tabs which have been hidden by code (using .hide() or .fadeOut() for example)
- activation of (children-) tabs which are not available any longer
- due to missing permissions
- because the parent-detail settings have changed
- because the child-tables have been deleted
I hope someone else will have the knowledge and may find the time for programming, publishing and supporting her/his working solution here.
Anyway, thank you, Olaf, for your feature request!
Kind regards,
<js />
My AppGini Blog:
https://appgini.bizzworxx.de/blog
You can help us helping you:
Please always put code fragments inside
AppGini 24.10 Revision 1579 + all AppGini Helper tools
<js />
My AppGini Blog:
https://appgini.bizzworxx.de/blog
You can help us helping you:
Please always put code fragments inside
[code]...[/code]
blocks for better readabilityAppGini 24.10 Revision 1579 + all AppGini Helper tools
Re: Tabs and saving
Hi Jan,
I agree, there are several things to consider.
Your points
- dv name may change when re-generating your app
- tab-name may change when changing in TABLENAME-dv.js (addTab() function)
are good, but does the title not only change if the user (AG user, not application end-user) changes things? So he is the developer and would need to adjust the code. But I agree, this get's forgotten and there will be support demands/questions.
I also agree with the problems you point out
- activation of tabs which have been hidden by code (using .hide() or .fadeOut() for example)
- activation of (children-) tabs which are not available any longer
These are probably harder to match. It actually may be easier to send the current tab back to the database (ajax) and then, when the pages are created pull the value from the database using php to create necessary JS code on the fly to avoid some of the problems you named.
Olaf
I agree, there are several things to consider.
Your points
- dv name may change when re-generating your app
- tab-name may change when changing in TABLENAME-dv.js (addTab() function)
are good, but does the title not only change if the user (AG user, not application end-user) changes things? So he is the developer and would need to adjust the code. But I agree, this get's forgotten and there will be support demands/questions.
I also agree with the problems you point out
- activation of tabs which have been hidden by code (using .hide() or .fadeOut() for example)
- activation of (children-) tabs which are not available any longer
These are probably harder to match. It actually may be easier to send the current tab back to the database (ajax) and then, when the pages are created pull the value from the database using php to create necessary JS code on the fly to avoid some of the problems you named.
Olaf
Some postings I was involved, you might find useful:
SingleEdit - Prevent concurrent edits on records; Field Permissions; Column-Value-Based-Permissions; Custom (error) message; Audit Log; Backup your database; Two Factor Authentication; Block brute force (failed) logins; Add 2nd SAVE CHANGES button; Place a search on details view
SingleEdit - Prevent concurrent edits on records; Field Permissions; Column-Value-Based-Permissions; Custom (error) message; Audit Log; Backup your database; Two Factor Authentication; Block brute force (failed) logins; Add 2nd SAVE CHANGES button; Place a search on details view
Re: Tabs and saving
Good morning Olaf!
Thanks for your valuable feedback! We agree on the essential points, which is good.
You will need additional table(s) and configure permissions, set ownership and cleanup usersettings. The complexity of the required javascript code will be pretty much the same. The challenges addressed above will be pretty much the same. Plus you will need additional Javascript code for the AJAX-call and you will need additional PHP code for handling the AJAX-call, for database updates and for generating the script. I'm afraid installation, deinstallation and configuration of a mixed solution could become more complicated than just including a "myTabHandler.js" file.
So, I still think it would much, much easier using localStorage and pure Javascript.
Anyway, if someone finds the time to build a working plugin in PHP+Javascript or pure Javascript this would be great for all of us! I would definitely give it a try if someone publishes something like this.
Thanks for your valuable feedback! We agree on the essential points, which is good.
I'm not sure if this will be easier:It actually may be easier to send the current tab back to the database (ajax) and then, when the pages are created pull the value from the database using php to create necessary JS code on the fly to avoid some of the problems you named.
You will need additional table(s) and configure permissions, set ownership and cleanup usersettings. The complexity of the required javascript code will be pretty much the same. The challenges addressed above will be pretty much the same. Plus you will need additional Javascript code for the AJAX-call and you will need additional PHP code for handling the AJAX-call, for database updates and for generating the script. I'm afraid installation, deinstallation and configuration of a mixed solution could become more complicated than just including a "myTabHandler.js" file.
So, I still think it would much, much easier using localStorage and pure Javascript.
In addition to this, this PHP-based solution would no longer be possible with pure Javascript, but would also require php and database changes. So it would no longer be an option as a feature request for the AppGini Helper Javascript Library, which is clientside, only.... this could be a feature (request) ...
Anyway, if someone finds the time to build a working plugin in PHP+Javascript or pure Javascript this would be great for all of us! I would definitely give it a try if someone publishes something like this.
Kind regards,
<js />
My AppGini Blog:
https://appgini.bizzworxx.de/blog
You can help us helping you:
Please always put code fragments inside
AppGini 24.10 Revision 1579 + all AppGini Helper tools
<js />
My AppGini Blog:
https://appgini.bizzworxx.de/blog
You can help us helping you:
Please always put code fragments inside
[code]...[/code]
blocks for better readabilityAppGini 24.10 Revision 1579 + all AppGini Helper tools
Re: Tabs and saving
I've already researched myself and there seems to be a simple solution here that you can possibly incorporate easy into the script?
https://www.tutorialrepublic.com/faq/ho ... tstrap.php
https://www.tutorialrepublic.com/faq/ho ... tstrap.php
Re: Tabs and saving
It would be great if you could share your experiences and code with us once you have integrated and got it running. Thanks in advance!
Kind regards,
<js />
My AppGini Blog:
https://appgini.bizzworxx.de/blog
You can help us helping you:
Please always put code fragments inside
AppGini 24.10 Revision 1579 + all AppGini Helper tools
<js />
My AppGini Blog:
https://appgini.bizzworxx.de/blog
You can help us helping you:
Please always put code fragments inside
[code]...[/code]
blocks for better readabilityAppGini 24.10 Revision 1579 + all AppGini Helper tools
Re: Tabs and saving
i try there and then give a feedback
Re: Tabs and saving
This code should work in the tablename.js.
but since your script outputs the tabs, I have no idea how to use data-toggle = "tab"; can add to the links.
sorry i'm not a coder ...
Code: Select all
$('a[data-toggle="tab"]').on('shown.bs.tab', function (e) {
localStorage.setItem('activeTab', $(e.target).attr('href'));
});
var activeTab = localStorage.getItem('activeTab');
if(activeTab){
$('.nav-tabs a[href="' + activeTab + '"]').tab('show');
}
sorry i'm not a coder ...