Code Complete
The C++ Programming Language Third Edition by Bjarne Stroustrup
Efffective C++
More Effective C++
Pragmatic Programmer
More Exceptional C++
Modern C++ Design, Generic Programming and Design Patterns Applied
Wednesday, February 10, 2010
Tuesday, February 2, 2010
SOA
Source:
If a service-oriented architecture is to be effective, we need a clear understanding of the term service. A service is a function that is well-defined, self-contained, and does not depend on the context or state of other services.
A service-oriented architecture is essentially a collection of services. These services communicate with each other. The communication can involve either simple data passing or it could involve two or more services coordinating some activity. Some means of connecting services to each other is needed.
The .Net technology introduces the SOA by mean of web services.
The SOA can be used as the concept to connect multiple systems to provide services. It has it's great share in the future of the IT world.
According to the imaginary diagram above, we can see how the Service Oriented Architecture is being used to provide a set of centralized services to the citizens of a country. The citizens are given a unique identifying card, where that card carries all personal information of each citizen. Each service centers such as shopping complex, hospital, station, and factory are equipped with a computer system where that system is connected to a central server, which is responsible of providing service to a city. As an example when a customer enter the shopping complex the regional computer system report it to the central server and obtain information about the customer before providing access to the premises. The system welcomes the customer. The customer finished the shopping and then by the time he leaves the shopping complex, he will be asked to go through a billing process, where the regional computer system will manage the process. The payment will be automatically handled with the input details obtain from the customer identifying card.
The regional system will report to the city (computer system of the city) while the city will report to the country (computer system of the country).
Source:
http://www.service-architecture.com/web-services/articles/web_services_explained.html
Web Service
Web Services refers to the technologies that allow for making connections. Services are what you connect together using Web Services. A service is the endpoint of a connection. Also, a service has some type of underlying computer system that supports the connection offered.
The Web Services Description Language (WSDL) forms the basis for Web Services. The following figure illustrates the use of WSDL. At the left is a service provider. At the right is a service consumer. The steps involved in providing and consuming a service are:
If a service-oriented architecture is to be effective, we need a clear understanding of the term service. A service is a function that is well-defined, self-contained, and does not depend on the context or state of other services.
A service-oriented architecture is essentially a collection of services. These services communicate with each other. The communication can involve either simple data passing or it could involve two or more services coordinating some activity. Some means of connecting services to each other is needed.
The .Net technology introduces the SOA by mean of web services.
The SOA can be used as the concept to connect multiple systems to provide services. It has it's great share in the future of the IT world.
According to the imaginary diagram above, we can see how the Service Oriented Architecture is being used to provide a set of centralized services to the citizens of a country. The citizens are given a unique identifying card, where that card carries all personal information of each citizen. Each service centers such as shopping complex, hospital, station, and factory are equipped with a computer system where that system is connected to a central server, which is responsible of providing service to a city. As an example when a customer enter the shopping complex the regional computer system report it to the central server and obtain information about the customer before providing access to the premises. The system welcomes the customer. The customer finished the shopping and then by the time he leaves the shopping complex, he will be asked to go through a billing process, where the regional computer system will manage the process. The payment will be automatically handled with the input details obtain from the customer identifying card.
The regional system will report to the city (computer system of the city) while the city will report to the country (computer system of the country).
Source:
http://www.service-architecture.com/web-services/articles/web_services_explained.html
Web Service
Web Services refers to the technologies that allow for making connections. Services are what you connect together using Web Services. A service is the endpoint of a connection. Also, a service has some type of underlying computer system that supports the connection offered.
The Web Services Description Language (WSDL) forms the basis for Web Services. The following figure illustrates the use of WSDL. At the left is a service provider. At the right is a service consumer. The steps involved in providing and consuming a service are:
- A service provider describes its service using WSDL. This definition is published to a directory of services. The directory could use Universal Description, Discovery, and Integration (UDDI). Other forms of directories can also be used.
- A service consumer issues one or more queries to the directory to locate a service and determine how to communicate with that service.
- Part of the WSDL provided by the service provider is passed to the service consumer. This tells the service consumer what the requests and responses are for the service provider.
- The service consumer uses the WSDL to send a request to the service provider.
- The service provider provides the expected response to the service consumer.
Using Universal Description, Discovery, and Integration (UDDI)
The directory shown in the above figure could be a UDDI registry. The UDDI registry is intended to eventually serve as a means of "discovering" Web Services described using WSDL . The idea is that the UDDI registry can be searched in various ways to obtain contact information and the Web Services available for various organizations. How much "discovery" will be used in the early days of Web Services is open to discussion. Nevertheless, even without the discovery portion, the UDDI registry is a way to keep up-to-date on the Web Services your organization currently uses.Using SOAP
All the messages shown in the above figure are sent using SOAP. (SOAP at one time stood for Simple Object Access Protocol. Now, the letters in the acronym have no particular meaning .) SOAP essentially provides the envelope for sending the Web Services messages. SOAP generally uses HTTP , but other means of connection may be used. HTTP is the familiar connection we all use for the Internet. In fact, it is the pervasiveness of HTTP connections that will help drive the adoption of Web Services.Using XML with WSDL
WSDL uses XML to define messages. XML has a tagged message format. This is shown in the above figure. The tagSunday, January 17, 2010
QT
Haavard Nord and Eirik Chambe-Eng (the original developers of Qt and the CEO and President, respectively, of Trolltech) began development of "Qt" in 1991, three years before the company was incorporated as Quasar Technologies, then changed the name to Troll Tech, and then to Trolltech.
The toolkit was called Qt because the letter Q looked appealing in Haavard's Emacs font, and "t" was inspired by Xt, the X toolkit.
In Qt terminology, a widget is a visual element in a user interface.
Qt is a comprehensive, cross-platform C++ application development framework, which includes:
‧ An extensive C++ class library of over 400 classes
‧ GUI, Database, Core, XML, Networking, Open GL, Multithreading, and more
‧ Advanced cross-platform development tools for:
‧ GUI layout and forms design
‧ Internationalization
‧ Documentation
The Qt class library encompasses all the functions needed to build robust, high-end applications
‧ Separated into several modules, Qt’s intuitive API includes:
‧ Core Classes
‧ GUI Classes
‧ SQL Database Classes
‧ XML Classes
‧ Networking Classes
‧ OpenGLR 3D Graphics Classes
Qt Designer
Qt Designer is a powerful, drag-and-drop GUI layout and forms builder
‧ Features
‧ Supports forms and dialog creation with instant preview
‧ Integrates with Qt layout system
‧ Extensive collection of standard widgets
‧ Support for custom widgets and dialogs
‧ Seamless integration with MicrosoftR Visual Studio .NET
‧ Benefits
‧ Greatly speeds the interface design process
‧ Enables native look and feel across all supported platforms
‧ Developers work within the environment of their choice, leveraging existing skills
CROSS-PLATFORM DEVELOPMENT WITH Qt
Qt is the leading framework for cross-platform application development
With Qt, development teams can create native applications for all major operating systems
‧ The Qt API and tools are identical across all supported operating systems
‧ Targeting a new platform demands little more than a simple recompile of a single source code-base
Qt enables development teams to natively target:
‧ WindowsR 98 through Vista?
‧ Mac OSR X
‧ Linux
‧ Solaris, HP-UX, IRIX, AIX, BSD, Tru64 UNIX
HOW Qt PROVIDES NATIVE LOOK AND FEEL
The Qt API is uniform across platforms.
Qt interfaces with platform specific APIs “under the hood”. Benefits:
‧ Only one API to learn
‧ High performance, memoryefficient, compiled applications
‧ Native look and feel
With Qt, development teams can:
‧ Target multiple platforms from a single source
‧ Shorter development time – faster time to market
‧ Reduced maintenance expense
‧ Avoid OS-subgroups in development organization
‧ Enjoy true platform independence
‧ Target a new platform in weeks, not months
‧ Rapidly respond to evolving market requirements
‧ Remain insulated from platform changes
‧ Qt is actively maintained and developed to support all new mainstream OS variants
‧ Focus development efforts instead on value-adding innovation
NEW IN 4.2: WIDGET STYLESHEETS
Rapid UI styling through simple CSS syntax
‧ Complex styles can be defined in a few lines of Cascading Style Sheet (CSS)- like code
‧ Define styles in a fraction of the time and code traditionally needed
‧ Style to the right created in 50 lines
NEW IN 4.2: GRAPHICS VIEW
Powerful 2D graphics canvas
‧ Handles millions of objects
‧ Support for collision detection, otimized level-of-detail rendering, affine item transformations
‧ Enhanced control for animations and drag and drop features
VISUAL STUDIO .NET INTEGRATION
Qt 4 is seamlessly integrated with MicrosoftR Visual Studio .NET
‧ Qt now enables Windows developers to leverage their skills to target multiple operating systems from a familiar environment
‧ Qt’s integration with Visual Studio includes:
‧ Code completion and syntax highlighting, boosting developer productivity using the intuitive Qt API
‧ Powerful GUI layout system and forms design using integrated Qt Designer
‧ Qt documentation integrated with Visual Studio online help
‧ Templates for the most common Qt application types
Qt is available in three editions, each optimized for a unique purpose:
‧ Qt Console Edition
‧ Qt Desktop Light Edition
‧ Qt Desktop Edition
Qt CONSOLE EDITION
An edition of Qt optimized for the development of GUIindependent back-end and server applications
The Qt Console Edition includes:
‧ Qt Core classes
‧ Database module
‧ Network module
‧ XML module
Qt Desktop Light Edition
An edition of Qt that provides all the features and capabilities required for cross-platform GUI application development
The Qt Desktop Light Edition includes:
‧ Qt Core classes
‧ Qt GUI module
‧ Qt Designer
‧ Qt3Support module
‧ MicrosoftR Visual Studio integration (Qt/Windows)
Signals and Slots
Signals and slots are used for communication between objects. The signal/slot mechanism is a central feature of Qt and probably the part that differs most from other toolkits.
In GUI programming we often want a change in one widget to be notified to another widget. More generally, we want objects of any kind to be able to communicate with one another. For example if we were parsing an XML file we might want to notify a list view that we're using to represent the XML file's structure whenever we encounter a new tag.
The signals and slots mechanism is a powerful inter-object communication mechanism that can be used to completely replace the crude callbacks and message maps used by legacy toolkits.
Older toolkits achieve this kind of communication using callbacks. A callback is a pointer to a function, so if you want a processing function to notify you about some event you pass a pointer to another function (the callback) to the processing function. The processing function then calls the callback when appropriate. Callbacks have two fundamental flaws. Firstly they are not type safe. We can never be certain that the processing function will call the callback with the correct arguments. Secondly the callback is strongly coupled to the processing function since the processing function must know which callback to call.
A signal is emitted when a particular event occurs. Qt's widgets have many pre-defined signals, but we can always subclass to add our own. A slot is a function that is called in reponse to a particular signal. Qt's widgets have many pre-defined slots, but it is common practice to add your own slots so that you can handle the signals that you are interested in.
The signals and slots mechanism is type safe: the signature of a signal must match the signature of the receiving slot. (In fact a slot may have a shorter signature than the signal it receives because it can ignore extra arguments.) Since the signatures are compatible, the compiler can help us detect type mismatches. Signals and slots are loosely coupled: a class which emits a signal neither knows nor cares which slots receive the signal. Qt's signals and slots mechanism ensures that if you connect a signal to a slot, the slot will be called with the signal's parameters at the right time. Signals and slots can take any number of arguments of any type. They are completely typesafe: no more callback core dumps!
All classes that inherit from QObject or one of its subclasses (e.g. QWidget) can contain signals and slots. Signals are emitted by objects when they change their state in a way that may be interesting to the outside world. This is all the object does to communicate. It does not know or care whether anything is receiving the signals it emits.
All classes that contain signals or slots must mention Q_OBJECT in their declaration.
A signal is emitted for every connection you make, so if you duplicate a connection, two signals will be emitted. You can always break a connection using QObject::disconnect().
The preprocessor changes or removes the signals, slots and emit keywords so that the compiler is presented with standard C++.
To benefit from signals and slots, a class must inherit from QObject or one of its subclasses and include the Q_OBJECT macro in the class’s definition. Signals are declared in the signals section of the class, while slots are declared in the public slots, protected slots, or private slots sections.
One object’s signal can be connected to many different slots, and many signals can be
connected to one slot in a particular object. Connections are made between signals and
slots whose parameters have the same types. A slot can have fewer parameters than the
signal and ignore the extra parameters.
Signals
Signals are emitted by an object when its internal state has changed in some way that might be interesting to the object's client or owner. Only the class that defines a signal and its subclasses can emit the signal.
When a signal is emitted, the slots connected to it are executed immediately, just like a normal function call. The signal/slot mechanism is totally independent of any GUI event loop. The emit will return when all slots have returned.
If several slots are connected to one signal, the slots will be executed one after the other, in an arbitrary order, when the signal is emitted.
Signals are automatically generated by the moc and must not be implemented in the .cpp file. They can never have return types (i.e. use void).
Slots
A slot is called when a signal connected to it is emitted.
Since slots are normal member functions with just a little extra spice, they have access rights like ordinary member functions. A slot's access right determines who can connect to it:
A public slots section contains slots that anyone can connect signals to. This is very useful for component programming: you create objects that know nothing about each other, connect their signals and slots so that information is passed correctly, and, like a model railway, turn it on and leave it running.
A protected slots section contains slots that this class and its subclasses may connect signals to. This is intended for slots that are part of the class's implementation rather than its interface to the rest of the world.
A private slots section contains slots that only the class itself may connect signals to. This is intended for very tightly connected classes, where even subclasses aren't trusted to get the connections right.
The signals and slots mechanism is efficient, but not quite as fast as "real" callbacks. Signals and slots are slightly slower because of the increased flexibility they provide, although the difference for real applications is insignificant. In general, emitting a signal that is connected to some slots, is approximately ten times slower than calling the receivers directly, with non-virtual function calls.
Widgets
Widgets are visual elements that are combined to create user interfaces. Buttons, menus, scroll bars, message boxes, and application windows are all examples of widgets. Qt’s widgets are not arbitrarily divided between “controls” and “containers”; all widgets can be used both as controls and as containers. Custom widgets can easily be created by subclassing existing Qt widgets, or created from scratch if necessary.
Standard widgets are provided by the QWidget class and its subclasses, and custom widgets can be created by subclassing them and reimplementing virtual functions.
A widget may contain any number of child widgets. Child widgets are shown within the parent widget’s area. A widget with no parent is a top-level widget (a “window”), and usually has its own entry in the desktop environment’s task bar. Qt imposes no arbitrary limitations on widgets.
Main Windows
The QMainWindow class provides a framework for typical application main windows.
For SDI applications, the central area of a QMainWindow can contain any widget. For example, a text editor could use a QTextEdit as its central widgetz
For MDI applications, the central area will usually be occupied by a QMdiArea widget which is populated with QMdiSubWindow widgets.
The toolkit was called Qt because the letter Q looked appealing in Haavard's Emacs font, and "t" was inspired by Xt, the X toolkit.
In Qt terminology, a widget is a visual element in a user interface.
Qt is a comprehensive, cross-platform C++ application development framework, which includes:
‧ An extensive C++ class library of over 400 classes
‧ GUI, Database, Core, XML, Networking, Open GL, Multithreading, and more
‧ Advanced cross-platform development tools for:
‧ GUI layout and forms design
‧ Internationalization
‧ Documentation
The Qt class library encompasses all the functions needed to build robust, high-end applications
‧ Separated into several modules, Qt’s intuitive API includes:
‧ Core Classes
‧ GUI Classes
‧ SQL Database Classes
‧ XML Classes
‧ Networking Classes
‧ OpenGLR 3D Graphics Classes
Qt Designer
Qt Designer is a powerful, drag-and-drop GUI layout and forms builder
‧ Features
‧ Supports forms and dialog creation with instant preview
‧ Integrates with Qt layout system
‧ Extensive collection of standard widgets
‧ Support for custom widgets and dialogs
‧ Seamless integration with MicrosoftR Visual Studio .NET
‧ Benefits
‧ Greatly speeds the interface design process
‧ Enables native look and feel across all supported platforms
‧ Developers work within the environment of their choice, leveraging existing skills
CROSS-PLATFORM DEVELOPMENT WITH Qt
Qt is the leading framework for cross-platform application development
With Qt, development teams can create native applications for all major operating systems
‧ The Qt API and tools are identical across all supported operating systems
‧ Targeting a new platform demands little more than a simple recompile of a single source code-base
Qt enables development teams to natively target:
‧ WindowsR 98 through Vista?
‧ Mac OSR X
‧ Linux
‧ Solaris, HP-UX, IRIX, AIX, BSD, Tru64 UNIX
HOW Qt PROVIDES NATIVE LOOK AND FEEL
The Qt API is uniform across platforms.
Qt interfaces with platform specific APIs “under the hood”. Benefits:
‧ Only one API to learn
‧ High performance, memoryefficient, compiled applications
‧ Native look and feel
With Qt, development teams can:
‧ Target multiple platforms from a single source
‧ Shorter development time – faster time to market
‧ Reduced maintenance expense
‧ Avoid OS-subgroups in development organization
‧ Enjoy true platform independence
‧ Target a new platform in weeks, not months
‧ Rapidly respond to evolving market requirements
‧ Remain insulated from platform changes
‧ Qt is actively maintained and developed to support all new mainstream OS variants
‧ Focus development efforts instead on value-adding innovation
NEW IN 4.2: WIDGET STYLESHEETS
Rapid UI styling through simple CSS syntax
‧ Complex styles can be defined in a few lines of Cascading Style Sheet (CSS)- like code
‧ Define styles in a fraction of the time and code traditionally needed
‧ Style to the right created in 50 lines
NEW IN 4.2: GRAPHICS VIEW
Powerful 2D graphics canvas
‧ Handles millions of objects
‧ Support for collision detection, otimized level-of-detail rendering, affine item transformations
‧ Enhanced control for animations and drag and drop features
VISUAL STUDIO .NET INTEGRATION
Qt 4 is seamlessly integrated with MicrosoftR Visual Studio .NET
‧ Qt now enables Windows developers to leverage their skills to target multiple operating systems from a familiar environment
‧ Qt’s integration with Visual Studio includes:
‧ Code completion and syntax highlighting, boosting developer productivity using the intuitive Qt API
‧ Powerful GUI layout system and forms design using integrated Qt Designer
‧ Qt documentation integrated with Visual Studio online help
‧ Templates for the most common Qt application types
Qt is available in three editions, each optimized for a unique purpose:
‧ Qt Console Edition
‧ Qt Desktop Light Edition
‧ Qt Desktop Edition
Qt CONSOLE EDITION
An edition of Qt optimized for the development of GUIindependent back-end and server applications
The Qt Console Edition includes:
‧ Qt Core classes
‧ Database module
‧ Network module
‧ XML module
Qt Desktop Light Edition
An edition of Qt that provides all the features and capabilities required for cross-platform GUI application development
The Qt Desktop Light Edition includes:
‧ Qt Core classes
‧ Qt GUI module
‧ Qt Designer
‧ Qt3Support module
‧ MicrosoftR Visual Studio integration (Qt/Windows)
Signals and Slots
Signals and slots are used for communication between objects. The signal/slot mechanism is a central feature of Qt and probably the part that differs most from other toolkits.
In GUI programming we often want a change in one widget to be notified to another widget. More generally, we want objects of any kind to be able to communicate with one another. For example if we were parsing an XML file we might want to notify a list view that we're using to represent the XML file's structure whenever we encounter a new tag.
The signals and slots mechanism is a powerful inter-object communication mechanism that can be used to completely replace the crude callbacks and message maps used by legacy toolkits.
Older toolkits achieve this kind of communication using callbacks. A callback is a pointer to a function, so if you want a processing function to notify you about some event you pass a pointer to another function (the callback) to the processing function. The processing function then calls the callback when appropriate. Callbacks have two fundamental flaws. Firstly they are not type safe. We can never be certain that the processing function will call the callback with the correct arguments. Secondly the callback is strongly coupled to the processing function since the processing function must know which callback to call.
A signal is emitted when a particular event occurs. Qt's widgets have many pre-defined signals, but we can always subclass to add our own. A slot is a function that is called in reponse to a particular signal. Qt's widgets have many pre-defined slots, but it is common practice to add your own slots so that you can handle the signals that you are interested in.
The signals and slots mechanism is type safe: the signature of a signal must match the signature of the receiving slot. (In fact a slot may have a shorter signature than the signal it receives because it can ignore extra arguments.) Since the signatures are compatible, the compiler can help us detect type mismatches. Signals and slots are loosely coupled: a class which emits a signal neither knows nor cares which slots receive the signal. Qt's signals and slots mechanism ensures that if you connect a signal to a slot, the slot will be called with the signal's parameters at the right time. Signals and slots can take any number of arguments of any type. They are completely typesafe: no more callback core dumps!
All classes that inherit from QObject or one of its subclasses (e.g. QWidget) can contain signals and slots. Signals are emitted by objects when they change their state in a way that may be interesting to the outside world. This is all the object does to communicate. It does not know or care whether anything is receiving the signals it emits.
All classes that contain signals or slots must mention Q_OBJECT in their declaration.
A signal is emitted for every connection you make, so if you duplicate a connection, two signals will be emitted. You can always break a connection using QObject::disconnect().
The preprocessor changes or removes the signals, slots and emit keywords so that the compiler is presented with standard C++.
To benefit from signals and slots, a class must inherit from QObject or one of its subclasses and include the Q_OBJECT macro in the class’s definition. Signals are declared in the signals section of the class, while slots are declared in the public slots, protected slots, or private slots sections.
One object’s signal can be connected to many different slots, and many signals can be
connected to one slot in a particular object. Connections are made between signals and
slots whose parameters have the same types. A slot can have fewer parameters than the
signal and ignore the extra parameters.
Signals
Signals are emitted by an object when its internal state has changed in some way that might be interesting to the object's client or owner. Only the class that defines a signal and its subclasses can emit the signal.
When a signal is emitted, the slots connected to it are executed immediately, just like a normal function call. The signal/slot mechanism is totally independent of any GUI event loop. The emit will return when all slots have returned.
If several slots are connected to one signal, the slots will be executed one after the other, in an arbitrary order, when the signal is emitted.
Signals are automatically generated by the moc and must not be implemented in the .cpp file. They can never have return types (i.e. use void).
Slots
A slot is called when a signal connected to it is emitted.
Since slots are normal member functions with just a little extra spice, they have access rights like ordinary member functions. A slot's access right determines who can connect to it:
A public slots section contains slots that anyone can connect signals to. This is very useful for component programming: you create objects that know nothing about each other, connect their signals and slots so that information is passed correctly, and, like a model railway, turn it on and leave it running.
A protected slots section contains slots that this class and its subclasses may connect signals to. This is intended for slots that are part of the class's implementation rather than its interface to the rest of the world.
A private slots section contains slots that only the class itself may connect signals to. This is intended for very tightly connected classes, where even subclasses aren't trusted to get the connections right.
The signals and slots mechanism is efficient, but not quite as fast as "real" callbacks. Signals and slots are slightly slower because of the increased flexibility they provide, although the difference for real applications is insignificant. In general, emitting a signal that is connected to some slots, is approximately ten times slower than calling the receivers directly, with non-virtual function calls.
Widgets
Widgets are visual elements that are combined to create user interfaces. Buttons, menus, scroll bars, message boxes, and application windows are all examples of widgets. Qt’s widgets are not arbitrarily divided between “controls” and “containers”; all widgets can be used both as controls and as containers. Custom widgets can easily be created by subclassing existing Qt widgets, or created from scratch if necessary.
Standard widgets are provided by the QWidget class and its subclasses, and custom widgets can be created by subclassing them and reimplementing virtual functions.
A widget may contain any number of child widgets. Child widgets are shown within the parent widget’s area. A widget with no parent is a top-level widget (a “window”), and usually has its own entry in the desktop environment’s task bar. Qt imposes no arbitrary limitations on widgets.
Main Windows
The QMainWindow class provides a framework for typical application main windows.
For SDI applications, the central area of a QMainWindow can contain any widget. For example, a text editor could use a QTextEdit as its central widgetz
For MDI applications, the central area will usually be occupied by a QMdiArea widget which is populated with QMdiSubWindow widgets.
Monday, January 11, 2010
The Qt Object Model
By deriving classes from the QObject a number of benefits are inherited. They are listed below:
Easy memory management
When creating an instance of a class derived from QObject it is possible to pass a pointer to a parent object to the constructor. This is the basis of the simplified memory management. When a parent is deleted all its children are deleted too.
Signals and slots
Properties
Self-knowledge
Signals and Slots
They provide a mechanism through which it is possible to expose interfaces that can be freely interconnected. For example a menu item, push button, toolbar button and any other item can expose signal corresponding to "activated", "clicked" or any other appropriate event. By connecting such a signal to a slot of any other item, the event automatically calls the slots.
A signal can also include values, thus making it possible to connect a slider, a spinbox, a knob or any other value generating item to any item accepting values, for example another slider, knob or spinbox, or something completely different such as an LCD display.
The key advantage of the signals and slots is that the caller does not have to know anything about the receiver and vice versa. This makes it possible to integrate many components easily without the component's designer having actually thought about the used configuration. This is truly loose coupling.
Figure 2-2 The moc flow
This additional compilation stage may seem to complicate the building process, but there is yet another Qt tool, qmake. It makes it as simple as qmake -project && qmake && make to build any Qt application.
What are signals and slots - for real?
As mentioned earlier, a Qt applicaion is 100% C++, so what are signals and slots, for real? One part is the actual keywords, they are simply replaced by proper C++ by the pre-processor. The slots are then implemented as any class member method while the signals are implemented by the moc. Each object then holds a list of its connections (which slots are activated by which signal) and its slots (which are used to build the connections table in the connect method. The declarations of these tables are hidden in the Q_OBJECT macro. Of course there are more to this, but all can be seen by looking in a moc-generated cpp-file.
uic
The user interface compiler translates .ui files generated by Designer into C++ classes. This tool is automatically configured by qmake.
moc
The meta object compiler creates meta objects describing the classes with signals and slots. This tool is automatically configured by qmake.
Object Trees and Object Ownership
QObjects organize themselves in object trees. When you create a QObject with another object as parent, it's added to the parent's children() list, and is deleted when the parent is. It turns out that this approach fits the needs of GUI objects very well. For example, a QAccel (keyboard accelerator) is a child of the relevant window, so when the user closes that window, the accelerator is deleted too.
The static function QObject::objectTrees() provides access to all the root objects that currently exist.
You can also delete child objects yourself, and they will remove themselves from their parents. For example, when the user removes a toolbar it may lead to the application deleting one of its QToolBar objects, in which case the tool bar's QMainWindow parent would detect the change and reconfigure its screen space accordingly.
Easy memory management
When creating an instance of a class derived from QObject it is possible to pass a pointer to a parent object to the constructor. This is the basis of the simplified memory management. When a parent is deleted all its children are deleted too.
Signals and slots
Properties
Self-knowledge
Signals and Slots
They provide a mechanism through which it is possible to expose interfaces that can be freely interconnected. For example a menu item, push button, toolbar button and any other item can expose signal corresponding to "activated", "clicked" or any other appropriate event. By connecting such a signal to a slot of any other item, the event automatically calls the slots.
A signal can also include values, thus making it possible to connect a slider, a spinbox, a knob or any other value generating item to any item accepting values, for example another slider, knob or spinbox, or something completely different such as an LCD display.
The key advantage of the signals and slots is that the caller does not have to know anything about the receiver and vice versa. This makes it possible to integrate many components easily without the component's designer having actually thought about the used configuration. This is truly loose coupling.
Figure 2-2 The moc flow
This additional compilation stage may seem to complicate the building process, but there is yet another Qt tool, qmake. It makes it as simple as qmake -project && qmake && make to build any Qt application.
What are signals and slots - for real?
As mentioned earlier, a Qt applicaion is 100% C++, so what are signals and slots, for real? One part is the actual keywords, they are simply replaced by proper C++ by the pre-processor. The slots are then implemented as any class member method while the signals are implemented by the moc. Each object then holds a list of its connections (which slots are activated by which signal) and its slots (which are used to build the connections table in the connect method. The declarations of these tables are hidden in the Q_OBJECT macro. Of course there are more to this, but all can be seen by looking in a moc-generated cpp-file.
uic
The user interface compiler translates .ui files generated by Designer into C++ classes. This tool is automatically configured by qmake.
moc
The meta object compiler creates meta objects describing the classes with signals and slots. This tool is automatically configured by qmake.
Object Trees and Object Ownership
QObjects organize themselves in object trees. When you create a QObject with another object as parent, it's added to the parent's children() list, and is deleted when the parent is. It turns out that this approach fits the needs of GUI objects very well. For example, a QAccel (keyboard accelerator) is a child of the relevant window, so when the user closes that window, the accelerator is deleted too.
The static function QObject::objectTrees() provides access to all the root objects that currently exist.
You can also delete child objects yourself, and they will remove themselves from their parents. For example, when the user removes a toolbar it may lead to the application deleting one of its QToolBar objects, in which case the tool bar's QMainWindow parent would detect the change and reconfigure its screen space accordingly.
qmake
Introduction to qmake
qmake is a tool created by Trolltech to write makefiles for different compilers and platforms. Writing makefiles by hand can be difficult and error prone, especially if several makefiles are required for different compiler and platform combinations. With qmake, developers create a simple single 'project' file and run qmake to generate the appropriate makefiles. qmake takes care of all the compiler and platform dependencies, freeing developers to focus on their code. Trolltech uses qmake as the primary build tool for the Qt library, and for the tools supplied with Qt. qmake also takes care of Qt's special requirements, automatically including build rules for moc and uic.
Installing qmake manually
Before building Qt manually the following environment variables must be set:
QMAKESPEC
The QMAKESPEC environment variable
Before qmake can be used to build makefiles, the QMAKESPEC environment variable must be set to the platform-compiler combination that is being used on the system. The QMAKESPEC environment variable tells qmake where to look to find platform and compiler specific information. This ensures that the right libraries are used, and that the generated makefile uses the correct syntax. A list of the currently supported platform-compiler combinations can be found in qt/mkspecs.
For example, if you are using Windows and Microsoft Visual Studio, you would set this environment variable to win32-msvc. If you are using Solaris and g++, you would set this environment variable to solaris-g++.
QTDIR
This must be set to where Qt is (or will be) installed. For example, c:\qt and \local\qt
The 10 minute guide to using qmake
Project (.pro) files
'#' comments
You can add comments to project files. Comments begin with the '#' symbol and run to the end of the line.
Templates
The template variable tells qmake what sort of makefile should be generated for the application. The following choices are available:
app - Creates a makefile that builds an application. This is the default, so if a template is not specified, this is used.
lib - Creates a makefile that builds a library.
vcapp - Creates a Visual Studio Project file which builds an application.
vclib - Creates a Visual Studio Project file which builds a library.
subdirs - This is a special template which creates a makefile which will go into the specified directories and create a makefile for the project file and call make on it.
The 'app' template
The 'app' template tells qmake to generate a makefile that will build an application. When using this template the following qmake system variables are recognized. You should use these in your .pro file to specify information about your application.
HEADERS - A list of all the header files for the application.
SOURCES - A list of all the source files for the application.
FORMS - A list of all the .ui files (created using Qt Designer) for the application.
LEXSOURCES - A list of all the lex source files for the application.
YACCSOURCES - A list of all the yacc source files for the application.
TARGET - Name of the executable for the application. This defaults to the name of the project file. (The extension, if any, is added automatically).
DESTDIR - The directory in which the target executable is placed.
DEFINES - A list of any additional pre-processor defines needed for the application.
INCLUDEPATH - A list of any additional include paths needed for the application.
DEPENDPATH - The dependency search path for the application.
VPATH - The search path to find supplied files.
DEF_FILE - Windows only: A .def file to be linked against for the application.
RC_FILE - Windows only: A resource file for the application.
RES_FILE - Windows only: A resource file to be linked against for the application.
The CONFIG variable
The config variable specifies the options that the compiler should use and the libraries that should be linked against. Anything can be added to the config variable, but the options covered below are recognised by qmake internally.
The following options control what compiler flags are used:
release - The application is to be built in release mode. This is ignored if 'debug' is specified.
debug - The application is to be built in debug mode.
warn_on - The compiler should output as many warnings as possible. This is ignored if 'warn_off' is specified.
warn_off - The compiler should output as few warnings as possible.
The following options define the type of library/application to be built:
qt - The application is a Qt application and should link against the Qt library.
thread - The application is a multi-threaded application.
x11 - The application is an X11 application or library.
windows - 'app' template only: the application is a Windows window application.
console - 'app' template only: the application is a Windows console application.
dll - 'lib' template only: The library is a shared library (dll).
staticlib - 'lib' template only: The library is a static library.
plugin - 'lib' template only: The library is a plugin; this enables the dll option.
The '=' operator
This operator simply assigns a value to a variable, it is used like this:
TARGET = myapp
This sets the TARGET variable to myapp. This will remove any previously set TARGET.
The '+=' operator
This operator appends a value to the list of values in a variable. It is used like this:
DEFINES += QT_DLL
This appends QT_DLL to the list of pre-processor defines to be put in the makefile.
The '-=' operator
This operator removes a value from the list of values in a variable. It is used like this:
DEFINES -= QT_DLL
This removes QT_DLL from the list of pre-processor defines to be put in the makefile.
The '*=' operator
This operator only adds a value to the list of values in a variable if it doesn't already exist. It is used like this:
DEFINES *= QT_DLL
QT_DLL will only be added to the list of pre-processor defines if it is not already defined.
The '~=' operator
This operator replaces any values that match the regexp with the specified value. It is used like this:
DEFINES ~= s/QT_[DT].+/QT
This removes any values in the list that start with QT_D or QT_T with QT.
Scopes
A scope are similar to 'if' statements, if a certain condition is true, the settings inside the scope are processed. A scope is written like this:
win32 {
DEFINES += QT_DLL
}
Creating a project file
qmake uses information stored in project (.pro) files to determine what should go in the makefiles it generates.
A basic project file contains information about the application, for example, which files are needed to compile the application, and which configuration settings to use.
Here's a simple example project file:
SOURCES = hello.cpp
HEADERS = hello.h
CONFIG += qt warn_on release
We'll provide a brief line-by-line explanation, deferring the detail until later on in the manual.
SOURCES = hello.cpp
This line specifies the source files that implement the application. In this case there is just one file, hello.cpp. Most applications require multiple files; this situation is dealt with by listing all the files on the same line space separated, like this:
SOURCES = hello.cpp main.cpp
Alternatively, each file can be listed on a separate line, by escaping the newlines, like this:
SOURCES = hello.cpp \
main.cpp
A more verbose approach is to list each file separately, like this:
SOURCES += hello.cpp
SOURCES += main.cpp
This approach uses "+=" rather than "=" which is safer, because it always adds a new file to the existing list rather than replacing the list.
The HEADERS line is used to specify the header files created for use by the application, e.g.
HEADERS += hello.h
Any of the approaches used to list source files may be used for header files.
The CONFIG line is used to give qmake information about the application's configuration.
CONFIG += qt warn_on release
The "+=" is used here, because we add our configuration options to any that are already present. This is safer than using "=" which replaces all options with just those specified.
The qt part of the CONFIG line tells qmake that the application is built using Qt. This means that qmake will link against the Qt libraries when linking and add in the neccesary include paths for compiling.
The warn_on part of the CONFIG line tells qmake that it should set the compiler flags so that warnings are output.
The release part of the CONFIG line tells qmake that the application must be built as a release application. During development, programmers may prefer to replace release with debug, which is discussed later.
Project files are plain text (i.e. use an editor like notepad, vim or xemacs) and must be saved with a '.pro' extension. The name of the application's executable will be the same as the project file's name, but with an extension appropriate to the platform. For example, a project file called 'hello.pro' will produce 'hello.exe' on Windows and 'hello' on Unix.
Generating a makefile
When you have created your project file it is very easy to generate a makefile, all you need to do is go to where you have created your project file and type:
Makefiles are generated from the '.pro' files like this:
qmake -o Makefile hello.pro
For Visual Studio users, qmake can also generate '.dsp' files, for example:
qmake -t vcapp -o hello.dsp hello.pro
qmake is a tool created by Trolltech to write makefiles for different compilers and platforms. Writing makefiles by hand can be difficult and error prone, especially if several makefiles are required for different compiler and platform combinations. With qmake, developers create a simple single 'project' file and run qmake to generate the appropriate makefiles. qmake takes care of all the compiler and platform dependencies, freeing developers to focus on their code. Trolltech uses qmake as the primary build tool for the Qt library, and for the tools supplied with Qt. qmake also takes care of Qt's special requirements, automatically including build rules for moc and uic.
Installing qmake manually
Before building Qt manually the following environment variables must be set:
QMAKESPEC
The QMAKESPEC environment variable
Before qmake can be used to build makefiles, the QMAKESPEC environment variable must be set to the platform-compiler combination that is being used on the system. The QMAKESPEC environment variable tells qmake where to look to find platform and compiler specific information. This ensures that the right libraries are used, and that the generated makefile uses the correct syntax. A list of the currently supported platform-compiler combinations can be found in qt/mkspecs.
For example, if you are using Windows and Microsoft Visual Studio, you would set this environment variable to win32-msvc. If you are using Solaris and g++, you would set this environment variable to solaris-g++.
QTDIR
This must be set to where Qt is (or will be) installed. For example, c:\qt and \local\qt
The 10 minute guide to using qmake
Project (.pro) files
'#' comments
You can add comments to project files. Comments begin with the '#' symbol and run to the end of the line.
Templates
The template variable tells qmake what sort of makefile should be generated for the application. The following choices are available:
app - Creates a makefile that builds an application. This is the default, so if a template is not specified, this is used.
lib - Creates a makefile that builds a library.
vcapp - Creates a Visual Studio Project file which builds an application.
vclib - Creates a Visual Studio Project file which builds a library.
subdirs - This is a special template which creates a makefile which will go into the specified directories and create a makefile for the project file and call make on it.
The 'app' template
The 'app' template tells qmake to generate a makefile that will build an application. When using this template the following qmake system variables are recognized. You should use these in your .pro file to specify information about your application.
HEADERS - A list of all the header files for the application.
SOURCES - A list of all the source files for the application.
FORMS - A list of all the .ui files (created using Qt Designer) for the application.
LEXSOURCES - A list of all the lex source files for the application.
YACCSOURCES - A list of all the yacc source files for the application.
TARGET - Name of the executable for the application. This defaults to the name of the project file. (The extension, if any, is added automatically).
DESTDIR - The directory in which the target executable is placed.
DEFINES - A list of any additional pre-processor defines needed for the application.
INCLUDEPATH - A list of any additional include paths needed for the application.
DEPENDPATH - The dependency search path for the application.
VPATH - The search path to find supplied files.
DEF_FILE - Windows only: A .def file to be linked against for the application.
RC_FILE - Windows only: A resource file for the application.
RES_FILE - Windows only: A resource file to be linked against for the application.
The CONFIG variable
The config variable specifies the options that the compiler should use and the libraries that should be linked against. Anything can be added to the config variable, but the options covered below are recognised by qmake internally.
The following options control what compiler flags are used:
release - The application is to be built in release mode. This is ignored if 'debug' is specified.
debug - The application is to be built in debug mode.
warn_on - The compiler should output as many warnings as possible. This is ignored if 'warn_off' is specified.
warn_off - The compiler should output as few warnings as possible.
The following options define the type of library/application to be built:
qt - The application is a Qt application and should link against the Qt library.
thread - The application is a multi-threaded application.
x11 - The application is an X11 application or library.
windows - 'app' template only: the application is a Windows window application.
console - 'app' template only: the application is a Windows console application.
dll - 'lib' template only: The library is a shared library (dll).
staticlib - 'lib' template only: The library is a static library.
plugin - 'lib' template only: The library is a plugin; this enables the dll option.
The '=' operator
This operator simply assigns a value to a variable, it is used like this:
TARGET = myapp
This sets the TARGET variable to myapp. This will remove any previously set TARGET.
The '+=' operator
This operator appends a value to the list of values in a variable. It is used like this:
DEFINES += QT_DLL
This appends QT_DLL to the list of pre-processor defines to be put in the makefile.
The '-=' operator
This operator removes a value from the list of values in a variable. It is used like this:
DEFINES -= QT_DLL
This removes QT_DLL from the list of pre-processor defines to be put in the makefile.
The '*=' operator
This operator only adds a value to the list of values in a variable if it doesn't already exist. It is used like this:
DEFINES *= QT_DLL
QT_DLL will only be added to the list of pre-processor defines if it is not already defined.
The '~=' operator
This operator replaces any values that match the regexp with the specified value. It is used like this:
DEFINES ~= s/QT_[DT].+/QT
This removes any values in the list that start with QT_D or QT_T with QT.
Scopes
A scope are similar to 'if' statements, if a certain condition is true, the settings inside the scope are processed. A scope is written like this:
win32 {
DEFINES += QT_DLL
}
Creating a project file
qmake uses information stored in project (.pro) files to determine what should go in the makefiles it generates.
A basic project file contains information about the application, for example, which files are needed to compile the application, and which configuration settings to use.
Here's a simple example project file:
SOURCES = hello.cpp
HEADERS = hello.h
CONFIG += qt warn_on release
We'll provide a brief line-by-line explanation, deferring the detail until later on in the manual.
SOURCES = hello.cpp
This line specifies the source files that implement the application. In this case there is just one file, hello.cpp. Most applications require multiple files; this situation is dealt with by listing all the files on the same line space separated, like this:
SOURCES = hello.cpp main.cpp
Alternatively, each file can be listed on a separate line, by escaping the newlines, like this:
SOURCES = hello.cpp \
main.cpp
A more verbose approach is to list each file separately, like this:
SOURCES += hello.cpp
SOURCES += main.cpp
This approach uses "+=" rather than "=" which is safer, because it always adds a new file to the existing list rather than replacing the list.
The HEADERS line is used to specify the header files created for use by the application, e.g.
HEADERS += hello.h
Any of the approaches used to list source files may be used for header files.
The CONFIG line is used to give qmake information about the application's configuration.
CONFIG += qt warn_on release
The "+=" is used here, because we add our configuration options to any that are already present. This is safer than using "=" which replaces all options with just those specified.
The qt part of the CONFIG line tells qmake that the application is built using Qt. This means that qmake will link against the Qt libraries when linking and add in the neccesary include paths for compiling.
The warn_on part of the CONFIG line tells qmake that it should set the compiler flags so that warnings are output.
The release part of the CONFIG line tells qmake that the application must be built as a release application. During development, programmers may prefer to replace release with debug, which is discussed later.
Project files are plain text (i.e. use an editor like notepad, vim or xemacs) and must be saved with a '.pro' extension. The name of the application's executable will be the same as the project file's name, but with an extension appropriate to the platform. For example, a project file called 'hello.pro' will produce 'hello.exe' on Windows and 'hello' on Unix.
Generating a makefile
When you have created your project file it is very easy to generate a makefile, all you need to do is go to where you have created your project file and type:
Makefiles are generated from the '.pro' files like this:
qmake -o Makefile hello.pro
For Visual Studio users, qmake can also generate '.dsp' files, for example:
qmake -t vcapp -o hello.dsp hello.pro
Friday, January 8, 2010
AJAX
Source is: www.w3schools.com/ajax/default.asp
var XMLHttp=null
if (window.XMLHttpRequest)
{
XMLHttp=new XMLHttpRequest()
}
else if (window.ActiveXObject)
{
XMLHttp=new ActiveXObject("Microsoft.XMLHTTP")
}
Example above explained:
First create a variable XMLHttp to use as your XMLHttpRequest object. Set the value to null.
Then test if the object window.XMLHttpRequest is available. This object is available in never versions of browsers like Firefox, Mozilla, and Opera.
If it's available, use it to create a new object:
XMLHttp=new XMLHttpRequest().
If it's not available,? test if an object window.ActiveXObject is available. This object is available in Internet Explorer version 5.5 and later.
If it is available, use it to create a new object:
XMLHttp=new ActiveXObject().
A Better Example?
Some programmers will prefer to use the newest and fastest version of the XMLHttpRequest object.
The example below tries to load Microsoft's the latest version "Msxml2.XMLHTTP", available in Internet Explorer 6, before it falls back to "Microsoft.XMLHTTP", available in Internet Explorer 5.5 and later.
var XMLHttp=null
try
{
XMLHttp=new ActiveXObject("Msxml2.XMLHTTP")
}
catch(e)
{
try
{
XMLHttp=new ActiveXObject("Microsoft.XMLHTTP")
}
}
if (XMLHttp==null)
{
XMLHttp=new XMLHttpRequest()
}
XMLHttpRequest Methods
The open() method.
The open() method sets up a request to a web server.
The send() method.
The send() method sends a request to the server.
The abort() method.
The abort() method aborts the current server request.
Source is: http://www.telerik.com/Default.aspx
Need for AJAX
Poor Interactivity – web applications require that users wait for full page reloads after each interaction with the server.
Advantage:
Problems and Challenges:
Benefits of AJAX:
Where to Use AJAX:
Top tips to use AJAX:
Source: ? http://www.xul.fr/en-xml-ajax.html
- AJAX is an acronym for Asynchronous JavaScript And XML.AJAX is not a new programming language, but simply a new technique for creating better, faster, and more interactive web applications.
- AJAX uses JavaScript to send and receive data between a web browser and a web server.
- The AJAX technique makes web pages more responsive by exchanging data with the web server behind the scenes, instead of reloading an entire web page each time a user makes a change.
- AJAX is a technology that runs in your browser. It uses asynchronous data transfer (HTTP requests) between the browser and the web server, allowing web pages to request small bits of information from the server instead of whole pages.
- The technology makes Internet applications smaller, faster and more user friendl
- AJAX is based on the following open standards:
- JavaScript
- XML
- HTML
- CSS
- The open standards used in AJAX are well defined, and supported by all major browsers. AJAX applications are browser and platform independent. (Cross-Platform, Cross-Browser technology)
- Most existing web applications can be rewritten to use AJAX technology instead of traditional HTML forms.
- A traditional web application will submit input (using an HTML form) to a web server. After the web server has processed the data, it will return a completely new web page to the user.
- Because the server returns a new web page each time the user submits input, traditional web applications often run slowly and tend to be less user friendly.
- With AJAX, web applications can send and retrieve data without reloading the whole web page. This is done by sending HTTP requests to the server (behind the scenes), and by modifying only parts of the web page using JavaScript when the server returns data.
- XML is commonly used as the format for receiving server data, although any format, including plain text, can be used.
- AJAX applications can only run in web browsers with XML support.
- Only two web browsers available today - Internet Explorer (IE) and Mozilla Firefox.- have complete enough support for XML to run AJAX applications.
- Since other browsers like Safari and Opera have limited, incomplete or incorrect XML support, this tutorial will focus on IE and Firefox examples.
- There is no such thing as an AJAX server.
- AJAX pages can be served by any internet server.
- AJAX can be used for interactive communication with an XML file.
- AJAX can be used for interactive communication with Database.
- The XMLHttpRequest object is the key to AJAX.
- Different browsers use different methods to create an XMLHttpRequest object. Internet Explorer uses an ActiveXObject. Other browsers uses a built in JavaScript object called XMLHttpRequest.
- Creating An XMLHttpRequest Object
- Different browsers use different methods to create an XMLHttpRequest object.
- Internet Explorer uses an ActiveXObject.
- Other browsers uses a built in JavaScript object called XMLHttpRequest.
var XMLHttp=null
if (window.XMLHttpRequest)
{
XMLHttp=new XMLHttpRequest()
}
else if (window.ActiveXObject)
{
XMLHttp=new ActiveXObject("Microsoft.XMLHTTP")
}
Example above explained:
First create a variable XMLHttp to use as your XMLHttpRequest object. Set the value to null.
Then test if the object window.XMLHttpRequest is available. This object is available in never versions of browsers like Firefox, Mozilla, and Opera.
If it's available, use it to create a new object:
XMLHttp=new XMLHttpRequest().
If it's not available,? test if an object window.ActiveXObject is available. This object is available in Internet Explorer version 5.5 and later.
If it is available, use it to create a new object:
XMLHttp=new ActiveXObject().
A Better Example?
Some programmers will prefer to use the newest and fastest version of the XMLHttpRequest object.
The example below tries to load Microsoft's the latest version "Msxml2.XMLHTTP", available in Internet Explorer 6, before it falls back to "Microsoft.XMLHTTP", available in Internet Explorer 5.5 and later.
var XMLHttp=null
try
{
XMLHttp=new ActiveXObject("Msxml2.XMLHTTP")
}
catch(e)
{
try
{
XMLHttp=new ActiveXObject("Microsoft.XMLHTTP")
}
}
if (XMLHttp==null)
{
XMLHttp=new XMLHttpRequest()
}
XMLHttpRequest Methods
The open() method.
The open() method sets up a request to a web server.
The send() method.
The send() method sends a request to the server.
The abort() method.
The abort() method aborts the current server request.
Source is: http://www.telerik.com/Default.aspx
Need for AJAX
Poor Interactivity – web applications require that users wait for full page reloads after each interaction with the server.
Advantage:
- Real-time map panning in Google Maps and Virtual Earth is just like image panning in AdobeR PhotoshopR
- Folder browsing, message previewing, etc. in MicrosoftR OutlookR Web Access is identical to that in the desktop version of Outlook.
- Validation checking on complex input fields can be performed by the server, without reloading the page.
- Virtual scrolling of huge tables with telerik r.a.d.grid is as fast as in Microsoft ExcelR
- The core idea behind AJAX is to make the communication with the server asynchronous, so that data is transferred and processed in the background. As a result the user can continue working on the other parts of the page without interruption. In an AJAX-enabled application only the relevant page elements are updated, only when this is necessary.
Problems and Challenges:
- Writing and Maintaining Complex JavaScript
- ViewState Management – ASP.NET web controls properly maintain their ViewState between postbacks.
- Breaking the Page Paradigm – AJAX requires a different way of thinking about a web-site, since the concept of a "Page" is no longer valid. In fact, AJAX applications may be considered as closer to the desktop-applications development approach
- Accessibility – the AJAX development technique fundamentally violates the requirements for accessibility.
- New UI Interactivity Requires Learning – the UI richness of AJAX-enabled application presents users with new and unexpected functionality.
Benefits of AJAX:
- Better Performance and Efficiency
- More Responsive Interfaces
- Reduced or Eliminated "Waiting" Time
- Users Can Work with the Rest of the Page
Where to Use AJAX:
- Highly interactive applications?A good example of a highly interactive web site is Google Maps.
- Parts of pages – AJAX is best used in key places throughout a web site where it adds significant value.
- Intranets – on an internal web site the bandwidth is much higher so more AJAX usage can be successful.
- Online wizards
- Data input & validation
- Data visualization – visualizing large datasets on the web can be difficult because there’s been no easy way to pull in more data as the user needs it. Again, Google Maps is a great example.
Top tips to use AJAX:
- Give visual feedback
- Keep the Back button
- Use links for navigation
- Limit the scope of visual changes
- Use human-readable links
- Don’t bloat the code – make sure that your application uses as little client-side scripting as possible. This reduces download time for the page and also reduces the processor requirements on the client browser, so results in a faster browser experience.?
- Don’t scroll
- Reduce page loads
Source: ? http://www.xul.fr/en-xml-ajax.html
Subscribe to:
Posts (Atom)