XML
  Home arrow XML arrow An Introduction to XUL Part 5
Dev Shed Forums  
Administration  
AJAX  
Apache  
BrainDump  
DHTML  
Flash  
Java  
JavaScript  
Multimedia  
MySQL  
Oracle  
Perl  
PHP  
Practices  
Python  
Reviews  
Security  
Smartphone Development  
Style-Sheets  
Web Services  
XML  
Zend  
Zope  
Mobile Linux  
App Generation ROI  
IBM® developerWorks  
Forums Sitemap  
E-Commerce Hosting  
Linux Web Hosting  
Managed Hosting  
Small Business Hosting  
VPS Hosting  
Weekly Newsletter

 
Developer Updates  
Free Website Content 
 RSS  Articles
 RSS  Forums
 RSS  All Feeds
Write For Us Get Paid  
Request Media Kit
Contact Us  
Site Map  
Privacy Policy  
Support  
 USERNAME
 
 PASSWORD
 
 
  >>> SIGN UP!  
  Lost Password? 
Google.com  
XML

An Introduction to XUL Part 5
By: Dan Wellman
  • Search For More Articles!
  • Disclaimer
  • Author Terms
  • Rating: starstarstarstarstar / 9
    2005-06-20


    Table of Contents:
  • An Introduction to XUL Part 5
  • Buttons, JavaScript, and XPCOM
  • The nsIFilePicker interface
  • The keyset element

  • Rate this Article: Poor Best 
      ADD THIS ARTICLE TO:
      error-file:tidyout.log Del.ici.ous error-file:tidyout.log Digg
      error-file:tidyout.log Blink error-file:tidyout.log Simpy
      error-file:tidyout.log Google error-file:tidyout.log Spurl
      error-file:tidyout.log Y! MyWeb error-file:tidyout.log Furl
    Email Me Similar Content When Posted
    Add Developer Shed Article Feed To Your Site
    Email Article To Friend
    Print Version Of Article
    PDF Version Of Article

     
     
    ADVERTISEMENT


    An Introduction to XUL Part 5
    ( Page 1 of 4 )

    Learn about XUL, a subset of XML used to describe user interfaces, that helps you to make rich user interfaces with nothing more complicated than a text editor. In the fifth part of this series you will receive an introduction to XPCOM, the object model used by XUL, and take a close look at a basic example of the combination of Mozilla components and interfaces that make up the abstraction layer.

    All applications need a way or warning users that something is about to happen, or that something has happened. If you’re working in a word-processing application and you try to exit the application without saving your work, you’ll get a message advising that you’ll lose your data if you don’t save it, and are given the opportunity of canceling the action in order to save the file. Computers and software in particular can be frustrating enough as it is from time to time, without this added layer of program safety. Luckily, XUL is able to provide this same safety net, with the inclusion in its syntax of dialog boxes. Of course, you’ll need more than just the code that draws the box on the screen to make dialog boxes a barrier between yourself and application misery, but initially, we’ll look at the code needed to render them.

    The dialog element is used in place of the window element:

    <dialog id="mydialog"
      xmlns="http://www.mozilla.org/keymaster/gatekeeper/
      there.is.only.xul" buttons="accept,cancel">

    <dialogheader title="Warning"/>

    <description>The action you have selected will render your
      computer completely inoperable.  Do you wish to continue?
      </description>

    </dialog>

    As you can see, the XUL namespace still needs to be included. For scripting purposes, the id attribute is also recommended. The dialogheader is used to give the dialog box a separate heading, into which a title and description can be placed. The title is styled automatically to be bold and colored and gives an indication as to the function of the dialog box, whether this be information, a warning, or just a few words of wisdom. 

    Dialogs need to be opened using a chrome URL from within Mozilla, which means that in order for Mozilla to know about them, an RDF file needs to contain references to them. Save the above file in the content directory used for the wizard example and update the existing contents.rdf file with the following bag and description:

    RDF:Bag about="urn:mozilla:package:root">
        <RDF:li RDF:resource="urn:mozilla:package:mydialog2"/>
    </RDF:Bag>

    <RDF:Description about="urn:mozilla:package:mydialog2"
              chrome:displayName="myDialog2"
              chrome:author="Dan"
              chrome:name="mydialog2"
              chrome:extension="false"/>

    As before, this will not be recognized by Mozilla until the existing chrome.rdf file has been deleted and regenerated in the Mozilla chrome directory. Now open the dialog using the normal chrome syntax (chrome://filename/content/). The dialog should open, and will have the header, the message and the specified buttons. 

    Click one of the buttons to test that they will actually do something, and once again, Mozilla quits abruptly. You’ll also notice that instead of being a separate dialog box, Mozilla has opened it as if it were a window. Both of these things are caused by not calling the dialog from another file, which we can fix easily enough by creating a window that calls the dialog.  Create the following file and save it in your chrome folder:


    <?xml version="1.0"?>
    <window
      id="button"
      title="Dialog test"
      xmlns="http://www.mozilla.org/keymaster/gatekeeper/
     
    there.is.only.xul">

    <script>
      function openD() {
        window.open("chrome://mybutton/content/mydialog2.xul",
        "chrome", "dialog");
      }

    </script> 

    <button id="button1" label="Napalm my C: drive!"
      onclick="openD();"/>

    </window>

    For this to work properly, it will need to be added to the RDF file and opened with a chrome URL in the normal way. As you can see, you simply add a click event to the button, which calls the function residing within the script tags. This function contains a simple method with some parameters specifying the full chrome URL of the window to open, that it is a chrome file and that it is a dialog. 

    When the button file is opened with a chrome URL from Mozilla, you can click the button, and your dialog box will appear in a window of its own. Clicking the ok or cancel buttons (which both do exactly the same thing, as we haven’t scripted these) will close the dialog, but Mozilla itself will remain open. You could do the same thing for the wizard example to prevent Mozilla from closing, and also to give it its own window.



     
     
    >>> More XML Articles          >>> More By Dan Wellman
     

       

    XML ARTICLES

    - Flex Array Collection Sort and Filtering
    - The Flex Tree Control
    - Flex List Controls
    - Working with Flex and Datagrids
    - How to Set Up Podcasting and Vodcasting
    - Creating an RSS Reader Application
    - Building an RSS File
    - An Introduction to XUL Part 6
    - An Introduction to XUL Part 5
    - An Introduction to XUL Part 4
    - An Introduction to XUL Part 3
    - An Introduction to XUL Part 2
    - An Introduction to XUL Part 1
    - XML Matters: Practical XML Data Design and M...
    - Practical XML Data Design and Manipulation f...





    © 2003-2009 by Developer Shed. All rights reserved. DS Cluster 3 Hosted by Hostway
    For more Enterprise Application Development news, visit eWeek