TIBCOmmunity: General Interface Blog : Tags : asynchronous

Some of the FAQ that user have on XML resource are: Is there a build in way of doing asynchronous loading and caching of XML document? , How do I fetch xml document into the application cache asynchronously ? and How can I make sure that what I load myself will be used by GI instead loading again from the web server?

Well, quick answer is : Yes, use

jsx3.app.Cache.getOrOpenAsync(strURL)

Asynchronous Loading

Cache documents can be loaded asychronously with the getOrOpenAsync() method. This method returns the corresponding document synchronously if it already exists in the cache. If the document does not exist in the cache, then it is loaded asynchronously and the method returns a placeholder document. The namespace URI of this placeholder document is Cache.XSDNS and its root node name is "loading".

Method getOrOpenAsync(strURL, strId, objClass) Asynchronously loads an xml document and stores it in this cache.

Parameters:

strURL {String | jsx3.net.URI} – url (relative or absolute) the URI of the document to open.
strId – the id under which to store the document. If this parameter is not provided, thestrURL parameter is used as the id.
objClass {jsx3.lang.Class} – jsx3.xml.Document (default value) or one of its subclasses. The class with which to instantiate the new document instance.

Returns:

{jsx3.xml.Document} – the document retrieved from the cache or a placeholder document if the document is in the process of loading asynchronously.

Since:

3.5

0 Comments 0 References Permalink Tags: ajax, gi, asynchronous, xml

Does AMP make application harder to maintain? Is it worth re-implementing an existing application using AMP? When do you decide you need AMP as oppose to simple classes and packages?

Thiese were some of the questions and doubts that comes up during discussions on AMP. However, using AMP is really not an either or choice. You can keep using classes and packages. What you need to be aware of are the new programming facilities, the jsx3.$ functions. Especially the Asynchronous Programming Utilities

In Short, Why use AMP? Well ..

> An application's main definition XML in an AMP application can be made up of several source code files that are developped separately and then assembled together. Saving time since it is not necessary to recompose the complete application, when making a single change, but only the file that contains the change.

> There is a difference between complexity and maintainability. Making the assumption that the complexity of the underlying framework will lead to higher cost in maintenance is too simplistic.

> In the old way, coordinating the integration of a large complex application becomes a major task when everything you do may affect someone else.

Builder and AMP integration :

1. Creating AMP based application is a distributed process by nature. AMP based application are best suited for a large scale development with large number of team members. The fact that you cannot see the overall application when you work on one module should not affect the developer since he will be focused only on his module.
2. When developing using AMP, you can continue to develop GUI prototypes with Builder, which is essentially what the visual environment is good at.

> An investment in time and resource must be made to convert an application to AMP based design. There is definitely effort needed to design the proper extension point abstractions.

1. However, when the conversion work is done, the application becomes much easier to add functionality to and maintain than it would ever be using a different architectural design
2. In the case of GI builder, we're now able to disable or add new functionality into Builder without fear of inadvertently breaking the other functionalities within GI Builder.
3. The performance improvement for GI Builder over HTTP is probably at least double of what it was before.

> The architectural constraints that AMP imposes actually makes code easier to maintain and less brittle. For example, interactions between plug-ins are well defined and limited in AMP, which encourages loosely coupled application components. When using AMP correctly, spaghetti code is must less likely to occur and would never span plug-ins, greatly reducing developer burden in maintaining not just their own code but also those of others.

> Performance improvement using AMP architecture comes from

1. Forcing good design and coding practice in a asychronous environment.
2. Defining publish / subscribe interface that allow one to many communications and fully loosely coupled module
3. Allowing feature/extension based load (plug-in) and play, which can lead to smaller run-time application size.

> The well defined modular interface in AMP means that what was not possible before can now be done, such as : integrating the application without some of it parts, adding or removing parts and running a partially complete application.