Hi This is copy/paste from initial documentation. I am currently focusing on documentation organization, feel free to fix it or fill a jira. Anyway, documentation rework is the 'big next step'
2010/10/4 Josh Canfield <[email protected]>: > Principle 1 – Static Structure, Dynamic Behavior > "most importantly because Tapestry pages are pooled." > > Since pages are no longer pooled this section needs a rewrite... I'm > ok with making typo fixes, but I'm not a technical writer so > re-buidling the most important part of a core principle is out of my > depth... > > Should this be filed in Jira? > > Josh > > On Mon, Oct 4, 2010 at 4:21 AM, <[email protected]> wrote: >> Principles >> >> Page added by Christophe Cordenier >> >> What is Apache Tapestry? >> >> Apache Tapestry is an open-source framework for creating dynamic, robust, >> highly scalable web applications in Java. Tapestry complements and builds >> upon the standard Java Servlet API, and so it works in any servlet container >> or application server. >> >> Tapestry divides a web application into a set of pages, each constructed >> from components. This provides a consistent structure, allowing the Tapestry >> framework to assume responsibility for key concerns such as URL construction >> and dispatch, persistent state storage on the client or on the server, user >> input validation, localization/internationalization, and exception >> reporting. Developing Tapestry applications involves creating HTML templates >> using plain HTML, and combining the templates with small amounts of Java >> code. In Tapestry, you create your application in terms of objects, and the >> methods and properties of those objects – and specifically not in terms of >> URLs and query parameters. Tapestry brings true object oriented development >> to Java web applications. >> >> Tapestry is specifically designed to make creating new components very easy, >> as this is a routine approach when building applications. >> >> Tapestry is architected to scale from tiny, single-page applications all the >> way up to massive applications consisting of hundreds of individual pages, >> developed by large, diverse teams. Tapestry easily integrates with any kind >> of backend, including JEE, Spring and Hibernate. >> >> It's more than what you can do with Tapestry ... it's also how you do it! >> Tapestry is a vastly productive environment. Java developers love it because >> they can make Java code changes and see them immediately ... no redeploy, no >> restart! And it's blazingly fast to boot (even when files change). Designers >> love it because Tapestry templates are so close to ordinary HTML, without >> all the cruft and confusion seen in JavaServer Pages. Managers love it >> because it makes it easy for large teams to work together, and because they >> know important features (including localization) are baked right in. Once >> you work in Tapestry there's no going back! >> >> Tapestry is released under the Apache Software Licence 2.0. >> >> Principle 1 – Static Structure, Dynamic Behavior >> >> Tapestry is designed to be extremely scalable in several dimensions: >> >> Tapestry applications may contain large numbers of pages and many custom >> components. >> Tapestry applications may contain very complex functionality. >> Tapestry applications may be created by large, diverse teams. >> Tapestry applications can service large numbers of concurrent users. >> >> One core architecture decision in Tapestry exists to service many of the >> above goals (and others that are harder to describe). Static Structure, >> Dynamic Behavior >> >> In Tapestry, the structure of any particular page is static. This is >> necessary for several reasons, most importantly because Tapestry pages are >> pooled. Creating a Tapestry page is an involved process, because the page >> object is simply the root of a large tree of other objects including user >> provided components, many kinds of structural objects, template objects, and >> others. Creating a new page instance for each request is simply not >> scalable. >> >> Instead, Tapestry pools pages. Once created, a page instance will be stored >> in a pool for that particular type of page, and reused in later requests. An >> incoming request, the result of a user clicking a link or submitting a form, >> will be processed by some server within a cluster, and will use some page >> instance within the page pool. Because page instances are static and uniform >> across instances and servers, Tapestry can use any available page instance, >> or create a new one as needed. >> >> Tapestry does not need to store page instances inside the HttpSession. At >> most, it stores a smattering of persistent field values from the page, but >> not the entire page instance. This lean use of the HttpSession is key to >> Tapestry's very high scalability, especially in a clustered configuration. >> >> In some Tapestry-like frameworks, such as Faces and Wicket, the page >> structure is more dynamic, at the cost of storing much, much more data in >> the HttpSession. >> >> This static structure is not so limiting as you might think. With different >> kinds of conditional and looping components, and the ability to "jump out of >> the flow" and render components in an arbitrary order, you will not find >> Tapestry to be rigid ... anything but! >> >> Principle 2 – Adaptive API >> >> A key feature of Tapestry 5 is adaptive API. >> >> In traditional Java frameworks, including Tapestry 4, user code is expected >> to conform to the framework. You create classes that extend from >> framework-provided base classes, or implement framework-provided interfaces. >> >> This works well until you upgrade to the next release of the framework: with >> the new features of the upgrade, you will more often than not experience >> breaks in backwards compatibility. Interfaces or base classes will have >> changed and your existing code will need to be changed to match. >> >> In Tapestry 5, the framework adapts to your code. You have control over the >> names of the methods, the parameters they take, and the value that is >> returned. This is driven by annotations, which tell Tapestry under what >> circumstances your methods are to be invoked. >> >> For example, you may have a login form and have a method that gets invoked >> when the form is submitted: >> >> public class Login >> { >> @Persist >> @Property >> private String userId; >> >> @Property >> private String password; >> >> @Component >> private Form form; >> >> @Inject >> private LoginAuthenticator authenticator; >> >> void onValidateForm() >> { >> if (! authenticator.isValidLogin(userId, password)) >> { >> form.recordError("Invalid user name or password."); >> } >> } >> >> Object onSuccess() >> { >> return PostLogin.class; >> } >> } >> >> This short snippet demonstrates a bit about how Tapestry operates. Pages and >> services within the application are injected with the @Inject annotation. >> The method names, onValidateForm() and onSuccess(), inform Tapestry about >> when the method is to be invoked. The two events validateForm and success >> occur when a form is submitted; "validateForm" is triggered to perform >> cross-field validations, and "success" is only triggered when there are no >> validation errors. The onSuccess() method's return value directs Tapestry on >> what to do next: jump to another page within the application (here >> identified as the class for the page, but many other options exist). When >> there are exceptions, the page will be redisplayed to the user. >> >> This also represents a distinct change from Tapestry 4. In earlier versions >> of Tapestry, the Form component's listener parameter would be bound to the >> method to invoke, by name. Further, the listener method had to be public. >> This new approach not only support multiple listeners, but provides an >> improved separation of view concerns (inside the page's HTML template) and >> logic concerns, inside the Java class. >> >> In many cases, additional information about the event is available, and can >> be passed into the method by adding parameters to the method. Again, >> Tapestry will adapt to your parameters, in whatever order you supply them. >> >> Tapestry also saves you effort: the @Property annotation marks a field as >> readable and writable; Tapestry will provide the accessor methods >> automatically. >> >> Finally, Tapestry 5 explicitly separates actions (requests that change >> things) and rendering (requests that render pages) into two separate >> requests. Performing an action, such as clicking a link or submitting a >> form, results in a client side redirect to the new page. This is often >> called "redirect after post". This helps ensure that URLs in the browser are >> book-markable ... but also requires that a bit more information be stored in >> the session between requests (using the @Persist annotation). >> >> Principle 3 – Public vs. Internal >> >> An issue plaguing previous versions of Tapestry 4 (and earlier) was the lack >> of a clear delineator between private, internal APIs and public, external >> APIs. The fact that your code would extend from base objects but that many >> of the methods on those base objects were "off limits" further confused the >> issue. This has been identified as a key factor in the "steep learning curve >> of Tapestry" meme. >> >> With the clean slate of Tapestry 5, we are being much more ruthless about >> internal vs. external. >> >> First of all, anything inside the org.apache.tapestry5.internal package is >> internal. It is part of the implementation of Tapestry. It is the man behind >> the curtain. You should not ever need to directly use this code. It is a bad >> idea to do so, because internal code may change from one release to the next >> without concern for backwards compatibility. >> >> Principle 4 – Backwards Compatibility >> >> Tapestry has been plagued by backwards compatibility problems with every >> major release. Tapestry 5 does not even attempt to be backwards compatible >> to Tapestry 4. Instead, it lays the ground work for true backwards >> compatibility going forwards. >> >> Tapestry 5's API is based almost entirely on naming conventions and >> annotations. You components are just ordinary Java classes; you will >> annotate fields to allow Tapestry to maintain their state or to allow >> Tapestry to inject resources, and you will name (or annotate) methods to >> tell Tapestry under what circumstances a method should be invoked. >> >> Tapestry will adapt to your classes. It will call your methods, passing in >> values via method parameters. Instead of the rigidness of a fixed interface >> to implement, Tapestry will simply adapt to your classes, using the hints >> provided by annotations and simple naming conventions. >> >> Because of this, Tapestry will be able to change internally to a great >> degree without it affecting any of the application code you write. This >> should finally crack the backwards compatibility nut, allowing you to have >> great assurance that you can upgrade to future releases of Tapestry without >> breaking your existing applications. >> >> This is already evident in Tapestry 5.1, where many new features and >> improvements have occurred, but is still 100% backwards compatible to >> Tapestry 5.0, as long as you've avoided the temptation to make use of >> internal APIs. >> >> Change Notification Preferences >> View Online > > > > -- > -- > http://www.bodylabgym.com - a private, by appointment only, one-on-one > health and fitness facility. > -- > http://www.ectransition.com - Quality Electronic Cigarettes at a > reasonable price! > -- > TheDailyTube.com. Sign up and get the best new videos on the internet > delivered fresh to your inbox. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- Regards, Christophe Cordenier. Committer on Apache Tapestry 5 Co-creator of wooki @wookicentral.com --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
