[CONF] Apache Tapestry Limitations

2014-03-02 Thread Bob Harner (Confluence)














  


Bob Harner edited the page:
 


Limitations   




 Comment: Added note about running Tap 4  5 apps together 


...
Although you code Tapestry pages and components as if they were ordinary POJOs (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.
...
How do I run multiple Tapestry applications in the same web application?
 This Running multiple Tapestry 5 applications is not supported; there's only one place to identify the application root package, so even configuring multiple filters into multiple folders will not work.
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.
 Youcanrun a Tapestry 4 app and a Tapestry 5 app side-by-side (the package names are different, for just this reason), but they know nothing of each other, and can't interact directly. This is just like the way you could have a single WAR with multiple servlets; the different applications can only communicate via URLs, or shared state in the HttpSession. 



 Wiki Markup




 {scrollbar} 












 View Online   Like   View Changes  
 Stop watching space   Manage Notifications  


 


 


  This message was sent by Atlassian Confluence 5.0.3, Team Collaboration Software  


 

[CONF] Apache Tapestry Limitations

2014-01-18 Thread Bob Harner (Confluence)














  


Bob Harner edited the page:
 


Limitations   




 Comment: Removed broken footnote 


...
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 

[CONF] Apache Tapestry Limitations

2011-09-01 Thread confluence







Limitations
Page edited by Howard M. Lewis Ship


Comment:
add note that multiple t5 apps in one war not supported


 Changes (1)
 




...
{scrollbar}  
 h3. How do I run multiple Tapestry applications in the same web application?  This is not supported; theres only one place to identify the application root package, so even configuring multiple filters into multiple folders will not work.   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 doesnt seem to be an advantage to doing so ... and certainly, in terms of memory utilization, there is a significant down side, were it event possible.  
  {display-footnotes} 


Full Content

Request Processing FAQFrequently Asked QuestionsSpecific Errors FAQ

Limitations

How do I add new components to an existing page dynamically?

The short answer here is: you don't. The long answer here is you don't have to, to get the behavior you desire.

One of Tapestry basic values is high scalability: this is expressed in a number of ways, reflecting scalability concerns within a single server, and within a cluster of servers.

Although you code Tapestry pages and components as if they were ordinary POJOs




1


, 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.

Tapestry provides quite a number of ways to vary what content is rendered, well beyond simple conditionals and loops. It is possible to "drag in" components from other pages when rendering a page (other FAQs will expand on this concept). The point is, that although a Tapestry page's structure is very rigid, the order in which the components of the page render does not have to be top to bottom.


Why doesn't my service implementation reload when I change it?

Main article: Service Implementation Reloading

Live service reloading has some limitations:

	The service must define a service interface.
	The service implementation must be on the file system (not inside a JAR).
	The implementation must be instantiated by Tapestry, not inside code (even code inside a module class).
	The service must use the default scope (reloading of perthread scopes is not supported).



Consider the following example module:



public static void bind(ServiceBinder binder)
{
  binder.bind(ArchiveService.class, ArchiveServiceImpl.class);
}

public static JobQueue buildJobQueue(MessageService messageService, MapString,Job configuration)
{
  JobQueueImpl service = new JobQueueImpl(configuration);

  messageService.addQueueListener(service);
 
  return service;
}



ArchiveService is reloadable, because Tapestry instantiates ArchiveServiceImpl itself.  On the other hand, Tapestry invokes buildJobQueue() and it is your code inside the method that instantiates JobQueueImpl, so the JobQueue service will not be reloadable.

Finally, only classes whose class files are stored directly on the file system, and not packaged inside JARs, are ever reloadable ... generally, only the services of the application being built (and not services from libraries) will be stored on the file system. This reflects the intent of reloading: as an agile development tool, but not something to be used in deployment.

Request Processing FAQFrequently Asked QuestionsSpecific Errors FAQ


How do I run multiple Tapestry applications in the same web application?

This is not supported; there's only one place to identify the application root package, so even configuring multiple filters into multiple folders will not work. 

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 event possible.



  Footnotes
  

  Reference
  Notes

  
  

  

1

  
  
  Plain Old Java Object. Tapestry does not require you to extend any base classes or implement any special interfaces.
  

  




Change Notification Preferences

View Online
|
View Changes