Hello Everyone,
I have a SL testproject which I use for learning purposes. In the Xaml page for locating an address I'v two CslaDataProviders:
1: AddressListData
2: AddressListCriteria (BusinessBase with 7 criteria properties)
there are also Textbox controls which are bound to properties of dataprovider 2 to enter the individual criteria.
When I click a button, the refresh() of the static resource #1 is invoked (by invokemethod), this works fine, but no parameters (criteriaobject) is transfered to the factorymethod (getAddressList(AdressListCriteria)) and thereby not to the dataportal, it is simply not implemented yet...
<csla:CslaDataProvider x:Key="AddressListData" <------dataprovider #1
ObjectType="TmnOsis.Eos.Business.AddressList, Business"
FactoryMethod="GetAddressList"
IsInitialLoadEnabled="False"
DataChangedHandler="{StaticResource DataErrorDialog}">
<csla:CslaDataProvider.FactoryParameters>
<s:Object>???????????</s:Object> <------ How should I implement the object in dataprovider #2
</csla:CslaDataProvider.FactoryParameters>
</csla:CslaDataProvider>
Questions:
1:
How do I implement the Factoryparameter in the #1 dataprovider to use #2 as parameter?
2:
Is this the proper way to do this or is there a better strategy. I even thougt of implementing the criteria properties in the AddressList class so the whole thing is build in just one class instead of two. I had to redefine the AddressLictCriteria from "CriteriaBase" (which worked fine in my unittest) to "BusinessBase" because of the csla serialization strategy (crossing tiers) in Csla for SilverLight. The AddresList itself has no additional properties so why not combine it in the AddressList ? I Guess this combining is a bad idea because of the OOP philosofy , or are there other reasons not to combine this functionality ?
Thank you!
Peer
This is a hard problem that has no easy answer. I think this is one reason everyone is abandoning the data provider model in favor of the MVVM pattern. Not that MVVM necessarily makes the answer trivial - but it is far easier than trying to get it to work with a data provider.
Basically you need to figure out how you are going to navigate to the next form. Then decide how you create that form. Then decide how you want to pass your parameters to that form (through a constructor, an Initialize() method or something). Then in the code-behind for the second form, take the parameters and use them to load the FactoryParameters collection of the data provider.
It is not ideal, but it can be done.
Thank you for your reply :) , though I do not understand the full meaning of your answer. Actualy I'm a bit astonished why it is so hard to accomplish surch a simple (functional) concept.
The first remark is very important for me, because I'm in a POC process and this sets me on the right (MVVM) track BUT not knowing why and where I'm going to. I will read a few MVVM consideration articles today. By the way: How should I interpred this 6 months old thread (http://forums.lhotka.net/forums/p/7187/34360.aspx#34360) about MVVM. What has changed the importance of this pattern?
About the problem:
After searching the forum again I found an unaswered thread about excacly the same issue:
http://forums.lhotka.net/forums/p/7769/37044.aspx#37044
I do not want to navigate to a next page, I simply want to refresh the current form by refreshing (requery) dataprovider 1 using the properties in dataprovider 2 as searchcriteria. (dataprovider 2 is an BuisinessBase object containing 7 optional properties to find an address). I Instantiated this object in dataprovider 2 and bound the properties to textboxes.
What I'm intending to do for now is remove dataprovider 2, extend the GetaddressList() factory Method(dataprovider 1) with 7 parameters, and declare these parameters in the dataprovider1 as Factoryparameters. In the factorymethod I will create a new AddressListCriteria object and fill the properties with the parametervalues.
Do you think my thoughs are in line with the Csla concept?
Thank you :)
Peer
In WPF you can use "reverse binding" to bind something like a TextBox.Text property to a factory parameter property. This concept doesn't exist in SL. I think it doesn't exist in SL because the data provider concept doesn't really exist in SL - we created it in CSLA because I thought the data provider was the way Microsoft was going.
The SL data provider was specifically designed to look like the WPF data provider - because Microsoft defined what a data provider would look like and how it would work in WPF. The factory parameters are simply passed as parameters to the factory method. This is like the WPF ObjectDataProvider that passes the parameters to the constructor.
However, and this is important, Microsoft is not going with the data provider concept. The Visual Studio 2010 XAML designer doesn't use or support the data provider concept.
I never thought the WPF answer was very good, but of course the lack of any answer in SL is worse. The only real-world answer in WPF or Silverlight though, is to use code-behind to set the factory parameter list.
I am considering removing the data provider types in CSLA 4. This will break people using the data provider - but these types are increasingly useless and misleading, given that Microsoft isn't using this concept and so it will slowly become more and more trouble over time.
Rocky, thanks for the streight and complete answer, It's appreciated and sets me on the right track. Maybe it is an Idea to inform the community (more specific: people who are learnig with the Video's) about this possible step. I have to focus on another technique. You gave me a hint ( MVVM) in an earlier reply so I'll go on whith that. Two steps ahead, 1 step back ! ... Is the MVVMExperimentSL solution a good example using this pattern ? I read the thread about the videos so Maybe I should be patient and concentrate for now on Csla core techniques...
If you step back and have an overview of the whole SL development it is pretty obvious it is far from mature. Techniques will be exchanged in the next years and we will be running and cleaning up the mess. (It probably keeps us in good shape ;) )
Peer
Magenic has some customers (2 specifically that I've seen) who are very far along with large Silverlight apps. Very cool, very large apps - fun to see!
And there are quite a lot of organizations with WPF apps - and they have the exact same challenges in terms of data provider vs MVVM vs other options.
I guess the point is that the lack of "best practices" understanding applies to both SL and WPF, and exists because relatively few people have been using either technology until recently. It wasn't until 2009 that serious interest in these technologies started to occur, and I think in 2010 there'll be a veritable explosion of interest.
Copyright (c) Marimer LLC