Hi,

your point (designing the form solely defines the exact positioning of components) forgets that metadata, for data actions and ui actions, follows the datasource. Lookups, validation, field triggers, allow blank rules, enabled status, visible status, etc. all follow the datasource. So, being able to design once and run anywhere is in fact a big deal. In this scenario, where would you put an Entity Framwork, or an MVC or MVVM pattern, and why?

XAML can reference custom controls: witness Silverlight 3 and 4. How it does it makes no more difference to me than how VFP forms are stored inside an SCX (which is to say, if I have a need I would go look it up). XAML is just (today's) information storage mechanism; what I can do with it is what counts.

Hank

>Hi,
>Several things I'd take issue with there. But, firstly, please don't take this personally - my natural instinct is to argue against any POV ( If no-one else is available I'll argue with myself) and I'm willing to be converted/convinced
>
>OK. I'll pick one :
>
>Why on earth would you design a form in VFP in order to convert it to XAML. There may be an argument for converting an existing VFP form - but that is not what you said. Since the information in a VFP form solely defines the exact positioning of its components then the XAML could only represent this as a convoluted nested Grid structure. I just don't see the point.
>
>Reserving the option to come back on some other issues,
>Viv
>
>
>>Hi,
>>
>>I'm actually arguing for the separation of both data metadata and ui metadata, on the one hand; and the separation of ui design and ui implementation on the other hand. When that's done, these extra layers become irrelevant.
>>
>>I've been using data metadata and ui metadata for some time. Like all good data <s>, it is stored in dbf's.
>>
>>The second part, separating UI design and implementation, is what has been missing. Imagine that you could design a VFP form, and have it expressed as SVG, or as XAML which would then be expressed as WPF or Silverlight 4? What that does is eliminate the layer needed to match up to various UI implementations. The metadata (for data actions and ui actions) would follow the datasources. The only thing needed would the the choice of transport mechanism for the data; but that's simple too, at least in VFP.
>>
>>What I see happening in the .Net world is an assumption that objects are statically typed, and everything after that is an attempt to make up for that strategic disadvantage. Remove that assumption, pare it down to the basics of what is required, and things become simpler while retaining flexibility.
>>
>>BTW: etecnologia's "VFP.Net" (my name, not theirs) will have the ability to design a VFP form (in their customized SharpDevelop environment) and output it as SVG or XAML.
>>
>>cheers,
>>
>>Hank
>>
>>>Hi,
>>>>Historically, as we all know, it as ado.net, entity framework, and mvc.
>>>That chronology sounds wrong. MVC has been around since,at least, the early '80s
>>>
>>>>EF attempts to solve the impedance mismatch between the data and the statically typed language.
>>>Surely EF's just a ORM option - ie addressing the mismatch between object based programs and a relational data model?
>>>But where does 'statically typed language' come into this?.
>>>
>>>>MVC attempts to solve the impedance mismatch there also, when not used with EF, in addition to providing a layer for solving the impedance mismatch to the UI. In that sense, then, MVC is (partly) yet another ORM, as I see it.
>>>
>>>I agree that the MVC pattern would need logic to create the model if something like EF isn't used. But, again, especially with the MVVM variation, isn't the primary purpose to achieve separation of the UI implementation? I don't see it as being to do with a mismatch as such. Re-reading youur previous post it sounds as if you are arguing for a more tightly bound relationship between the model and the UI......
>>>
>>>Best,
>>>Viv
>>>
>>>
>>>
>>>>
>>>>Hank
>>>>
>>>>>Hi,
>>>>>
>>>>>I understand the MVC / MVVM stuff (and EF). It was just the "MVC (and the Entity Framework before it)" phrase that didn't make sense to me......
>>>>>
>>>>>>It's probably easiest to see if you look at MVC applied to WPF, where it becomes MVVM. http://www.orbifold.net/default/?p=550 As Brad Abrams points out, http://blogs.msdn.com/brada/archive/2008/01/29/asp-net-mvc-example-application-over-northwind-with-the-entity-framework.aspx, the Model can be from the Entity Framework (or any other ORM-type). MVC as I see it is a workaround for the fact that there is no metadata repository for data or UI, and so classes that store and test the action of the metadata need to be created.
>>>>>>
>>>>>>Hank
>>>>>>
>>>>>>>Can you clarify what you perceive as the connection between the MVC pattern and the EntityFramework?
>>>>>>>Ta,
>>>>>>>Viv
>>>>>>>
>>>>>>>>Hi Matt,
>>>>>>>>
>>>>>>>>As I see it, MVC (and the Entity Framework before it), are elegant ORM answers to the problem of working in a system where there is a mismatch between what the controls expect as a datasource, and what the native providers of data in the system can provide; and in which metadata is not assumed (because it isn't) to be available.
>>>>>>>>
>>>>>>>>In VFP, of course, there is no mismatch between datasources and controls: you just wire them up. No need do describe the type of a field: it's all done for you. The same is true in the eTecnologia effort for (my name) VFP.Net.
>>>>>>>>
>>>>>>>>The other part, the Data metadata and the UI metadata, is something we have been using for 7 years as our extensions to the framework we use in VFP. I couldn't imagine software development without it (e.g., dynamically setting when a control should be visible, or be enabled, etc., in metadata rather than in code; setting field triggers in metadata rather than in code; etc).
>>>>>>>>
>>>>>>>>We'll have the same metadata available in VFP.Net, but reworked based on our experience, and also on new features available in VFP.Net.
>>>>>>>>
>>>>>>>>These ORM solutions shove all of the above into one place. Since most of it is itself data (i.e., metadata), that place should be a table, not a bunch of code. Of course, I look at things as a data guy, but isn't that what we are?
>>>>>>>>
>>>>>>>>Hank
>>>>>>>>
>>>>>>>>>Model < --- > ViewModel < -- > View
>>>>>>>>>
>>>>>>>>>It's great theory, but come on!
>>>>>>>>>
>>>>>>>>>Just say No Way!!
>>>>>>>>>
>>>>>>>>>http://therealmattslay.blogspot.com/2009/11/model-view-model-view-no-way-for-now.html
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>.