Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Desclaimer - i LOVE xaml. I think it's the best thing to happen to UI technology since..well..i wanted to say "winforms" but that really sucked - so since the dawn of history!</p> <p>Let me break down your requirements from this new and improved framework:</p> <ol> <li><strong>Strongly typed bindings</strong> - While i agree it might be useful in SOME settings to specific the binding in a strongly typed way, i frequently find myself using the fact that binding is completely loose to be very useful. the runtime discovery of properties is an incredibly powerful property of Xaml and the binding mechanism. In my experience you learn pretty quickly to find and fix binding issues, and the runtime errors are very detailed. It may not be ideal - but it's pretty good.</li> <li><strong>Faster binding</strong> - <a href="http://msdn.microsoft.com/en-us/library/bb613546.aspx" rel="nofollow noreferrer">performance</a>, is fairly fast for most situations. You can always provide an ICustomTypeDescriptor to improve performance in extreme cases. As for that Bindable property with a callback - how about some kind of <a href="http://msdn.microsoft.com/en-us/library/system.windows.dependencyproperty.aspx" rel="nofollow noreferrer">Dependency Property</a>? (i do concede that the syntax is somewhat lacking). However, for most uses i found the INotifyPropertyChanged interface to be sufficient. The binding mechanism only cares about the fact that there was a change, and it works very well in it's current form. Why do you care how the framework solves this problem - as long as it works well? </li> <li><strong>Resource Dictionaries</strong> - This is another implementation issue that mostly influences the framework and it's internal working. Why do you care how they are implemented? They work pretty well. </li> </ol> <p>I suspect you might be overusing codebehind to solve problems that can and should be solved in Xaml. Which exposes you to the framework's way of solving these different issues, and which I have almost never had to deal with in WPF. The clear seperation provided by Xaml between "things that are the GUI" and "Things that are your code" makes it harder for you to interfere with the UI by using the Code. But WPF provides MANY different mechanism to solve these solutions in an elegant way by using Xaml.</p> <p>If you don't like coding it (personally i don't like messing with UI - it never ends) - Hire a Xaml Expert. They usually have better taste in UI then developers anyway. And if you can't - Learn it! it's a great tool if you take the time to understand it. No framework will solve the problem of groking it's use.</p>
    singulars
    1. This table or related slice is empty.
    1. POWPF without XAML
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USNightDweller
    1. USNightDweller
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POWPF without XAML
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COSome good thoughts there. Thanks for the link on performance - I honestly didn't like the numbers I saw there. Let me specify a little more clearly: I definitely wish to preserve a clear separation of code and UI. Ultimately, I think you'd make a .cs file for the UI and you would build the visual tree there in some LINQ-syntax-esque fashion and NOT have any further code behind, just as you would expect with XAML. I've written custom controls and behaviours to accomplish complex UI tasks without code-behind. Thanks for bringing that up - hopefully I can clear up any misconceptions there.
      singulars
      1. PO
      1. USJ Trana
    2. CO@Trana J - i apologizes for my sarcastic tone, i was going for comic effect :) I understand your point, but i still disagree with your premise. I spent enough time manipulating winforms code, and i've written some gui code in java which gives you more freedom and control to build those structures - and i maintain that the basic form of xaml acheives it's goals very well. The tools are not yet good enough, good auto-complete support, real generics support etc' are very much needed. But this is a new framework that is picking up pace. New features are being added all the time.
      singulars
      1. PO
      1. USNightDweller
    3. COWho knows - strongly typed properties may be just around the corner. I truely think that the way you can separate UI, styling, data binding, logic and transformation was achieved amazingly well compared with other frameworks i've used. I think you'll find that actually putting your concept into conceptual syntax will hit a wall of complexity and incoherence very quickly because regular code was never optimized for UI the way Xaml is.
      singulars
      1. PO
      1. USNightDweller
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload