david wrote:I guess I need to see a more complete example then. The only example I see is from
here where the child component is included in the markup. Then in the
spec I see the child components listed under the model. Wouldn't this be better listed under a "dependencies" section?
Then in the
js file, I would expect something like:
- Code: Select all
angular.module('servoycomponentsNestedsimplecomponent',['servoy','childComponent1','inheritedComponent2']).directive(...
the thing is what are we really talking about here?
Are we talking about composition so 1 component uses a few other components to represent itself.
or are we talking about extending? (inheritance)
Inheritance is not really done in angular see for example
http://stackoverflow.com/questions/1700 ... -directive for a few option that you have (like require, or having 2 directives with the same name)
But a component (directive) doesn't really have an real option to say "extend".
Nested components, so the things in the spec like mychildcomponents: "components[]", that we talk here above are a bit different all together.
Because that's about composition in for the designer. So the users (servoy developers) of your component can drop in any other component(s) they want and we fill that property
So the module of that component can't include anything, because it doesn't really know what it gets from the system.
more info is also here:
https://wiki.servoy.com/display/DOCS/Co ... perty+typethe svy-component-wrapper directive that we provide is just an easy way to use those components that are stored in that property.
But we don't use that ourself, for example you could look at the portal.js code as an example, its a quite big example but for the components part that we get we generate the 'cellTemplate'
based on what is in the model of the childComponents array
(its even more complex because this is also directly a repeater)
david wrote:to expose the functionality of inherited components. In addition to being able to compose multiple components together, this would also cover the ability to create a headless component with a base set of functionality that you would use across a bunch of components. For example, if I wanted to create components for all of
Kendo UI's core widgets, I would first create a "base" component (that doesn't get listed in an editor sidebar, so you need a setting for this) with all the common functionality all of their widgets use.
what is the common functionality (what is really a base component?)
Can't you build that in attribute directives? That you then include in the real components?
For example like our svy-format or a simple one like svy-scrollbars that takes care of the scrollbars for a component based on the value it gets.
Or you can build services that components use (that are injected into your components)
Do you also want to sort of "inherited" and 'extends" templates of a component? then i think you need to look at transclude:
https://thinkster.io/egghead/transclusion-basics/david wrote:Back to having a dependencies section: currently it looks like you specify a library path to anywhere outside of the component scope if you want to pull in foreign resources. This breaks compartmentalization of components. What if that path resource isn't there? You need a dependencies section so you know what is required and to enforce only allowed paths.
if component developers really want to use a CDN or something like that then they can do that.
For use that is not recommended because it would be better not to depend on outside resources (maybe the servoy application is really in house)
So yes it is better to use local things, but we will not enforce this.
Our dependency section is the libraries options in the spec file. We even look at the name and the version to see if there are conflicts and we take the latest one of the same name (over all the components)
Maybe in your example we also should have a dependency section in the manifest, because i guess if you make 1 package for kendo, then you want to specify that once and that is then used for all the components in that package.
david wrote:jcompagner wrote:Do you want to have predefined components structure that are the selectable in the designer and are directly really form components with there own state and api on the server side?
This seems natural if your components are architected to allow composition of independent components in a way that maintains their character.
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:
<div>
<anothercomponentsdirective astate="something">
<andsomeother state="else">
</div>
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.
But this has nothing to do with the components type that servoy provides. Thats really for doing composition through the designer.