Binding data to controls widgets in CLFramework

I added basic bindings mechanism on CLFramework, for connect data with widgets.

First, a ObservableCollection; any change on the collection have representation on the data showed for the widget:

http://www.youtube.com/watch?v=m8nC2gB4SUk

For the moment the ObservableCollection only works with CLListview widget. Later will work with CLGrid too.

Second, basic value bindings of a model (a person) with the GUI:

http://www.youtube.com/watch?v=hYX2NCav_ZE


Regards.

Hi nullPointer

I was wondering what would be the actions to take at the level of your code and at the level of Pharo to
support a good and easier integration in the future?

Context: We are discussing with alain about a list of actions to clean and move on the UI of Pharo
        - merging/integrating polymorph
        - removing useless leaf in the widget trees
        - better Event (both Morphic and system)
        ...
Now my fear is that if we do not take action now about thinking about pushing changes that can benefit to everybody
from your system to pharo then the integration (I would like to avoid yet another level of widgets and yet another layer
of announcement/events....)

So the message and question is how can we improve the infrastructure so that your system is easier to build?
what is the code that you would push from your code to the infrastructure?

The same question applies to the HPI framework.
It is important to understand that each time we improve the infrastructure, the overall system gets better and easier to build
solution on top.

So I'm eager to read your answers.
Stef


On Mar 6, 2011, at 2:21 AM, nullPointer wrote:

I´m not sure understand good all message, Stephane.

I believe the integration is easy from CLFramework to Pharo and reverse and really don´t need changes:

The mechanism than widgets launch events is the same of system, the trigger mechanism. I only encapsulate that basic functionality on a TCLPublishEvents trait, for send rich event arguments in some cases, and force the handler of event is always of two parameters, the sender of event and the information of event, but the functionality for launch the events is the same of system.

In some types of control usability I implemented news widgets: listview, button, treeview, statusbar, grid, splitterpanel and tablepanel. The others widgets be Polymorphs sons. Really a widget in CLFramework is a normal morph implementing the trait TCLControl, for only basic properties (#location, #style ,#tabIndex, #text ..... ). Exists others traits: TCLCollectionControl for list type widgets, TCLContainerControl for panels,
TCLObservableCollectionListener for controls than need listen a ObservableCollection instance etc  The reason of that news widgets is the velocity, clean methods interface and inexistence like basic and huge needed grid.

Really Pharo has been repeat updated and I didn´t have problems. I believe than unique dependence of Pharo is Polymorph. The unique problem I have in last step is the imposibility of save on a external file the preferences. In Pharo 1.1 that works. I did use that functionality for my Deployment tool mechanism.


Clean the system and remove useless code from system is a great idea, but in GUI I believe Pharo needs some enhancements:

·Another more fast way for render the morphs, the GUI still slow compared another languages.

·Posibility of open independent windows (integrate ffenestri on Core??).

·Embed a pharo world on a browser for have the same application on the desktop or the web, ala Silverlight (something I did see lasts days).

·Basic widgets like a good and fast grid (not like my shit grid) for upset, group, filter and edit data. I believe the difference in some cases for create enterprise applications or not create will be widgets like that.

·Bindings implementation on widgets ala WPF/XAML. The link of widget value and data model must be with bindings mechanism, not with simple events.

·A GUI designer. I believe the Morphic designer is the good way.


I wait understood the question.

Regards.

On Mar 6, 2011, at 11:20 AM, nullPointer wrote:

good to know
we should have a look at your widgets when we will do a pass one all the widgets.
First we should clean polymorph.

yes this is why somebody should look at SimpleMorphic
and this is why we should clean Morph.

> ·Posibility of open independent windows (integrate ffenestri on Core??).

Not easy it requires a large effort. I would love that but at least 2/3 months of work.
+ probably VM changes.

> ·Embed a pharo world on a browser for have the same application on the
> desktop or the web, ala Silverlight (something I did see lasts days).
>
> ·Basic widgets like a good and fast grid (not like my shit grid) for upset,
> group, filter and edit data. I believe the difference in some cases for
> create enterprise applications or not create will be widgets like that.

Ok

> ·Bindings implementation on widgets ala WPF/XAML. The link of widget value
> and data model must be with bindings mechanism, not with simple events.
>
> ·A GUI designer. I believe the Morphic designer is the good way.

but this will need to again integrate other widgets and event model.

>
>
> I wait understood the question.

yes

Now the grid widget accept Observable collections too:

http://www.youtube.com/watch?v=ENyNcfMw-P0

Regards