Hello, Marc Clifton reports in the MyXaml et al blog story titled "Documentation is coming online" that a first draft of the official MyXaml Tutorial is now online
In the intro Marc writes: What Is MyXaml? MyXaml is a form of Declarative Programming. This is different from Imperative Programming. With declarative programming, the program is responsible solely for instantiating an object graph, and setting initial values for those objects. Imperative programming consists of the command and control of those objects. Why Use MyXaml? Separating the application code into declarative from imperative pieces has benefits (although this is greatly debated). Obviously, I feel that there are significant benefits, otherwise I wouldn't be spending all this time in implementing and supporting MyXaml. One of the primary differences is declarative programming lets you glue things together in different ways, relying on the common underlying imperative code for the various functions. Take the Visual Studio designer process. You create a form, put some buttons on the form, double click on those buttons to generate the event handler, and you write the event handler. You've now entangled the user interface (the declarative part) with the event handler (the imperative part). What's worse, the event handler is tied to the instance of the class, in this case, the worst possible kind of class--a user interface Form! Let's say this event handler provides some useful functionality that maybe other aspects of the application would like to reuse as well. Now you're stuck--you can't access the event handler without having an instance of the class, which means you would need to instantiate the form, which is absurd. Using declarative programming is a better way of programming. Certainly, the above description illustrates bad programming practice and the separation of the user interface from the business logic is a common enough best-practice technique in imperative programming. However, declarative programming takes the n-tier best-practice approach to a really useful level. This is accomplished by (coming full circle) separating out the declarative aspects of programming from the imperative aspects. Declarative programming is not necessarily handled best by an Imperative Language (although some would argue the xml isn't the best solution either), however by separating the two concerns, they can vary independently of each other. Simply put, this separation of concerns results in better written applications--they are more robust and easier to maintain and upgrade. More @ http://www.myxaml.com/wiki/ow.asp?MyXamlTutorial - Gerald ------------------- Gerald Bauer XUL Alliance | http://xul.sourceforge.net United XAML | http://xaml.sourceforge.net ______________________________________________________________________ Post your free ad now! http://personals.yahoo.ca ------------------------------------------------------- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com _______________________________________________ xul-announce mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xul-announce
