@12yr old developer: Nice work, keep learning a tiny bit every day ... before you know it, I'll be coming to YOU for a job.
Is this what you want?
@NerdyWoman: Yep, I loved WordPerfect's tag system back in 1989-1992-ish (painful to say that) and it did help the mental transition into HTML.
... I'll be nit picky for a moment in order to reinforce this important concept: XAML doesn't inherently have anything to do with with defining elements on the page. However, when used with an API for building user interfaces like WPF, it can be used to create instances of classes defined in the given API and set their initial properties. Again, just want to make sure we've got that nuanced idea cemented.
Correct, XAML can only create instances of classes and set initial properties. If you need more logic to control the given user interface API or respond to events that are triggered by the user or the system (page load, button click, timer, etc.) then you will use imperative C# or VB code in the "code behind" that is associated with the declarative XAML code file. How are the two associated? The "main page" file that you see in the visual designer and the "code behind" file are two parts of a whole ... they are both partial classes and will be turned into Intermediate Language (IL) by the compiler ... the two files of code combine together to define a new class that derives from the Page class.
Good question! API == Application Programming Interface. It's a fancy term used for years and not specific to .NET. Simply put ... an API is a collection of classes with properties, methods and events that someone (in this case, at Microsoft) creates with the intent that it will be used by other developers. You could also call an API a Library, like the .NET Framework Class Library, an important component to every .NET application. Just a library of functionality you can borrow from.
APIs hide complexity thereby making it useful to other developers. All of the down-n-dirty implementation details are hidden behind a public "interface" ... in this case the term "interface" consists of some classes, some properties, some methods, etc. that are made public (so that other developers reference and use them in their code). Meanwhile deep down inside the code of the API some classes, properties and methods are made private (because they do important stuff that the original developers don't want anyone fiddling with). This is the notion of Encapsulation in Object Oriented Programming.
API's usually encapsulate important work that is common to everyone, not just to your specific "problem domain" (business need). However, suppose you work at an accounting firm and want to create an API that handles tax calculations for all states. That would be a good re-usable component that could be documented and utilized by other developers in your organization. That's a great example of an API ... albeit, one that you probably don't want to share with the world because it is specific to just the developers in your organization. Still, it's "standardized", documented and hopefully other developers can learn how to utilize it within their apps.
In .NET, there are APIs for everything ... data access (ex. ADO.NET API), web development (ex. ASP.NET Web Forms API), web services (ex. Windows Communication Foundation, the WCF API) ... IN FACT there are MULTIPLE API's created by Microsoft to do the same basic job ... as you can see, the Windows Presentation Foundation (WPF) API is one way to create a Windows application ... there's also the Windows Forms API, Windows Store API / WinRT API, Windows Phone API, etc. Competing APIs are created to give developers options on how to approach a problem, which technologies can be used. They are split up into their own APIs to reduce complexity and application size.
Some APIs have "sub API's" ... for example, the ADO.NET API has a popular sub-API called the Entity Framework API. Inside of *that* API, there's other sub-API's ... LINQ to Entities, the DbContext API, the Change Tracking API, the Validation API ... again, these are conceptually different aspects of a larger set of functionality. They may even be deployed in the same physical .DLL file (more about that later) but can be referenced conceptually as a distinct set of classes, methods and properties used to accomplish some sub-feature of a larger feature set. Simply put, a sub-API is just a way to talk about a sliver of the overall functionality ... it's just a label that describes a conceptual boundary around some classes so you can isolate and talk about those since they were intended to work together.
API's rarely have user interfaces themselves. They are just literally libraries of code that can be leveraged by other developers. They may be used to CREATE user interfaces, but you couldn't just run an API on it's own ... there would be nothing to see. It needs YOUR CODE to drive it to do something meaningful like "print a form to screen" or "print a button to screen" or "respond to a click event" or whatever.
In the .NET world, API's are usually packaged into one or more assemblies. An API is the more conceptual way to refer to a a .dll Assembly file. You add a reference to a .dll / Assembly in your Visual Studio Project as a means of accessing the API. All .NET applications reference the core .NET Framework Class Library, and some Project templates add references to other .dll Assemblies depending on the type of application you're creating. This is a shortcut made simply by choosing
API's also are versioned and there are important rules around how to properly version them so you don't remove or change functionality in one version of the API that developers depend on in their applications. The words "breaking changes" are considered an anathema.
I think I've literally told you everything I know about the term "API" ... except to answer the last bit of your question:
Does WPF (as an API) enable some procedures/events to be written on the main page vs. a code behind page?
Well, no ... not exactly. I mean, XAML is really just used to create instances of classes in a given API and then initialize the properties of that new instance. It can WIRE UP an action to an EVENT HANDLER in the code behind, sort of like:
<x:Button ... onclick="myButton_Click" />
... it can't actually handle the event when it happens. It must defer to the imperative C# or VB code in the code behind file since it can be used to write logic to define what happens next. So, it's not a limitation or restriction of the given API per se, it's more a matter of what each language is equipped to do. Like the video I referenced, you COULD create an entire WPF app exclusively in VB or C#, HOWEVER it would become laborious. You don't NEED XAML. XAML is merely a short-hand, a short-cut both mentally for those of us who think of layout in terms of tags, and in terms of the actual number of characters you need to type to achieve similar results (i.e., creating a new instance of a Page class, adding to that class an instance of the Grid class and setting all its properties, then adding as children to the Grid class instance new instances of buttons, stack panels, etc.) That would take FOREVER and you wouldn't be able to see the results in a friendly designer at Design Time. You would have to F5 Start Debugging the application to see each little change you wanted to make. So, XAML, as used for layout against the WPF API or what have you, is merely a convenience. Not a requirement.
Hope that helps?
@Samet: Nice catch. I don't know I would have caught it without trial and error (removing attributes, etc.)
@WinAppy: YES YOU CAN! Use this as a starting point (or google it using Bing.com):
"C++ phone 8"
... helped me find this ...
@NerdyWoman: Hi! So, the challenge with being new to a topic is (a ) all the terminology and (b ) the nuanced differences between the terms. Think of XAML as a language, much like C# or Visual Basic ... just a language, by itself, has rules, semantics, etc. In fact, while XAML is most often used to define user interfaces, that's not its only usage. Just happens to be the most popular.
WPF, WinRT, etc. are Application Programming Interfaces (API) that provide features (implemented as classes with methods and properties developed by Microsoft) to draw stuff on a screen, animate things, etc. As I point out in my Absolute Beginners series on Windows Store Apps (albeit, for C#, but this will apply no matter what), you can use XAML or C# or Visual Basic to create instances of those objects in the WPF API or WinRT API or whatever (Phone, Silverlight, etc.) XAML's declarative nature (looks like HTML) provides a shorthand syntax ... you can express more with fewer keystrokes than using C# or VB to do the same sorts of things. However, XAML doesn't have logic features (i.e., no if / else statements) ... but it's really good at creating instances of classes and initializing their property values.
Again, I realize this is nuanced difference between XAML and WPF (or name your API) but it's an important distinction.
Now, the beauty of XAML is that if you learn how to use it to create WPF apps (learning how to create instances of WPF classes, set attributes, etc.), you'll almost instantly know how to use it to do the exact same sorts of things in WinRT, Phone, Silverlight, etc. with some small variations. The smart people at Microsoft realize that in order to keep the learning curve low and increase adoption, they can re-use languages and names of things you're already familiar with in one API when they introduce a new one. All of the down-and-dirty details that make each API do different stuff under the hood is abstracted away for you and I, the consumers of the languages and APIs. The benefit to us is that we learn it once, we can apply 95% of our knowledge to the next idea / technology / gadget / API / whathaveyou. I suspect someday in 20 years when we can create apps to control drones or robots to vacuum our floors, we'll still be using C# and XAML to build those apps. (That's speculation, obviously. I have no idea whether Microsoft is working on robots right now. I hope they are!!!)
Hope that helps a little?
Watch the XAML video in the recent Phone series I just created ... I elaborate on these ideas:
Good luck! Stay nerdy!
@Donald Brown: Thanks for the very nice words and for being a supporter! Tell you what ... that's actually a binary clock, and I'll send it to you for free. Some people seem to hate it because they focus on the lights. SO rather than answer more questions about it, I'm purging it from my "recording studio" ... my loss is your gain. Send me your shipping address ... bob at you know the rest.
@Emad67: Hi! I don't talk about iFrame in HTML5 ... it's a bit more involved. Here's a great article about the issues involved in using iFrame:
Regarding the div element ... I do have things to say about it, but I don't know that you'll like them. The div has been misused as some have referred to "divitis" ... a disease in web programming that adds divs for styling and css hooks. This is NOT the correct semantic use of the element. The major theme running through this series ... HTML5 should not be used for layout. That is CSS3's job. So, you referenced "screen realestate" and "positioning", etc. That's more of a CSS3 thing and I do talk about it in THAT context. Hope that helps!