Open AlexeyKashintsev opened 8 years ago
Is NativeAPI widget.element
insufficient?
Here some elaboration. Sometimes (really often actually) developer must provide modern usable and reaaaaly beautyfull GUI for the best user experience. Especially in HTML5 clients. It's obvious that we can use any libs or GUI frameworks to rich this. But stills it gets really bad because:
img
tag working PlatypusJS ORM, working with PlatypusJS events like onActionPerformed etc. May be this is not really the best example, but the point should be clear - GUI flexibility without harming general coding style in application and also availability of widgets in Designer.widget.element
is good to make some grooming, but still it's not the right way to make completely different widget. I totaly can say that 'cause I passed through working with it in past year in CBSM project with Cordova. I also used Onsen wich is based on AngularJS btw. So both ways are complete mess.
Also this API will be reaaaally usefull in new Corvus. I think we need to determine this API task more precisely.
widget.element
is much more powerfull. It allows to build composite UI in browser and thus to combine widgets of different nature in one UI.
PS: I also wanna say that this API feature can make PlatypusJS more attractive tool for many people. Some custom widgets developed by community could bring more interest to platform. PPS: Folks are supporting this feature :)
Update commentary.
Still I used widget.element
only as way to rich DOM element to make some grooming. Do you mean that any other DOM element can be assigned and this will work?
For better understanding of each other, we need concrete examples of adaptors code. Let's discuss them and thus we will reach a clear point.
I believe, that there is no need to develop adapter layers in an application at all, because any framework or UI library should be able to accept JavaScript objects regardless of theirs source. At this moment, Platypus UI is such UI library.
On the other hand, since Object.observe
was eliminated, and ES6 proxies were added, we should consider data binding layer in any our browser application, wichever UI library we will use. Otherwise we are pushed to use framework-specific ways of data binding.
There are widgets in Platypus UI library without internal structure of widget.element
. So, an application developer is able o add an any widget from any library to Platypus UI widget and vice versa. See web socket example for details.
Also, i want to make the point about desginer clear. Do you want Platypus.js to support third party widgets in its UI Factory at runtime and in palette and layout in designer? I think this feature is completely separate from Platypus UI library itself. Am i right?
Recently @jskonst provided this good example of using placeholders as an alternative way of widgets customization. At first sight this thing is looks like much closer to the things I was talking about: platypus style events, custom markup etc. But after closer look I found out two things.
I guess if second bullet is correct, so this exact issue is 80% solved. Another 20% is the first bullet which is still would be a great feature anyway if it will be done. But right now I am extremely interested in second bullet. So am I right about manual binding?
Yes. You are absolutely right. The new branch manual-binding
will be merged to master
after tests transferring to Travis CI.
UPD: Marat, about UI Factory and palette and stuff in designer: yes, that is exactly I was talking about. And I understand that it's complicated. But this would be great anyway. Just to be more clear I wanna say that by 3rd party widgets I meant not only exact 3rd party frameworks and libs, but also widgets made for platypus such as widget in example which @jskonst made. In this case 3rd party widget for me is any custom UI element with it's own markup and styles (and sometimes with behaviour) which can be plugged and used inside application. So this is first bullet in my recent comment.
I believe that placeholders can cover needs of application UI developer in case of using third-party and external widgets.
For long enough, yes.
Add API for custom UI widgets