SlideShare verwendet Cookies, um die Funktionalität und Leistungsfähigkeit der Webseite zu verbessern und Ihnen relevante Werbung bereitzustellen. Wenn Sie diese Webseite weiter besuchen, erklären Sie sich mit der Verwendung von Cookies auf dieser Seite einverstanden. Lesen Sie bitte unsere Nutzervereinbarung und die Datenschutzrichtlinie.
SlideShare verwendet Cookies, um die Funktionalität und Leistungsfähigkeit der Webseite zu verbessern und Ihnen relevante Werbung bereitzustellen. Wenn Sie diese Webseite weiter besuchen, erklären Sie sich mit der Verwendung von Cookies auf dieser Seite einverstanden. Lesen Sie bitte unsere unsere Datenschutzrichtlinie und die Nutzervereinbarung.
MVC architecture is one of the oldest patterns available for achieving the separation of concerns. MVC consists of three layers, viz, Model, View, and Controller.
MVC View May retrieve data from Model directly Controller Changes view when nessesary
MVP summarized: Navigation is handled on a per page basis using page controller pattern approach.
Classic MVC existed at a time when every control/gadget that existed in the screen was considered dumb and each control is paired with its own controller to manage the user interactions happening on them. So if 10 gadgets exist, then 10 controllers have to exist. In this scenario, every gadget is counted as a view. The advent of Windows GUI systems changed this picture. The Control-Controller relationship became obsolete. Controls gained the intelligence to respond to the actions initiated by the user. In the Windows world, view is a surface on which all the controls/gadgets exist, hence there is a need for only one controller. View can receive events and reach for controllers help to do further processing.
Model – Model receives input from the controller and decides what data it needed to fulfill the request raised by the controller. Model is also capable of doing transactions with databases or other persistent storage as needed. Once it gathers the required information, it informs the view (via controller) about the new data by raising appropriate events. View – View hosts all the UI controls needed by the end-user to interact with the application. Its job is to monitor end-user gestures and pass it to the controller for further handling. View handles the event notification received from the Model and may request for any new data required to render it on the screen. However, in some variations, Controller can be designated to retrieve dataset from the Model, format it and send it to the View. Here the view’s job is to render the data received from the view without any other processing. Controller – Controller can be imagined as an extension or a personal assistant to the view, all the events originated from the view is handled by the controller. Controller will also inform the Model on behalf of view that some event happened on the view and some new data might be required.
Form handlers provide an instance of a Presenter element of the MVP pattern. They supply values for control widgets exposed by JSP’s and manage the exchange of form data. Ideally, they are the only means of acquiring data from the web site user and supplying it to business components (droplets and tags being outwardly oriented only). Form handlers have no knowledge of business logic, but they do have enough knowledge of where that logic “lives” so as to direct actions to it. In the diagram you will note that although Ajax can be used to exchange information with web services directly, that is not considered best practice for web applications serving users on the open Internet. The issue with calling web services directly, rather than obtaining their services through corresponding form handlers, is that it exposes the site to various forms of cross site scripting attacks. ATG has added an increasing amount of scripting attack mitigation support into the form handlers. Calling web services (or any nucleus component) directly from the JSP bypasses this support.
The Form Handler Pattern Form handlers may be either request or session scoped, with strong preference given to request scope. In general, if the form is used very frequently it may be session scoped so as to avoid instantiating new copies. However, when session scoping is used then tighter maintenance of instance variables must accompany that (and session scoping form handlers is the exception).
A series of related forms
Cache can help reduce repetitive time-consuming tasks by keeping content in temporary memory. When you use Cache, you specify the content to cache and how frequently to clear the cache. Cached URLs do not retain session or request IDs. Avoid Cache in these circumstances: When the content to cache is static. When it takes more time to cache the content than to render the content. When the cached content is not applicable for many users.
The Cache.purgeCacheSeconds property determines how often content cached by any Cache servlet bean is flushed. The default is 21600 seconds (6 hours). Cache purging also occurs when a JSP is removed or recompiled.
Avoid SQLQueryForEach, SQLQueryRange and other non-cached database querying
The sortProperties parameter of *Range, *ForEach, and Targeting* servlet beansThe Range, TargetingRange, TableRange, ForEach, TargetingForeach, TableForEach, TargetingArray and TargetingFirst servlet beans accept a sortProperties parameter which provides an easy way to sort items in an array. However, sorting large arrays is expensive performance-wise. When the number of items to be sorted is potentially large, try to have the data source (e.g. the database server) handle the sorting instead
All RqlStatement properties have to be suffixed with word 'Query'.
RqlStatement in Global component: RqlStatement has to be used as property type of a class member variable
RqlStatement could be used as property type (see previous slide) or as a static variable RqlStatement in Request component should be used as a static variable
Repository have to use the property managers to access repository properties. See below example based on the profile property manager To check the item descriptor of the element it's better to use DynamicBeans API
The SQL repository uses the cascade attribute in a <property> tag to better handle hierarchical properties, which is to say properties with either the item-type or component-item-type attributes. The cascade attribute can have one or more of the values insert, update, or delete
When item property refers to another item, both items can be deleted, inserted or updated at the same time Insert: an item of the type declared by item-type attribute is also created Update: any modified referenced items are automatically updated, Any referenced items that are new items are added (Update incapsulates insert?) Delete: when an item is deleted, the referenced item is deleted as well
Never user one primary table in more than one item descriptor,this can create problem in Item caching.If table get updated by one Item, other Item will not get invalidate. Try to avoid derived properties, it can adversely affect system performance Don’t use derived and transient property as part of RQL and ATG Query Use Lazy loading in repository item to improve performance.
Verify that the PageFilter in web.xml is bound to the right extension. Typically it's *.jsp, not /*. Pre-Compiling JSPs Recheck components scope Disable Performance Monitor Ensure that loggingDebug is disabled for all components Disabling Document and Component Indexing /atg/devtools/DocumentIndex.enabled=false and /atg/devtools/ComponentIndex.enabled=false
ATG Best Practices
By Kate Soglaeva
ATG Hints by Kate Soglaeva