Hi Yiannis,

These autofit panels are mainly used in ToolBar and ToolGroup to provide overflow and auto-fit layout feature. To understand how it works, try to create a UXToolBar with two or three UXToolGroup inside it, then add several UXToolBarButton to each of the UXToolGroup.

Run your sample in the browser. Then, try to resize your browser to a smaller width. You'll notice that the ToolBar will automatically maintain its size by moving the exceeding items (called overflow items) to the overflow menu which is accessible from the small indicator in the most right edge.

One of the unique features in our ToolBar is that you can have several groups in a toolbar and determine which groups to participate with the overflow calculation. We'll have various samples in the RTM that brings together all these features to allow you easily build commercial-class UIs, such as Windows 7 toolbar, iTunes toolbar, iPad toolbar, and so on.

Although these autofit panels are currently used in ToolBar and ToolGroup, there maybe similar scenarios that can effectively utilize these panels. Let me know if there's something you want to achieve with these panels. Thank you.

Hope this helps,
Jimmy.

Hue,

Try binding to SelectedItem instead. That should work.

For MVVM pattern sample, you can see the Contacts sample (in Visual Studio 2010 solution) that we shipped in the RC. Open the Edit Contact form, you can find some examples of input controls that bound to the view model.

Hope this helps,
Jimmy.

Our engineers are pushing complete MVVM + framework integration for the presenter lineups in R2 milestone.

In this release, you can still bind the presenters to MVVM using an alternative solution such as using row template, however, that won't be optimal in the MVVM usage. Let me know if you're interested to learn about this alternative approach.

Regards,
Jimmy.

Thank you for evaluating ClientUI RC.

I'll try to answer some of your questions:

1. Our UI components are not designed to coupled with any proprietary model or data service context. The use of WebContext (WCF RIA Services) for authentication is just a sample that we took based on many requests from Silverlight developers and community.
    
   
2. The key behind the authentication is the User property (IPrincipal) which is available in three levels of our component architecture. First, in the UXPage, secondly, in the UXFrame, and the third is in the UXShell level. This provides the most flexible configurations to achieve several business scenarios.
   
   In the business sample that we shipped, the User property is bound at the UXFrame level to achieve single-sign-on (SSO) scenario. So when the User is authenticated at the UXFrame level, the pages with RequiresAuthentication will be properly validated and displayed without requiring extra authentication (this actually also greatly simplifies the development effort).
   
   The UXShell is the central of the application model and fundamental architecture that we introduced in ClientUI, which includes asynchronous application initialization, asynchronous authentication, external XAP navigation, and many more. In the sample, you can notice that the key authentication is managed at the UXShell level, which is then bound to many other places such as UXFrame.
   
   So, to answer your questions, the page becomes aware of user authentication via the following codes.
   
   App.xaml.cs:
   

   // Bind WebContext's User to the Shell, so we can enable single sign-on login feature
   // and many other integrated features to easily query the authenticated user.
   
    shell.CreateBinding(UXShell.UserProperty, "User", webContext);

   In this process, the User property of UXShell is bound two-way to the WebContext.User.
   
   Login.xaml.cs:
   

    // Perform asynchronous server-side call to perform authentication
    
      WebContext.Current.Authentication.Login(
                       new LoginParameters(this.UserName, this.Password, this.RememberMe, null),
                       this.Login_Completed, null);

   When a user is successfully authenticated, the User property of the WebContext is populated and notified to the UXShell. Consequently, the UXShell notifies the rest subscribers such as UXFrame and others that a User is now authenticated.
   
   MainPage.xaml:
   

   <Intersoft:UXFrame x:Name="ContentFrame" Intersoft:DockPanel.Dock="Top" Intersoft:DockPanel.IsFillElement="True" 
                                  ...
                                  UseGlobalShell="True" 
                                  RedirectUri="/Login" User="{Binding User, Source={StaticResource Shell}}" 
                                  IsAuthenticating="{Binding IsAuthenticating, Source={StaticResource Shell}}" 

   Notice that we bound the User property to the UXShell. This is made as simple just for a sample, but actually quite sufficient for common business applications that used single authentication.
   
   So, if you have more complex apps that used multiple authentication, you can bind the User to another authentication provider. The same goes true for the UXPage level.
   
   Customers.xaml:
   
   

   <Intersoft:UXPage 
   	xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
   	xmlns:Intersoft="http://intersoft.clientui.com/schemas"
   	x:Class="Intersoft.Silverlight.CSharp.BusinessApps.Customers" 
   	Title="Customers Page"
           RequiresAuthentication="True">

   UXPage can be thought as the consumer of all this authentication architecture. The RequiresAuthentication and RequiresRole are two key properties that determine how it should work along with the authentication.
   

   
   Hopefully this short explanation gives you clear insights of how the authentication process is chained. In fact, we've designed this to be as simple as possible, so that developers only need to set what are needed, and avoid unnecessary bridging and lot of codes.
    
   
3. The LoginStatus and Logout doesn't seem necessary to have view model because they simply bind to a single DisplayName. If you have more complex information or interaction in the LoginStatus, it might make sense to have a view model. The Logout is currently as simple as performing logout (done in OnNavigatedTo method) thus doesn't seem to need view model.
   

Full samples and documentations will be available in RTM release which is expected to ship in few weeks.

At the meantime, please post your questions and feedback in this forum, we'll try our best to provide solutions and answer.

Regards,
Jimmy.

Ben,

Thanks for pointing this out.

ClientUI would be technologically new branding that encapsulates all UI controls designed for both Silverlight and WPF platform, so you can expect to see ClientUI in our samples, documentation, and technology showcase. So, instead of saying Navigation Framework for WebUI Studio for Silverlight and for WPF, the new ClientUI uniquely simplifies our presentation into "ClientUI Navigation Framework".

However, from the Intersoft website presentation and product packaging wise, we decided to keep using the platform-specific naming convention. This provides a clear path for customers to see our solutions per platform, rather than a unified technological brand.

The current website hasn't fully reflected the new 2010 release. In the RTM, we'll add WPF section under WebUI Studio home page. This is something our marketing team are hard at work :)

In short, the Silverlight and WPF lineups (ClientUI) are still under the main "WebUI Studio" umbrella thus enables us to maintain the consistency of our backend system, marketing and presentation such as in our store, subscription mechanism and more.

Hopefully my explanation is clear enough.

Feel free to let me know if you have any feedback or thoughts.

Jimmy.