i just quickly tested it and splitpanes should work fine also the popup menu is working for me
the htmlview showing a href with some javascript call back is not working (but it should)
this is because of a very small bug (a } is in a wrong place should be a few chars to the left… i fixed that)
Hi,
Thank you for looking into this. I have loaded your sample solution can confirm split panes and popup menus work fine. There must be something else stopping my forms from loading. Will investigate.
A design question:
In the canvas example (responsive design) everything is in the form. Menu structure - top menu - footer. All is arranged with CSS and you don’t use separate forms for the menu-bar etc. with split/tabs and put the separate forms on the tab-form.
What will be the structure for responsive design applications? Will this work with different forms/templates for menubar, footer etc or will the design structure be something with a base form for the main-template where you create sub-forms below per part.
For responsive design everything is in blocks with css (LayoutContainer). The layoutcontainer can be placed on a position on the form. Is it possible to create a layoutcontainer as a (related)form?
Deeplink/(start)parameters question:
Everything is single-page.
How can parameters be set by the url? Is it possible to set the url for deeplinking to a form or for example a product.
Will there be some routing services in Servoy NG-client? Like in this example of AngularJS: https://docs.angularjs.org/tutorial/step_07
the canvas example is 1 form that has all the components, thats correct.
But in the end it should be possible to use a “tabpanel” bean that includes a form on a specific location in the layout container hierarchy and that form is then just nested (just like a tabpanel)
I do think that mixing absolute positioning with responsive would be a bad idea then. So everything also the subforms should be responsive.
Also inheritance,so you have a base form with various components) and then a subform that places a few other components on certain positions, should also work.
deeplinking should work as before, so you get the parameters in the onsolution open. where you then decide where to go to. You could create a case for this so that we can schedule to look at this.
Such a case already exists: https://support.servoy.com/browse/SVY-7629
jcompagner:
if you want to create a component that is a composition of other components you can do that just fine, for example this is a components template:now you composed your new component and it uses 2 others and you pass some state to them from yours.
But this is just for servoy 1 component that has encapsulated 2 others that servoy (the designer or runtime) doesn’t know anything about.
If you want to expose properties (that a servoy developer can set in the designer) for those internal components your new top component needs to have those properties in the spec and pass that to the child components through that state object.
So you can do template partials across components and you can refer to resources outside of your component. Exactly my point — this is not composability. Having to reimplement child component functionality on the parent component is not composability. This is a mess waiting to happen if you try and do anything other than a flat structure of components.
This stuff has been figured out for a while now and there are well established patterns. Declaring dependencies in the package.json file (your spec file), inheriting/extending library code in the angular module declaration, not allowing any references outside of your component package, etc.
And while you’re at it, your spec file is being used for two completely different functions. Package description and resource description (model, handlers, and types). I would split these into two files: package.json and componentName.spec. Separation of concerns and all that.
david:
So you can do template partials across components and you can refer to resources outside of your component. Exactly my point — this is not composability. Having to reimplement child component functionality on the parent component is not composability. This is a mess waiting to happen if you try and do anything other than a flat structure of components.
No, Johan is explaining you can use the tag (representing a component) within another component template to get composition.
david:
This stuff has been figured out for a while now and there are well established patterns. Declaring dependencies in the package.json file (your spec file), inheriting/extending library code in the angular module declaration, not allowing any references outside of your component package, etc.
Johan suggestion is composition as defined by angular…nothing else
It’s best practice to declare use local references, but we can’t block CDN access either.
david:
And while you’re at it, your spec file is being used for two completely different functions. Package description and resource description (model, handlers, and types). I would split these into two files: package.json and componentName.spec. Separation of concerns and all that.
We will take this in consideration.
Thanks for the feedback!
Jan Blok:
david:
This stuff has been figured out for a while now and there are well established patterns. Declaring dependencies in the package.json file (your spec file), inheriting/extending library code in the angular module declaration, not allowing any references outside of your component package, etc.Johan suggestion is composition as defined by angular…nothing else
It’s best practice to declare use local references, but we can’t block CDN access either.
Another advantage of declaring dependencies is your tooling. Easily alert the developer if a dependency is missing and whatever sharing mechanism you come up with in the future can ensure dependencies are shared as well.
We already have it a bit build in for tooling about the dependencies…
We already check for versions and so on. If you use 10 components then any of those components gets also the dependencies of all the others… (because all the css and js are just included in the main page) (so dependencies are automatically already always shared)
Until we really can use shadow dom and real webcomponents (they are really isolated, like implemented in an IFrame) i don’t see at runtime another way how components will not see the dependencies of each other.
Thats why we have version checks in our libraries section, so that we can warn people that 2 components they are using are using different (older) versions of the same lib.
Not talking about runtime dependencies. If I have the following code in a component, how does the tooling know if “anothercomponenentsdirective” is missing from the components list? Do you go parse all the view code?
<div>
<anothercomponentsdirective astate="something">
<andsomeother state="else">
</div>
you can already give that i guess…
first in your module you have to declare a dependency on the module of the
and then in the library array you can give it the js file of the component.
I guess for this scenario we could do it a bit nicer that you can have a spec property like: dependencies: [“anothercomponentsdirective”]
so that it is a bit more clear, but you kind of need the module include to do yourself.
For the NG-Client you have the Servoy Default Components. When you have created your own component for example for a button or a field then you want to use that as default for your project.
Is it possible that the default buttons are getting your new component as default. The same for solutionmodel when you place a button or a field. Is this always the default or can it change to your own new default field, button etc.
Google has a project for material design. Material Design is a specification for a unified system of visual, motion, and interaction design that adapts across different devices and different screen sizes. Also components for AngularJS: Website: https://material.angularjs.org
There is complete JS and CSS files for all the animations and responsive designs.
When you look at the code for a responsive form with some buttons it looks like it is very easy to integrate in Servoy8.
{{title1}}
Primary (md-noink)
Disabled
{{title4}}
This would be nice as default servoy components in the NG-client.
the default components are made to be as much backwards compatible as possible with our current smart or webclients components.
Currently there is not an easy way to alter them and that the altered versions are used of those components.
(because altering them would mean that the behavior is changed for web,smart and ngclient)
Its better to just make a alternate set (which our components could be a base) and use that.
The soluton model must still be updated to play nicer with beans (you can already create custom beans and use them in solution model, but you have to use newBean() ans set a special innerHtml with some json
We are already looking at that angular material design components, but those won’t be the default but just another set of components. (for example the properties/api will be completely different, those components will not have settings for “font” or “background-color” and so on, mostly likely they just have style and class)
jcompagner:
you can already give that i guess…
first in your module you have to declare a dependency on the module of the
and then in the library array you can give it the js file of the component.
I guess for this scenario we could do it a bit nicer that you can have a spec property like: dependencies: [“anothercomponentsdirective”]so that it is a bit more clear, but you kind of need the module include to do yourself.
I recommend using CommonJS package format like everyone else. That format covers everything you need — including all the stuff you haven’t thought of yet.
Also recommend using expected directory boilerplate. All js, css and model files go in those directories — not at the top level (fix your boilerplate generating code). Rename componentName.spec to package.json. Put models in their own files. Etc.
As you get into the html5 world, if there is a common convention or best practice — use it! There aren’t that many obvious ones so if you deviate (edit: from something so well established), it is going to be suspect.
we are not going to rename component.spec to package.json (also package name is more a complete package description so the full jar, we only describe there 1 component not a whole package)
besides that,if we use a generic .json extension, we loose the benefits we have for IDE’s that can then really be triggered based on the extension for, for example, schema validation .
(thats how it currently works for the schema we provide for .spec files…)
edit: the difference also is that for example package.json (or bower/grunt stuff) is really about building the package (which would be in our case building the full jar of the set of components)
But our spec files have nothing to do with building the package, they are needed at runtime, they have to be in the “bin” or “dist” folder output when you build the package.
We already looked quite heavily if we could use for example bower, but that could make it for our users again quite complex. (and we have to really integrate it into our developer to make it way easier to use)
But if you wanted to use package.json/bower/grunt files to build your component bundle that you then use in your product or make it available for 3th party servoy developer then you could already do that.
Because that is just the building part of a full package that we didn’t really touch yet.
Is there a new release on the way soon?
currently working quite hard to get the client in ngclient better (better backward compartible) besides improvements to the editor (like responsive layout)
maybe next week we could do a new public alpha build.
On our road map i also would just like to introduce nightlies so that you can always if you really want to jump the the latest version build the last night.