Closed htowens closed 8 years ago
Hi!
Ajax tabs were not a part of the original design (although I may add them sometime in the future). The best suggestion I can give you is not to use tabulous if you want Ajax tabs. Otherwise, you could hack up a solution like using JavaScript to change the generated tab links to Ajax.
Has anyone given this more thought? @techiferous do you mind opening this issue again, please... in the hopes of it gaining some attention.
Tabulous has served us well but it is trapped on the server side in its current manifestation in a world that is rapidly packing up it's resources from the server and rendering rich client interfaces locally. As @htowens already envisioned circa 3 years past and it has become necessary for us to bridge that gap
Some of the requirements that we need to address.
There are several ways to approach this, please share your, concerns and suggestions with us especially if the work has already been done.
Rails already has all the mechanisms in place and accessible by which to identify a keyboard ani sare that information with others. We can generate tab and subtab scaffold with data model that represents the
We can have tabulous do a lookup of the model instead of generating it to a hard coded configuration file to avoid BC breaks and keep business as usual while serving database persisted definitions via the scaffold controllers.
Another approach is to simply create a controller which serves the tabulous data structure on request by means of the tabulous api or parsing the tabulous file directly and we could very likely also persist back to the config file by avoiding a database completely.
What do you think, anything you like already? Perhaps you know of an alternative solution to use instead. Please let us know...
@nickl- Thanks a lot for your ideas; you've got me thinking. I re-opened this issue as requested.
I understand what you mean when you say that tabulous is "trapped on the server side" and I think I understand your JSON approach to getting tabulous to interact with a rich client interface.
Before going too deeply into the "how", though, I want to understand the "what" a bit better. What is the main problem you are trying to solve?
Is it performance? Are you envisioning tabs that rely on Ajax to refresh the tab contents?
Or is it architectural, meaning that you have a thick JavaScript client (it loads up and then from then on communicates with the Rails back-end via JSON API requests) and you want tabulous to be used within the thick JavaScript client?
If you're trying to solve that problem, how would you expect the tabs to behave? Could there be more than one tab set? Why would you want to use tabulous?
Or is it architectural, meaning that you have a thick JavaScript client (it loads up and then from then on communicates with the Rails back-end via JSON API requests) and you want tabulous to be used within the thick JavaScript client?
@techiferous ditto, nail on head. AngularJS frontend consuming rails backend through JSON.
If you're trying to solve that problem, how would you expect the tabs to behave?
I think this is best handled in a phased approach.
P1. Exporse tabulous data structure as JSON. - once we have the data we can start playing with it P2. Parse and render tabulous JSON structure in JavaScript producing easily themeable/customizable tab mark-up. - kinda like tabulous is today
I still think having the structure as it is today, able to generate and configure/extend on the backend. The automation in the browser would likely produce retrieve the named tab set and populate a template as configured on the client.
Could there be more than one tab set?
Any reason why not? Tab sets and sub tabs all the functionality we are used to today.
Why would you want to use tabulous?
Two reasons mainly which feed into each other causing a chicken or egg conundrum and infinite loop if .pondered extensively.
Not sure if that addresses your enquiry as I am not sure how that matters or helps us solve the problem. Care to elaborate?
What are your immediate thoughts and ideas? Schedule? Do you have time to get involved?
@nickl This is a fascinating idea; I'd like to explore it some more.
About multiple tab sets: nope, no reason why we shouldn't have them. Just curious.
So I can see how tabulous, on the server side, can render up some JSON that represents the current state of the tab set and then JavaScript can inflate this JSON into actual HTML to be rendered and inserted in the DOM.
I think it might be tricky, however, to split the application state between the client and the server. For example, tabulous has rules for "visible when" and "enabled when". I could envision state changes in the thick JavaScript client that would warrant a change in tab visibility or enablement. In those cases, the thick JavaScript client would have to ask the server to recalculate the state of the tabs. Is this going with the grain of the architecture or is this fighting with the thick-client style of architecture?
As for my schedule and whether I have time to get involved: not really anytime soon. I'm moving in a few weeks and then expecting a baby a couple months after that, so I'll have my hands full for the foreseeable future!
If you want to move forward with something it might make sense to consider a separate gem that plugs in to tabulous to provide this behavior.
@nickl- Were you able to come up with some way of doing this with Tabulous? What path did you guys take?
I've decided that tabulous' architecture is firmly in the server-side rendering world and should stay there. I think we'd end up with a pretty complicated mess if we tried to force a server-side rendering tool to be something it's not. Better just to make a new tool. Also see https://github.com/techiferous/tabulous/blob/master/FUTURE.md
Hi,
Just taking Tabulous for a spin at present, and I like the look of it.
Do you have any suggestions for a clean way to get the tabs loading their content on demand, via Ajax? I think this would give a much more RIA feel to my app.
Thanks for any pointers you can provide!
Henry.