but now we are on api of tabpanel we get into the the discussion what api do we need
We really don’t want the same api as the legacy tabpanel. it must be way way less, way more streamed, i could even argue that the current bootstrap tabpanel is fine, because at design time you can set the form and thats what you should do…
And i see tabs property which can be altered at the server side so you can add tabs already on the fly
So I got the current Bootstrap Tabpanel working. I don’t think most developers will be fine with this…
var tab = {
"active": {"type":"boolean","default": false,"tags": { "scope" :"private" }},
"containedForm": formName,
"text": {"type":"tagstring","default":"tab"},
"relationName": ""
}
var tabs = [tab]
elements.tabpanel.tabs = tabs
I don’t think anyone wants to remember what all that JSON should be and proper format. We need real API calls into it.
I understand wanting to change the API, however many solutions have some base forms / framework code that acts upon tabpanels. If you start separating the logic of the components, just because they are rendered with a different front-end framework, that could get complicated. Having two sets of API’s for components that do the same thing is more than my brain can handle If you do choose to make a new, more simple API, would you then port it to the non-responsive components, so at least they all share the new API?
I think if the NG Components have a separate API from the Smart/Web Components, then that’s ok, we can learn the new stuff going forward. However I wouldn’t be in favor of different API for non-responsive NG components and Bootstrap NG Components. If I’m in NG client, and using a tabpanel, I would want the same API’s, regardless of whether its responsive or not. Anyway, that’s my 2 cents.
Api calls are kind of bad, because those are now in ngclient actual calls going from the server to the client, doing it stuff and then coming back…
(and we then have to send already stuff that is also changed around that so that it is the exact state that the component expect to be in)
Doing it all with model is way nicer, then nothing is send to the client except in the end.
Api calls can be optimized by using server side code in the component, then you can make it again a model api. so that is something we can do for the bootstrap tabpanel
But the bootstrap tabpanel will definitely not get the exact same api. A way more simpler streamlined api.
Its the same for many other components, now a legacy label can do pretty much everything, displaying images,text, rotation you name it. That will also not happen anymore, components should do 1 thing and 1 thing well, not 100 things a little bit.
For example the bootstrap components or any none legacy other components will also not get foreground,background,font and all those properties… They will just get style/class and and a few other specific ones that they need.
For example a tabpanel, if you get an existing nice (bootstrap or material) tabpanel component where there is already an angular variant of then we should not try to shoe horn the servoy api in it and map it back to the api of the angular component, no we should just expose the angular api, no fighting against the client side component.