Send the link below via email or IMCopy
Present to your audienceStart remote presentation
- Invited audience members will follow you as you navigate and present
- People invited to a presentation do not need a Prezi account
- This link expires 10 minutes after you close the presentation
- A maximum of 30 users can follow your presentation
- Learn more about this feature in our knowledge base article
Do you really want to delete this prezi?
Neither you, nor the coeditors you shared it with will be able to recover it again.
Make your likes visible on Facebook?
Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.
Transcript of Tapestry 5
CTO at FOUNDD.com @rrrdl https://github.com/criedel/ 2013 2000 T1.0 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 T5.3 T5.2 T5.1 T5.0 T5.4 T4.0 T3.0 Apache Top Level Project New Code Base No XML Convention over configuration! src/main/webapp/WEB-INF/web.xml <context-param>
</filter-mapping> http://localhost:8080/carsharing packages com.example.carsharing.pages com.example.carsharing.components com.example.carsharing.mixins com.example.carsharing.base com.example.carsharing.services com/example/carsharing/pages/*.tml com/example/carsharing/components/*.tml src/main/resources/.. Composition over Inheritance Page Component A Component B Component C Component A Component D Howard Lewis Ship: http://tapestryjava.blogspot.de Tapestry IoC More testable – smaller, simpler classes; coding to interfaces allows use of mock implementations
More robust – smaller, simpler classes; use of final variables; thread safety baked in
More scalable – thread safety baked in
Easier to maintain – less code, simpler classes
Easier to extend – new features are often additions (new services, new contributions) rather than changes to existing classes Modules A module class exists for the following reasons:
To bind service interfaces to service implementations
To contribute configuration data into services
To decorate services by providing interceptors around them
To provide explicit code for building a service
To set a default marker for all services defined in the module
Every service has a very specific life cycle.
Defined: The service has a definition (from some module) but has not yet been referenced.
Virtual: The service has been referenced, so a proxy for the class has been created.
Realized: A method on the proxy has been invoked, so the service implementation has been instantiated, and any decorators applied.
Shutdown: The entire Registry has been shut down and with it, all the proxies have been disabled. Service Life Cycle Configuration There are three different styles of configurations (with matching contributions):
Unordered Collection – Contributions are simply added in and order is not important.
public static void contributeMyService(Configuration<Runnable> configuration)
Ordered List – Contributions are provided as an ordered list. Contributions must establish the order by giving each contributed
object a unique id, by establishing forward and backward dependencies between the values.
public static void contributeStartup(OrderedConfiguration<Runnable> configuration)
Map – Contributions provide unique keys and corresponding values.
MappedConfiguration<String, Runnable> configuration
For mapped configurations where the key type is String, a CaseInsensitiveMap will be automatically used (and passed to the service builder method), to help ensure that case insensitivity is automatic and pervasive. TypeCoercer Type Coercion is the conversion of one type of object to a new object of a different type with similar content. Tapestry frequently must coerce objects from one type to another. A common example is the coercion of a string into an integer or a double. Component Rendering http://tapestry.apache.org/component-rendering.html http://tapestry.apache.org/request-processing.html