Linked by Thom Holwerda on Mon 9th May 2011 21:14 UTC, submitted by Elv13
Qt Since Nokia announced its switch to Windows Phone 7, people have been worried about the future of Qt. Well, it turns out Nokia is still going full steam ahead with Qt, since it has just announced the plans for Qt 5. Some major changes are afoot code and functionality-wise, but the biggest change is that Qt 5 will be developed out in the open from day one (unlike Qt 4). There will be no distinction between a Nokia developer or third party developer.
Permalink for comment 472539
To read all comments associated with this story, please click here.
RE[5]: Meh
by Nelson on Tue 10th May 2011 13:17 UTC in reply to "RE[4]: Meh"
Nelson
Member since:
2005-11-29


The big difference between QML and XAML is that you just can't add nontrivial logic to XAML; all the logic ends up in C# file. XAML can only do the "declarative" part, i.e. you can do simple bindings there.


You can do multibinding, binding to ancestor, element bindings, binding with data validation, binding to pure XAML data sources, priority binding, result filtering in XAML.. ?

PLUS really anything else under the sun you can imagine by creating a markup extension (Hint: "{Binding ...}" is simply a built in markup extension.)

But it speaks to a greater issue, and its a valid one, which is testability and that of a separation of concern.

The fundamental look of a View, and the mechanics behind that view, should be separate things in my opinion. This is the difference between a View (which should be pure XAML ideally, and a ViewModel which is simply an adapter for the Model).

So in my View I handle the layout, where bindings will appear, and do all the visuals (animations, caching brushes, freezing resources, etc..)

The ViewModel is where you'd communicate with the model and turn its platform agnostic data into Wpf/Sl specific entities .. you can also optionally present different values for design time and run time so I can see what my UI will look like without having to run my project.

The separation is an important one, and I'm glad its like that (for those who really have a problem with it: you *can* use inline code in XAML, though not in Silverlight iirc). Intermixing logic with my UI code in QML doesn't sound like my cup of tea.



What does this mean?


XAML is directly woven into the .NET object model. Every XAML element corresponds to a .NET Element 1:1. I can traverse them using C# and have first class support inside the IDE.

Besides, Javascript is such a yuck language to use when compared to C# for these kind of things. A typeless, completely dynamic language is really an abomination .. and should never be a part of the picture moving forward.

Hell, I'd rather do C++/QML than deal with the incoherent mess that is Javascript/QML.

Reply Parent Score: 3