By this stage you might be wondering what happens if you need to use more than one handler for your SRF file. Well, ATL Server has been designed to allow you to use as many handlers as you want in any SRF file.
All handlers after the first handler are considered subhandlers. You must list them after the initial handler, before you use any other tags. You denote them similarly to the main handler, except that you use the keyword subhandler instead of handler , and you give each subhandler a name to identify it. To use a method from a subhandler (instead of from the main handler), you must explicitly put the name identifier of the subhandler ( otherwise , the stencil processor will assume that the method is in your main handler). The following example should help clear up any confusion:
<html> <head> Basic SRF </head> {{handler BasicSrf.dll/Example}} {{subhandler Foo BasicSrf2.dll/Example2}} <body> Hello {{World}}<br> Hello {{Foo.World}} </body> </html>
Hopefully this looks fairly straightforward (the syntax is designed to suit C++ developers). It should be clear that you first call the World() method in the Example class in BasicSrf.dll, and then you call the World() method in the Example2 class in BasicSrf2.dll.
There s no reason why a subhandler can t point to the same DLL as the main handler, or to the same handler (in a different DLL), or even to the same handler in the same DLL (although the latter would mean that the subhandler was providing no additional functionality to the main handler).
There s no limit to the number of subhandlers you can use, the only caveat being that each subhandler must have its own unique identifier:
<html> <head> Basic SRF </head> {{handler BasicSrf.dll/Example}} {{subhandler Foo BasicSrf2.dll/Example}} {{subhandler Bar BasicSrf3.dll/Example}} {{subhandler FooBar BasicSrf4.dll/Example}} <body> Hello {{World}}<br> Hello {{Foo.World}}<br> Hello {{Bar.World}}<br> Hello {{FooBar.World}}<br> Hello {{Foo.World}} </body> </html>
The extra subhandlers in the preceding example work just as you would expect.
Subhandlers are very useful for breaking functionality out into generic application DLLs and generic handler classes. Thus, you might have a set of database application DLLs, and you could split these into separate handlers: handlers for reading from the database, handlers for inserting new elements into the database, and handlers for replacing or deleting elements in the database (or any number of similar partitions). Doing so enables you to better reuse code throughout your application.