Group items tagged

Excellent explanation and review from the Tim Anderson. I wonder how i missed this? Here is the summary statement: "..... You can also extend XAML with custom objects. The main requirement is that classes used in XAML must have a parameterless constructor. The procedure is straightforward. Define a class; make sure your application has a reference to the assembly containing the class; then add a namespace declaration for the assembly. You can then define elements in XAML that map to your class, and at runtime these will become object instances. XAML has a curious story when it comes to formatted text, especially in Silverlight. In one sense it is rather limited. XAML has no understanding of common formats such as HTML, CSS or RTF, let alone the fancy new OOXML. Silverlight developers have to interact with the browser DOM in order to display HTML." "... No escaping it: Silverlight .XAP bundle preserves the original XAML. That said, XAML with WPF actually is a document format. The full WPF has an element called FlowDocument and rich formatting capabilities. Silverlight lacks FlowDocument, but does have a TextBlock with basic formatting options via the inline object. It also supports the Glyph element. This is interesting because it is the core element in XPS, Microsoft's invented-here alternative to Adobe's PDF." ".... XPS uses a subset of XAML to describe fixed layouts. In consequence, and with some compromises, you can use Silverlight to display XPS." "..... The bottom line is that XAML is a way of programming .NET declaratively. Its more intricate features improve the mapping between XAML and .NET. The result is we have design tools like Microsoft's Expression Blend and a clean separation between UI objects and program code, which is a considerable achievement." ".... As ever there's a downside, and with Microsoft it's the classic: this is thoroughly proprietary, and the schema issues make it difficult to validate with standard XML tools." No

The Future of the Open Web You're right that the browser wars do not matter - except for this point of demarcation; browsers that support HTML+ and browser that support 1998 HTML. extensive comment by ~ge~ Not all Web services and applications support HTML+, the rapidly advancing set of technologies that includes HTML5, CSS3, SVG/Canvas, and JavaScript (including the libraries and JSON). Microsoft has chosen to draw the Open Web line at what amounts to 1998-2001 level of HTML/CSS. Above that line, they provision a rich-client / rich-server Web model bound to the .NET-WPF platform where C#, Silverlight, and XAML are very prominent. Noticeably, Open Web standards are for the most part replaced at this richer MSWeb level by proprietary technologies. Through limited support for HTML/CSS, IE8 itself acts to dumb down the Open Web. The effect of this is that business systems and day-to-day workflow processes bound to the ubiquitous and very "rich" MSOffice Productivity Environment have little choice when it comes to transitioning to the Web but to stay on the Microsoft 2010 treadmill. Sure, at some point legacy business processes and systems will be rewritten to the Web. The question is, will it be the Open Web or the MS-Web? The Open Web standards are the dividing line between owning your information and content, or, having that content bound to a Web platform comprised of proprietary Microsoft services, systems and applications. Web designers and developers are still caught up in the browser wars. They worry incessantly as to how to dumb down Web content and services to meet the limited functionality of IE. This sucks. So everyone continues to watch "the browser wars" stats. What they are really watching for though is that magic moment where "combined" HTML+ browser uptake in marketshare signals that they can start to implement highly graphical and collaboratively interactive HTML+ specific content. Meanwhile, the greater Web is a

Roger Black is a publication designer, and Filipe Fortes was the project manager for Microsoft's Windows Presentation Foundation - Silverlight project.  Today he specializes in dynamic layout algorithms written in Open Web JavaScript.  Roger is a reknown publication designer, and describes here the genesis behind TreeSaver.  Fascinating story certain to become a key explanation of how digital media ran away with the print publishing industry.   I'm wondering what kind of authoring tools will evolve that can publish directly into the TS JavaScript templates?   My first inclination would be to adapt OOo Impress.  It has an outline view, a notes editing capability, and provides a decent visual canvas.  The problem is that it's locked into "slides".  Can Impress be unlocked and flowing?  That might work. excerpt:  when Microsoft put together a dynamic page layout for The New York Times Reader, did they know that it was the future? It certainly wasn't the immediate present, since they couldn't pry the WPF visual layer off of Windows, leaving it a single-OS solution. (The Times' Reader later was taken up by Adobe, which at least got it to work on both Mac and PC.) Filipe Fortes, PM on the MS news client project, knew. I'd met him when the group invited me out to Redmond to help design the first templates for the Times. Later I saw him at the 2007 Mix conference in Vegas, and I asked him how to make the dynamic page size idea work multi-platform. He said, "We could do it in HTML."

excerpt: The trend in Office development is the migration of solutions away from in-application scripted processing toward more data-centric development. Of course this is a primary purpose of Open XML, and it is great to see the amount of activity in this area. We've seen customers scripting Word in a server environment to batch process / print documents or for other automation tasks. In reality Word isn't built to do that on a large scale, it is better to work directly against the document rather than via the application whenever possible. The Open XML SDK unlocks a "whole nuther" environment for document processing, and gets you out of the business of scripting client apps on servers to do the work of a true server application (not to mention the licensing problems created by installing Office on a server). comment:  Gray makes a very important point here.  The dominance of the desktop based MSOffice Productivity Environment was largely based the embedded logic driving "in-process" documents that was application and platform (Win32 API) specific.  Tear open any of these workgroup-workflow oriented compound documents and you find application specific scripts, macros, OLE, data bindings, security settings and other application specific settings.  These internal components are certain to break whenever these highly interactive and "live" compound documents are converted to another format, or application use.  This is how MSOffice documents and the business processes they represent become "bound" to the MSOffice Productivity Environment. What Gray is pointing to here is that Microsoft is moving the legacy Productivity Environment to an MSWeb based center where OpenXML, Silverlight, CAML, XAML and a number of other .NET-WPF technologies become the workgroup drivers.  The key applications for the MS WebStack are Exchange/SharePoint/SQL Server.  To make this move, documents had to be separated from the legacy desktop Productivity Environment settings. Note th

I posted two lengthy comments here.  Can't see the forest for all the trees is the idiom that comes to mind. excerpt: With Silverlight, Microsoft continues to make it clear that they intend to use this web application framework, which they developed, to power much of what they are doing on the web going forward. Again, the problem here is that not only does Microsoft control this, but it requires a plug-in to use. Sure, they've made the plug-in available to most browsers, including the ones by rivals Google and Apple, but it's still a plug-in. It's something that's going to stop everyone from seeing the same web no matter which browser they use. This has of course long been an issue with Microsoft. Despite a clear shift within the rest of the industry toward web standards, Microsoft long played difficult with its Internet Explorer browser. They could afford to, and maybe you could even argue that it was in their interest to, because they were so dominant. It was only when a standards-based browser, Mozilla's Firefox, started biting off significant chunks of IE's market share that Microsoft shifted their position to play more nicely with standards.