2.Droplets - Global
Components referencing other components:
Request Scoped Component can reference all scoped components
Session Scoped Components can reference global and session components (but not request).
Global Scoped Components can reference only global scoped components.
Real time example for session scope droplet is ShippingGroup Droplet
I do not see any good reason to have session scope component.
If you need to hold values then create a session scope bean like ShoppingCart which holds the data.
Message was edited by: NooruddinShaik
Shaik's response contains a couple of errors:
1. Session scoped components can refer to session and global components, not request. It shouldn't be necessary to memorize the rules for references in specific scopes. Global scope is the most general. There is one instance of a global component that is shared among all sessions and requests. Session is a narrower scope, where each component instance belongs to one session but is shared among all requests in that session. Request is the narrowest scope, with no sharing. Component references can refer to a more general scope but not a narrower one. Each request scoped component also belongs to a single thread, which means member variables are thread safe.
2. There are some session scoped form handlers in DCS. In particular, the form handlers that search for items in the product catalog and gift list repositories ship with session scope. The form handlers are session scoped to make shopper input values sticky from one search to the next. Going back to the original question, a global form handler makes no sense. Input values from different users would get tangled up and overwrite each other, producing incorrect results.
The decision about whether to make any particular component session scoped or create a central session scoped bean is a programming style choice. If you're working in a large development team or you want to build components that are independent of each other, for example because you're building a complex system with more than one module layer, it may be more convenient to keep properties in the components that use them. I'm not aware of a noticeable performance difference between the two styles. The main performance impact to worry about with session scoped components is that they can take up memory for an extended period of time. If you use session scoped components, make sure that all the member variables really need to hang around for the duration of the session.
Resolving (looking up) a component name is a non-trivial operation, as is instantiating a component. Droplets are usually global because it eliminates a lot of name resolution overhead. It's generally safe to make a droplet global because the state information, such as input parameters, is held outside of member variables. Manager and tools components that are part of the ATG platform are global more as a naming convention than anything else. They don't need to store information about one thread or request or session in member variables, which is the requirement for a global component.
As I said in my previous post, "If you're working in a large development team or you want to build components that are independent of each other" it's more convenient not to have a single session bean. Both of those criteria apply to ATG product development. Here are some additional reasons to keep properties in their form handlers:
- By using a separate session bean, every new feature that stored information in the bean would have to touch at least one extra source file (the bean). That's a nuisance for the person editing the files. It also leads to more merge conflicts in the source control system caused by collisions in the session bean file..
- It's a nuisance to have to write getSessionBean.getWhatever instead of getWhatever (and the same for setters) everywhere that touches a property value.
- If there are any properties for which Oracle/ATG or a customer wants to configure a default value, the configuration would have to happen in the session bean rather than the form handler. That's confusing. If one is thinking about a form handler, it's easier to configure the form handler component directly.
- Page code is easier to read if the form input fields mention the same component as the submit button. That would not be the case if sticky values lived in a separate bean.
- Customers who don't want form handler values to be sticky can change the scope of the form handler to request. That would be hard if some of the properties were stored in a separate bean. Note that this reason applies more to the ATG platform than it would to someone building a specific application.
Those are a few reasons off the top of my head. There may be more. I'm not saying there's anything wrong with a separate bean if that's what you prefer.
Nice discussion, Clare. This is really useful.
Can you give us some guidance as to the intended use of the new prototype scope that came into play with release 10.2. I can see where this could be very handy when needing to integrate libraries, API's, etc. provided by or with non-ATG applications. Particularly those whose architecture wasn't devised for web applications and wasn't oriented around the life cycle of a request. But I grow concerned that it could be easily be misused in such a way as to incur tremendous negative scalability impact. Imagine the impact of a request scoped component that was performing a resolveName() in a loop, for example.
So if you could give some guidance on best practice usage, do's and don'ts, the intension for the new scope, that would be +greatly+ appreciated. I'd like to figure out how it fits into the above mentioned discussion of the natural lifecycle duration of request, session, and global scoping. It seems to be a bit orthogonal to the nature of these other scopes.
BTW: What ever happened with Window scope? When that came out years ago in conjunction with CSC, I had thought that it would be a natural for managing the life cycle of tabs within pages. But it seemed to come and go with little fanfare.
Prototype scope was introduced into Nucleus in 10.1.1 to support Endeca's cartridge handlers. Every resolveName call for a prototype scoped component gets a separate instance. Not only are instance variables thread safe, but you also don't need to worry about clearing out or reinitializing them the way you would if you used a request scoped component more than once in the same request. As you suggested, overuse of prototype scope can lead to scalability problems. I don't have quick lists of when you should or should not use prototype scope. If you've never felt the need for something like prototype scope, you probably don't need it now.
A prototype scoped component can be referenced from any other scope. Prototype scoped components follow the same reference rules as the non-prototype scoped components that resolved them. For example, if a global component G refers to a prototype scoped component P, the new instance of P will follow the reference rules for global components, meaning P can refer to global components and other prototype scoped components. The basic idea is that you can't cheat your way through the scoping rules by inserting a prototype scoped component in the reference chain.
Window scope was written for the call center applications, CSC and the Knowledge Management product, and is still used for CSC. Window scope was never documented and supported for custom applications, in part because tremendous care has to be applied to the generation of every link in the application.
Man Clare, that's an amazing response. I hadn't even thought about the inheritance-like nature of the new prototype scope. Just that it made it really easy to bring in non-web oriented libraries for direct exploitation by ATG components, thereby removing the need for a lot of web service calls when direct integration has dramatically better performance, scalability, or reliability.
Thank you so much for taking the time to give such an insightful explanation. I really appreciate it.