Servoy Forum

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.
<section layout="row" layout-sm="column" layout-align="center center">
<md-button>{{title1}}</md-button>
<md-button md-no-ink class="md-primary">Primary (md-noink)</md-button>
<md-button ng-disabled="isDisabled" class="md-primary">Disabled</md-button>
<md-button class="md-warn" ng-click="isDisabled = !isDisabled">{{title4}}</md-button>
</section>

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 wrote:you can already give that i guess..
first in your module you have to declare a dependency on the module of the <anothercomponentsdirective>
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.