If I understand  correctly it's talking about essentially an easy way to
deploy xaml-based applciations that still run in the WPF context on the
client (and therefore require it on the client), which is something quite
different than an HTML-based web application. Is that correct?
It looks like I need to go a custom direction for what I want to accomplish,
but xaml could still be the basis for it.
I want to have one form layout definition that could be used in both windows
form and asp.net contexts. Most of the code-behind would be in base form
classes or otherwise implemented in a controller of some sort. So at the end
of the day the definition should really be just controls, their binding to
the underlying business objects, and grouping into layout controls. My goal
is to have both applications have a similar look and feel as far as form
functionality, navigating around the application, etc., but via the
controller each could also exploit advantages peculiar to the environment.
One other aspect of this has come out from watching and reading some of the
material. I know that part of WPF and XAML is the ability to declaratively
design a form, but I find it downright weird to be hand-typing form layouts
in 2006. Does VS2005 (with the right SDKs or whatever would be required)
have the ability to design a form in the designer and then output that as a
xaml definition? This would seem to get me a long way down the road I want
to go. I realize I may need to write an "interpreter" for the asp.net side
if it couldn't use the same definition.
I've spent a few days with Workflow Foundation, and see that there is kind
of two things talked about - the workflow classes on the one hand, and the
declarative ability to interact with the host "engine" on the other. So, WF
is not defined by declarative flow design, but is the technology that enables
it. I'm presuming now the same applies to WPF - it's not defined by xaml per
se, but is the technology that will enable xaml programming in Windows. Does
that sound right?
"Drew Marsh" wrote:
> Daniel Billingsley wrote:
> > In all the info from MS, I can't seem to find a solid answer to this
> > question. I want to develop an application such that I can
> > essentially define a UI once and have it available as both a windows
> > forms application and ASP.NET application. I found one blurb
> > somewhere that WPF applied to both windows forms and web forms, but
> > that was about it.
> > So, is it the case that I could define a UI form using XAML and have
> > WPF use that in the context of both windows forms application and
> > ASP.NET?
> The answer is: depends on what features you're using.
> There's two forms of WPF for the web: loose XAML and XBAP applications.
> Loose XAML would pretty much be used to create pretty pictures and animations.
> There's no code behind and you're limited to a sandboxed set of components
> you can work with. Then there's XBAP applications. These, like loose XAML,
> will run in a sandbox, but can also have compiled code-behind. The code-behind
> can do anything with .NET that is possible in the Interet Zone. Note that
> you can also request higher levels of trust for an XBAP application.
> All said, you should easily be able share resources between these types of
> application and the straight up windows application. Code, on the other hand,
> will need to be zone aware.
>  http://windowssdk.msdn.microsoft.com...c6bb8900df.asp
>  http://windowssdk.msdn.microsoft.com...0b1d032483.asp
>  http://blogs.gotdotnet.com/karstenj/...29/498061.aspx
> Drew Marsh
> Chief Software Architect
> Mimeo.com, Inc. - http://www.mimeo.com
> Microsoft C# / WPF MVP
> Weblog - http://blog.hackedbrain.com/