METHOD AND SYSTEM FOR BUILDING AND USING AN APPLICATION
FIELD OF THE INVENTION
The present invention relates to data communications technology. The object of the present invention is to provide a method and a system for creating and administrating an application related to mark-up languages .
BACKGROUND OF THE INVENTION
A business enterprise conventionally seeks a way to offer the information in its operative information systems to be browsed, modified and updated via mobile terminals. WWW applications (WWW, World Wide Web) can be created by using, for instance, the HTML mark-up language (HTML, Hyper Text Mark-up Language) and various script languages . The most common way of creating WWW and WAP applications (WAP, Wireless Application Protocol) is to create the pages as ordinary text files. In other words, the creator of a WWW or a WAP page directly modifies existing mark-up language code. The server is able to read and parse the programmable parts of the page and run the code that creates the page as a result of the incoming service request. Thus, as a result of executing the program code, a page is created, which is sent back to the terminal device.
There are several application development tools in the market for designing applications with the help of a graphical view. The main idea of the present application development tools is that the application developer directly works on a document presented in certain mark-up language. This leads to several problems. Since the developer works directly with the mark-up language document, there is a high risk of coding errors. For the developer to be able to code a
document in a certain mark-up language, he must have at least a basic knowledge of the mark-up language and its use in order to produce a satisfactory final result. Furthermore, a specific problem is that the modifiable document is the form of a particular markup language. The document is in the form of a particular mark-up language, whereas terminal devices are of several different incompatible types. Thus, the developer needs to decide at the beginning of the development work, which will be the mark-up language to be used in the document .
A special emulator is needed for checking the final layout of the mark-up language specific document, which is being coded. The document being coded must first be parsed for the emulator. The emulator shows the parsed document . The emulator can be used for simulating the use of a real application. The essential restriction of the emulator is that the coded document cannot be modified in it. The modification has to be done to a text-format mark-up language document and to be able to see the changes, the document needs to be parsed again for the emulator. In mark-up languages such as HTML and WML (WML, Wireless Mark-up Language) page structure, content and layout are heavily tied to each other. This lessens the possibilities of generic designing and implementation.
Various means can be used for implementing an application development tool . One example is the MVC (MVC, Model View Controller) . The MVC is a designing model, which offers high scalability, for instance, for exploiting different mark-up languages by dividing the application into three parts:
- Model: Information and the functionality needed to control it
- View: Presentation of information in different formats in different terminals
- Controller: Management of the parts of applications and reception of input from the user.
When an information structure has a clear interface, different components can easily be added to it for presenting information in different formats. When the input coming from the user is treated as a separate entity, the source of the input can easily be changed, for instance, from a keyboard into a mouse or even speech. The MVC also works recursively. An upper level model has a separate MVC. Within the model there may be another model, which again has its own views and controllers.
The MVC works as a model providing a frame for the design that establishes solution principles to support the design work before the implementation decisions are made. This provides the advantage of allowing the design work to go on like the implementation decisions had already been made. Each dialog (window) visible to the user has a corresponding view in the application and each view is usually controlled by one controller. The user input data reach the corresponding view that passes them to the corresponding controller. The controller processes the input by calling the services of the model and by updating the user interface by calling the services of the view. The controller reports to the main controller, which further informs the other controllers if needed.
OBJECT OF THE INVENTION
The object of the invention is to eliminate the above-mentioned drawbacks or at least to significantly alleviate them. A specific object of the invention is to disclose a new type of method and system with which applications can be generically created without being restricted to a predetermined mark-up language .
SUMMARY OF THE INVENTION
The present invention relates to creating a mark-up language independent application and using the created application in a data communications system.
The object of the invention is to produce a generic application that can later be presented on a user's terminal device by using an appropriate mark-up language. In the method within the invention, elements are positioned into a graphical user interface window. The graphical user interface window offers the developer of the application a real-time view of the state of the final application. In other words, the application developer works directly with the final view perceived by the user. Elements can be positioned, for instance, by using the drag-and-drop technique from the menus of the application development tool. Correspondingly, elements can be removed from the graphical editor. When the application developer positions the desired element into the graphical user interface window, the user interface window checks the compatibility of the new element with the application existing in the window. The new element is either accepted or rejected to be positioned into the graphical user interface window. Each element has preferably been modelled as an object-oriented class.
It is to be noted that the application developer does not directly write a code according to any mark-up language but works directly with the view visible to the user. When the application developer is building an application with the graphical user interface window, the structure and content of the application are automatically maintained. The application is saved in the application development tool's proprietary format, from which it can later be presented in desired mark-up language, for instance in WML or HTML. The proprietary format is, for instance, XML (XML, eX-
tended Mark-up Language) . The application is saved in a format, which separates the content, structure and layout from each other. The application's proprietary implementation model is preferably an object-oriented model, which makes modifications easier during the application creation phase.
The saved application can later be executed for the user with a certain mark-up language during run time according to the user's terminal device. In other words, the decision regarding the mark-up language to be used to execute the application is only made after the user has requested execution of the application via her/his terminal.
In a preferred example, the MVC is used as the design model for designing an application development tool to be used in creating an application.
An object of the invention is also a system for creating a generic application related to mark-up languages and for using the created application in a data communications system comprising an application development tool for creating the application, a terminal device and one or more servers, with which the application is requested from the terminal device. According to the invention, the system comprises a graphical user interface window for positioning the elements and for creating the application, checking means for checking the compatibility of a new element with an application existing in the window, a structure model for maintaining the structure and content of the application, storing means for saving the application and executing means for executing the application for the user at run-time according to the user's terminal device.
Due to the present invention, the application developer can create applications without having to write actual program code at all. In other words, the
application developer need not to have any knowledge of programming or mark-up languages .
The document model presented in the invention maintains its own structure and the validation of the document is done while as the document changes . The document model used prevents illegal actions itself.
LIST OF ILLUSTRATIONS
In the following, the invention will be described in detail by the aid of embodiment examples, wherein
Fig. 1 presents a preferred example of implementing the invention,
Fig. 2 presents a view of a preferred application development tool,
Fig. 3 presents a preferred example in which an element is added to the graphical user interface window, and
Fig. 4 presents a preferred example of the system in which the present invention can be used.
DETAILED DESCRIPTION OF THE INVENTION
The example presented in Figure 1 comprises three larger entities: an application environment APP (Application package) , a run-time environment RUN (Run time package) and a design environment DSN (Design time package) . The application environment APP is an entity that contains the structure and building blocks of the proprietary application format being created with the application development tool. The application environment APP does not contain any functions associated with showing the contents or running the application. The run-time environment RUN is an entity in which applications described for the components of the application environment APP are run. The fundamental function of the run-time environment RUN is to execute
the created application to the end user and to engage the proprietary application model with the target server environment. The run-time environment RUN is independent of the design environment DSN. The applications are designed and implemented in the design environment DSN. The aim of the design environment DSN is to provide an easy-to-use environment for creating and administrating applications. It is also possible to have several design environments DSN.
The application design and implementation environment can be manifold. The run-time environment RUN, for instance, may have several implementations, the design environment DSN may be different in different product packages and [when] new terminal devices as well as mark-up languages appear, the design and implementation environment has to be scalable. For this reason, for example, the MVC design model (MVC, Model View Controller) is used. The internal structure of the application is presented as an independent entity in the application environment APP (model) . The application is modified in the design environment DSN and correspondingly executed in the run time environment RUN (controller) . Everything related to the presentation of the application is within the implementation environment TKIT (view) .
The functionality contained in the implementation environment TKIT implements the design views of the design environment and production of applications in the form required by the user's terminal device. Pages created in the development environment are saved in the application development tool's proprietary format, for example, in XML, from which they can be parsed to the desired mark-up language, for example, WML or HTML. The proprietary format of page implementation is an object-oriented model, which makes it easier to modify the page in the design environment. At the same time, this allows easy localization imple-
mentations. Locale-dependent objects take care of their format of presentation themselves as required by the locale.
In the example presented in Figure 1 the application frame is divided into design and run time environments. In addition, it separates the applications itself into its own entity, the application being created in the design environment and executed in the run-time environment. The designing of the application is conducted graphically by formulating user interface pages and attaching functions to them. It is to be noted that in designing the application, there is no need to write program code at all. This is a significant factor in decreasing occasions of code errors. The run-time environment includes a server extension, with which the application pages are presented in a format defined by the abilities and restrictions of the terminal device.
Figure 2 presents a preferred view of the application development tool BU. The view comprises different menus and element button bars. These element buttons can be dragged into the graphical editor GU during the application design. In this example, the application development tool also comprises an application tree TREE, an application map MAP, an element view EMT and a message view MES.
The application tree TREE (Application Tree) refers to a window that shows the documents forming the application and the elements contained in them. The application map MAP refers to a window that shows the structure of the application and the interdependences of the documents that form the application. The element view EMT (Object Inspector) refers to a window with which the features of an element positioned into the graphical editor can be edited. The message view MES (Message View) refers to a window that shows the application developer messages concerning error situa-
tions and unexpected events when executing the program.
Figure 3 presents an example of adding an element into the graphical editor GU. When a single element is dragged using the drag-and-drop method from the element button bar into the graphical editor GU (arrow 1) , it locates the spot in the window to which the element was dropped (arrow 2) . On the basis of this, it either accepts or rejects the drop function. If the drop function is successful, in the program's own Document Object Model DOM, an existing object is fetched into which the element is to be added. The object is queried if the element is valid, i.e. whether it can be added to this object (arrow 3) . If it can be added, the object itself adds the element in question as its child element (arrows 4 and 5) . If the element cannot be added, an exception is sent to the graphical editor (arrow 6) . The checking procedure preceding the addition of the element also means that an element, which can be added to the object, can be presented in different mark-up languages, in other words, a visual representation for the element exists in the spot where it is being added.
At the same time, a visual representation is fetched for the element and the element is shown in the graphical editor GU. The following program parts are needed to handle this whole series of events in the module connected to the graphical editor: the graphical editor GU, the program's own DOM (Document Object Model - document model, a group of classes with inheritance) and a DocContainerElement class DCE in the program.
The graphical editor GU uses the Application- Model module for administrating the application context. It is a model that contains the whole application in the form of objects. In the ApplicationModel module, there is an object (class) for each context
element (text, image, input field, button etc.) containing the features of the context element. The graphical editor communicates with the application design environment via a DesignTimeContext module.
Figure 4 presents an example of a system in which the present invention can be used. Figure 4 shows the routes through which end users and developers handle the environment. The design, implementation and maintenance of the application take place in the design environment DSN, which is used by the application developer DEV. The execution of the application takes place in the run-time environment RUN, which the end user requests with his/her terminal device through a WAP gateway SER2 and a WWW server SER1. The application APP1 contains the structure and building blocks of the application being created. The application APP1 does not contain any functionality related to present the content of the application or to is executing. The application APP1 comprises the checking means CM for checking the compatibility of a new element with the application in the window, a structure model ST for maintaining the application structure and the storing means SM for saving the application. The abovementioned procedures are preferable implemented using a computer and program blocks .
The final application is finished only when someone starts using it, because until that it is not known which mark-up language is to be used to present the application.
The invention is not limited to the examples of its embodiments describes above; instead, many variations are possible within the scope of the inventive idea defined in the claims.