...
Although you code Tapestry pages and components as if they were ordinary POJOs
![]() Wiki Markup |
{footnote}Plain Old Java Object. Tapestry does not require you to extend any base classes or implement any special interfaces.{footnote}
|
(Plain Old Java Objects -- Tapestry does not require you to extend any base classes or implement any special interfaces), as deployed by Tapestry they are closer to a traditional servlet: a single instance of each page services requests from multiple threads. Behind the scenes, Tapestry transforms you code, rewriting it on the fly.
What this means is that any incoming request must be handled by a single page instance. Therefore, Tapestry enforces the concept of static structure, dynamic behavior.
...
![]() Code Block |
| controls |
true |
| linenumbers |
true |
|
public static void bind(ServiceBinder binder)
{
binder.bind(ArchiveService.class, ArchiveServiceImpl.class);
}
public static JobQueue buildJobQueue(MessageService messageService, Map<String,Job> configuration)
{
JobQueueImpl service = new JobQueueImpl(configuration);
messageService.addQueueListener(service);
return service;
}
|
...
Support for multiple Tapestry applications in the same web application was a specific non-goal in Tapestry 5 (it needlessly complicated Tapestry 4). Given how loosely connected Tapestry 5 pages are from each other, there doesn't seem to be an advantage to doing so ... and certainly, in terms of memory utilization, there is a significant down side, were it even possible.
![]() Wiki Markup |
{scrollbar} |
![]() Wiki Markup |
{display-footnotes}
|
Limitations 