Startup: Ajax Portal Technology - Towards Enterprise Portal of a New Generation
As it often happens, the Ajax Portal technology appeared by chance, as a synthesis of two Enterprise Portal and Ajax technologies when building the “engine” for a corporate site. As a result, something new has emerged that can give a second wind to the enterprise portals.
For about 5 years I worked in the Minsk division of a large European concern. As part of my work, I worked on Intranet (developing new applications and supporting old ones). The goal was to develop a certain integrating tool that would combine disparate applications into a single information space. The specificity of this work was that the applications were developed using various Web-technologies and were physically located on different servers. From a technical point of view, there was only one solution in order to “make friends” with these applications - to use HTML frames. HTML frames are a set of HTML tags that allow you to split a browser window into several parts, each of which can display any Internet sites, Web applications and Web pages. The highlight of this approach was that one of the frames (one of the independent parts of the browser) contained a set of links in the form of a simple list or tree, the other frame displayed Internet sites, Web applications, Web pages, PDF documents, MS Office. documents (Word, Excel, PowerPoint, etc.), photos, etc. (further we will call it content or Internet resources). At the same time there was no difference where the displayed content and the type of content were located.
Outwardly, it looked like this: the browser window was divided into two unequal parts (frames). The left side (narrower) displayed links in the form of a list or a tree, and the right side loaded content related to the selected link from the left side. Thus, an application and document console was created, which united disparate applications and documents into a single information space. The console also allowed searching, navigating and even protecting information.
On the basis of the developed solution, I offered to release a product for creating corporate websites that did not find support from the management. The typical reaction of a large company manager to any innovation is perfectly described in Jack Trout's book Horse Sense. Nevertheless, I did not leave attempts to create a new product by working in the following two companies. At the same time, every time the “engines” for the corporate site became more and more perfect.
')
Over time, the use of HTML frames was considered a “bad practice” when creating Web applications. An exception was made only for the IFRAME HTML tag, which allows you to add an independent browser window anywhere on the Web page and display any content in it. As a result, I started experimenting with pages with an embedded link tree and an IFRAME tag. When you click the links in the tree, the content is loaded inside the IFRAME tag. Naturally, the tree soon became dynamic based on JavaScript, with loadable on demand levels. There was even a version in which the tree was replaced by a set of "icons".
With the advent of Ajax technology, the idea came to load HTML / XHTML content using Ajax technology, and then display it by inserting content through the innerHTML JavaScript property (in general, the DIV tag). It worked perfectly for related applications — applications that use the same CSS and JavaScript files.
The next step was the idea of extracting all the necessary CSS and JavaScript files related to the loaded HTML / XHTML document (content) and inserting them into the main document. Cool idea, simple at first glance. I spent a lot of time before covering most of the possible situations, the difference between browsers, etc. The result was the JavaScript library ajax4all, which allows using JavaScript to insert almost any HTML / XHTML document (Web application) into another HTML / XHTML document (Web application), and then work with one and the other with almost no problems ( remark: of course, there may be a problem with the same names of CSS classes and JavaScript methods and classes, but even this problem can be solved programmatically by substituting the names of CSS classes and JavaScript classes and methods). This library could turn out to be a toy if I would not have another passion - portal solutions (enterprise portals based on JSR-168 and JSR-286 standards).
So it turned out, working on a project that later had to be migrated to WebLogic Portal, I became acquainted with portal solutions. As a result, the most important thing happened - the two passion ideas were connected, and as a result, Ajax Portal appeared.
Portals allow you to create your pages on the basis of portlets, which are small independent applications. Portlets are displayed as small independent windows on the portal page, which can include from several to several dozen portlets. If necessary, portlets can communicate with each other (interportlet communication). Using portlets allows modular software development.
Portals also allow you to aggregate (combine) data from different sources within a single portal page, which allows you not to search for information among several applications, but see it within a single browser page (if necessary, several pages). This makes it possible to speed up the decision.
The next advantage of portals is customization - the ability to customize portal pages: it becomes possible to move portlets, add new ones, delete old ones, collapse and expand portlets, i.e. to adjust the desktop (workspace) without the involvement of programmers. This allows for the greatest comfort when working with information and its processing.
What Ajax Portal gives an enterprise portal developer to a developer:
All that I cited above, ultimately leads to cheaper software creation and reduce the fixed costs of its maintenance. This is mainly achieved using the ajax4all library. She is the heart of Ajax Portal.
When creating the ajax4all library, I was faced with the need to convert all relative references to images, styles and scripts into absolute references. Otherwise, getting to the portal page, the real address of each relative link began to be calculated by the browser relative to the address of the portal page. The only serious problem is the relative addresses "wired" in the JavaScript code. In this case, the only solution is to adapt the Web application (introduction of best practice for Web applications that are supposed to be used as portlets).
The second task when creating the ajax4all library was to convert regular hypertext links into Ajax request calls and then replace the content in the portlet window.
Most Web applications still use HTML forms, i.e. it was not enough to just “isolate” the content of the Web application used as a portlet and insert it into the portlet page. It was also necessary to change the relative links in the HTML-forms. In turn, the question arose, what to do with the functionality of the forms themselves? –You submit an HTML form to the Submit button or using JavaScript usually to reload the entire portal page, instead of reloading the content in the portlet window.
The solution was found through the use of Ajax Submit pattern, which has become the de facto standard. The essence of this pattern is to substitute the usual HTML submit form for a request using Ajax and then receive the standard server response, convert it and paste it into the portal page inside the portlet window. It sounds simple, but it took several months to find an acceptable architectural solution. The complexity of the task was the significant differences in the DOM-model of browsers. Moreover, the most capricious browser when writing JavaScript was Internet Explorer, and not Safari, as is commonly believed.
Initially, I assumed to support both types of aggregation: on the client side (in the browser using JavaScript) and the classic approach on the server side (portal server). Practice has shown that the approach using ordinary Web-based applications is too good and the branch supporting aggregation on the server side has been abandoned. Maybe I'll come back to her, but later ...
Having lost the classic Java Portlet API (100% compatible with the JSR-168 and JSR-286 standards), I reached the main point: Ajax Portal is based on HTML, CSS, and JavaScript. This means that there is no dependence on the platform (including the programming language) of the server part of the portal. As a result, Ajax Portal can be considered a cross-platform solution. Java Web application development was supported by a JSP tag library. As soon as the library stabilizes and new tag attributes stop appearing, you can create a JSF component library. In June of this year (2011) I was joined by a .NET developer who made a library for .NET. With the advent of the PHP version, you can proudly declare that Ajax Portal is an absolutely cross-platform solution. There is an idea to make a library for Perl, but this is a distant prospect.
As an alternative to the Portlet API for Java, the project can offer the Java MVC framework MicroServlet. This was an example for my book on Java, which allows you to literally build a full-fledged Web application based on a single class (based on HttpServlet). The framework supports bean forms and JSP pages. Java annotations are widely used. This is an ideal solution for creating a portlet, which can have only one or two methods. Users will give their answer "to be it or not to be." I like. While the MicroServlet framework is coming closer and closer to Spring MVC. While I still do not understand whether this is good or bad. The latest trend is the new Portlet API based on the MicroServlet framework. Whether it is convenient for users time will tell.
Often portal solutions are associated with CMS. I consider it absolutely unwise to create my own CMS implementation, since Many startups are trying to occupy an already crowded niche. There are enough solutions, both commercial and free open source. On the other hand, the Ajax Portal architecture itself allows using the portal as a CMS with reduced functionality. I think this will need to devote a separate article.
I faced another interesting fact - when creating real-world applications, potential clients want to use their developments for the authorization and authentication system already used in the enterprise. Therefore, questions on the implementation of the security module are still open.
Each version of Ajax Portal in addition to the ajax4all library and Portlet API based on the MicroServlet framework carries some innovations. For versions 1.0. *, This innovation is the dynamic transformation of regions (portlet container on the portal page). The state pattern is applied. Transformation is done using CSS. CSS markers are used as markers. With the same structure of HTML / XHTML code, depending on the marker, the representation of the region and portlets changes. A region can be converted from a standard view (each portlet is displayed in a small window) to an accordion or bookmark system. In addition, it is possible to present the entire region as a single window without highlighting the pallets. There is also a view in which there is no decorating of portlets and the region.
Over the past few years, many companies have left the market for portal solutions. Many startups and open source solutions have been abandoned. In my opinion, the main reason is that the JSR-286 standard could not realize the potential of the Ajax technology. The standard JSR-286, released after the advent of Ajax, actually only expanded the capabilities of JSR-168, but did not bring anything new. These are the problems that the ajax4all library is designed to solve.
The latest fashion trend is a smooth transition of portal solutions towards mashup. I think this is a topic for a separate article. Ajax Portal is located in the niche between the enterprise portals and mashups. The result was a cross-platform Web 2.0 portal / mashup with support for customization and personalization.
The main question for any startup is analogs. I searched for a long time and searched well, but have not yet found it. If you, readers of this article, know them, I will be very grateful if you specify them to me. Please note that this is:
And the second question that usually arises, and why it was not done before? - Previously, there was no standard " Cross-Origin Resource Sharing ", which specifies the possibility of applying Ajax requests outside the current domain. Ajax Portal for remote portlets also supports proxy.
I “prepared” many popular solutions, including iGoogle, and found out that all of them basically use the HTML IFrame tag. Therefore, the ajax4all library is the only alternative I know of an HTML IFrame tag for remote portlets. When using ajax4all in Ajax Portal, it is possible to naturally fill the selected area with content and proportionally stretch it vertically, exactly what cannot be achieved using the HTML IFrame tag.
Continued:
http://habrahabr.ru/blogs/AJAX/125568/
For about 5 years I worked in the Minsk division of a large European concern. As part of my work, I worked on Intranet (developing new applications and supporting old ones). The goal was to develop a certain integrating tool that would combine disparate applications into a single information space. The specificity of this work was that the applications were developed using various Web-technologies and were physically located on different servers. From a technical point of view, there was only one solution in order to “make friends” with these applications - to use HTML frames. HTML frames are a set of HTML tags that allow you to split a browser window into several parts, each of which can display any Internet sites, Web applications and Web pages. The highlight of this approach was that one of the frames (one of the independent parts of the browser) contained a set of links in the form of a simple list or tree, the other frame displayed Internet sites, Web applications, Web pages, PDF documents, MS Office. documents (Word, Excel, PowerPoint, etc.), photos, etc. (further we will call it content or Internet resources). At the same time there was no difference where the displayed content and the type of content were located.
Outwardly, it looked like this: the browser window was divided into two unequal parts (frames). The left side (narrower) displayed links in the form of a list or a tree, and the right side loaded content related to the selected link from the left side. Thus, an application and document console was created, which united disparate applications and documents into a single information space. The console also allowed searching, navigating and even protecting information.
On the basis of the developed solution, I offered to release a product for creating corporate websites that did not find support from the management. The typical reaction of a large company manager to any innovation is perfectly described in Jack Trout's book Horse Sense. Nevertheless, I did not leave attempts to create a new product by working in the following two companies. At the same time, every time the “engines” for the corporate site became more and more perfect.
')
Over time, the use of HTML frames was considered a “bad practice” when creating Web applications. An exception was made only for the IFRAME HTML tag, which allows you to add an independent browser window anywhere on the Web page and display any content in it. As a result, I started experimenting with pages with an embedded link tree and an IFRAME tag. When you click the links in the tree, the content is loaded inside the IFRAME tag. Naturally, the tree soon became dynamic based on JavaScript, with loadable on demand levels. There was even a version in which the tree was replaced by a set of "icons".
With the advent of Ajax technology, the idea came to load HTML / XHTML content using Ajax technology, and then display it by inserting content through the innerHTML JavaScript property (in general, the DIV tag). It worked perfectly for related applications — applications that use the same CSS and JavaScript files.
The next step was the idea of extracting all the necessary CSS and JavaScript files related to the loaded HTML / XHTML document (content) and inserting them into the main document. Cool idea, simple at first glance. I spent a lot of time before covering most of the possible situations, the difference between browsers, etc. The result was the JavaScript library ajax4all, which allows using JavaScript to insert almost any HTML / XHTML document (Web application) into another HTML / XHTML document (Web application), and then work with one and the other with almost no problems ( remark: of course, there may be a problem with the same names of CSS classes and JavaScript methods and classes, but even this problem can be solved programmatically by substituting the names of CSS classes and JavaScript classes and methods). This library could turn out to be a toy if I would not have another passion - portal solutions (enterprise portals based on JSR-168 and JSR-286 standards).
So it turned out, working on a project that later had to be migrated to WebLogic Portal, I became acquainted with portal solutions. As a result, the most important thing happened - the two passion ideas were connected, and as a result, Ajax Portal appeared.
Portals allow you to create your pages on the basis of portlets, which are small independent applications. Portlets are displayed as small independent windows on the portal page, which can include from several to several dozen portlets. If necessary, portlets can communicate with each other (interportlet communication). Using portlets allows modular software development.
Portals also allow you to aggregate (combine) data from different sources within a single portal page, which allows you not to search for information among several applications, but see it within a single browser page (if necessary, several pages). This makes it possible to speed up the decision.
The next advantage of portals is customization - the ability to customize portal pages: it becomes possible to move portlets, add new ones, delete old ones, collapse and expand portlets, i.e. to adjust the desktop (workspace) without the involvement of programmers. This allows for the greatest comfort when working with information and its processing.
What Ajax Portal gives an enterprise portal developer to a developer:
- Client-side content aggregation (in the browser using JavaScript) is more efficient than classic server-side content aggregation, which is based on the JSR-168 and JSR-286 standards.
- Reducing the load on the portal server. Content and data are sent directly from the portlet server (the server on which the portlet application is running) to the browser, bypassing the portal server. The traffic decreases approximately tenfold to twentyfold and depends on the number of portlets on the portal page.
- Any change in the portlet takes place without reloading the entire portal page, including adding a new one or deleting an old portlet. As a result, everything works faster.
- Portlets can open new and close old portlets (delete from the portal page) without reloading the entire portal page.
- Simplified data exchange with other portlets (interportlet communication). This can be done either through the core of the portal page, or through a portal or portlet server.
- There is no need for a processAction method.
- There is no need to support bulky breeches based on the JSR-301 and JSR-329 standards and, as a result, a single way to download content and resources has appeared.
- Now you can use conventional Web applications as portlets (in the particular case of mashup, one of the following articles will be devoted to this). In addition, the use of porjax (Web applications with the portlet descriptors) can be considered a special case.
- As portlets, you can use versions of the mobile web application that are designed to be displayed on screens with relatively low resolutions. This is ideal for displaying such applications in portlets (for example, mobile versions of Odnoklassniki social network applications or ATO.BY geoservice ).
- No specific API. As a result - cheaper available skilled labor (it is more interesting to the manager or the architect).
All that I cited above, ultimately leads to cheaper software creation and reduce the fixed costs of its maintenance. This is mainly achieved using the ajax4all library. She is the heart of Ajax Portal.
When creating the ajax4all library, I was faced with the need to convert all relative references to images, styles and scripts into absolute references. Otherwise, getting to the portal page, the real address of each relative link began to be calculated by the browser relative to the address of the portal page. The only serious problem is the relative addresses "wired" in the JavaScript code. In this case, the only solution is to adapt the Web application (introduction of best practice for Web applications that are supposed to be used as portlets).
The second task when creating the ajax4all library was to convert regular hypertext links into Ajax request calls and then replace the content in the portlet window.
Most Web applications still use HTML forms, i.e. it was not enough to just “isolate” the content of the Web application used as a portlet and insert it into the portlet page. It was also necessary to change the relative links in the HTML-forms. In turn, the question arose, what to do with the functionality of the forms themselves? –You submit an HTML form to the Submit button or using JavaScript usually to reload the entire portal page, instead of reloading the content in the portlet window.
The solution was found through the use of Ajax Submit pattern, which has become the de facto standard. The essence of this pattern is to substitute the usual HTML submit form for a request using Ajax and then receive the standard server response, convert it and paste it into the portal page inside the portlet window. It sounds simple, but it took several months to find an acceptable architectural solution. The complexity of the task was the significant differences in the DOM-model of browsers. Moreover, the most capricious browser when writing JavaScript was Internet Explorer, and not Safari, as is commonly believed.
Initially, I assumed to support both types of aggregation: on the client side (in the browser using JavaScript) and the classic approach on the server side (portal server). Practice has shown that the approach using ordinary Web-based applications is too good and the branch supporting aggregation on the server side has been abandoned. Maybe I'll come back to her, but later ...
Having lost the classic Java Portlet API (100% compatible with the JSR-168 and JSR-286 standards), I reached the main point: Ajax Portal is based on HTML, CSS, and JavaScript. This means that there is no dependence on the platform (including the programming language) of the server part of the portal. As a result, Ajax Portal can be considered a cross-platform solution. Java Web application development was supported by a JSP tag library. As soon as the library stabilizes and new tag attributes stop appearing, you can create a JSF component library. In June of this year (2011) I was joined by a .NET developer who made a library for .NET. With the advent of the PHP version, you can proudly declare that Ajax Portal is an absolutely cross-platform solution. There is an idea to make a library for Perl, but this is a distant prospect.
As an alternative to the Portlet API for Java, the project can offer the Java MVC framework MicroServlet. This was an example for my book on Java, which allows you to literally build a full-fledged Web application based on a single class (based on HttpServlet). The framework supports bean forms and JSP pages. Java annotations are widely used. This is an ideal solution for creating a portlet, which can have only one or two methods. Users will give their answer "to be it or not to be." I like. While the MicroServlet framework is coming closer and closer to Spring MVC. While I still do not understand whether this is good or bad. The latest trend is the new Portlet API based on the MicroServlet framework. Whether it is convenient for users time will tell.
Often portal solutions are associated with CMS. I consider it absolutely unwise to create my own CMS implementation, since Many startups are trying to occupy an already crowded niche. There are enough solutions, both commercial and free open source. On the other hand, the Ajax Portal architecture itself allows using the portal as a CMS with reduced functionality. I think this will need to devote a separate article.
I faced another interesting fact - when creating real-world applications, potential clients want to use their developments for the authorization and authentication system already used in the enterprise. Therefore, questions on the implementation of the security module are still open.
Each version of Ajax Portal in addition to the ajax4all library and Portlet API based on the MicroServlet framework carries some innovations. For versions 1.0. *, This innovation is the dynamic transformation of regions (portlet container on the portal page). The state pattern is applied. Transformation is done using CSS. CSS markers are used as markers. With the same structure of HTML / XHTML code, depending on the marker, the representation of the region and portlets changes. A region can be converted from a standard view (each portlet is displayed in a small window) to an accordion or bookmark system. In addition, it is possible to present the entire region as a single window without highlighting the pallets. There is also a view in which there is no decorating of portlets and the region.
Over the past few years, many companies have left the market for portal solutions. Many startups and open source solutions have been abandoned. In my opinion, the main reason is that the JSR-286 standard could not realize the potential of the Ajax technology. The standard JSR-286, released after the advent of Ajax, actually only expanded the capabilities of JSR-168, but did not bring anything new. These are the problems that the ajax4all library is designed to solve.
The latest fashion trend is a smooth transition of portal solutions towards mashup. I think this is a topic for a separate article. Ajax Portal is located in the niche between the enterprise portals and mashups. The result was a cross-platform Web 2.0 portal / mashup with support for customization and personalization.
The main question for any startup is analogs. I searched for a long time and searched well, but have not yet found it. If you, readers of this article, know them, I will be very grateful if you specify them to me. Please note that this is:
- an alternative to the HTML IFrame tag and replacing it with Ajax requests,
- implementation of the Ajax Submit pattern for standard Web applications without special training (offline).
And the second question that usually arises, and why it was not done before? - Previously, there was no standard " Cross-Origin Resource Sharing ", which specifies the possibility of applying Ajax requests outside the current domain. Ajax Portal for remote portlets also supports proxy.
I “prepared” many popular solutions, including iGoogle, and found out that all of them basically use the HTML IFrame tag. Therefore, the ajax4all library is the only alternative I know of an HTML IFrame tag for remote portlets. When using ajax4all in Ajax Portal, it is possible to naturally fill the selected area with content and proportionally stretch it vertically, exactly what cannot be achieved using the HTML IFrame tag.
Continued:
http://habrahabr.ru/blogs/AJAX/125568/
Source: https://habr.com/ru/post/124376/
All Articles