You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@tapestry.apache.org by hl...@apache.org on 2007/01/20 16:25:33 UTC
svn commit: r498124 - in
/tapestry/tapestry5/tapestry-project/trunk/src/site/resources:
tap5devwiki.html tap5devwiki.xml
Author: hlship
Date: Sat Jan 20 07:25:32 2007
New Revision: 498124
URL: http://svn.apache.org/viewvc?view=rev&rev=498124
Log:
More thoughts into the wiki.
Modified:
tapestry/tapestry5/tapestry-project/trunk/src/site/resources/tap5devwiki.html
tapestry/tapestry5/tapestry-project/trunk/src/site/resources/tap5devwiki.xml
Modified: tapestry/tapestry5/tapestry-project/trunk/src/site/resources/tap5devwiki.html
URL: http://svn.apache.org/viewvc/tapestry/tapestry5/tapestry-project/trunk/src/site/resources/tap5devwiki.html?view=diff&rev=498124&r1=498123&r2=498124
==============================================================================
--- tapestry/tapestry5/tapestry-project/trunk/src/site/resources/tap5devwiki.html (original)
+++ tapestry/tapestry5/tapestry-project/trunk/src/site/resources/tap5devwiki.html Sat Jan 20 07:25:32 2007
@@ -5183,13 +5183,15 @@
<div tiddler="InvisibleInstrumentation" modifier="HowardLewisShip" modified="200610201803" created="200610201802" tags="">A feature of Tapestry 4 where the component id, type and parameters were "hidden" inside ordinary HTML tags.\n\nThis will show up inside Tapestry 5 pretty soon, and look something like:\n{{{\n<span t:type="If" t:test="prop:showWarning" class="warning"> \n . . .\n</span>\n}}}</div>
<div tiddler="LogicalPageName" modifier="HowardLewisShip" modified="200610081330" created="200610081330" tags="">A logical page name is the name of a page as it is represented in a URI.\n\nInternally, Tapestry operates on pages using full qualified class names. Technically, the FQCN is the class of the page's root element, but from an end developer point of view, the root element is the page.\n\nThe logical page name must be converted to a fully qualified class name.\n\nA set of LibraryMappings are used. Each library mapping is used to express a folder name, such as "core", with a Java package name, such as org.apache.tapestry.corelib. For pages, the page name is searched for in the pages sub-package (i.e., org.apache.tapestry.corelib.pages). Component libraries have unique folder names mapped to root packages that contain the pages (and components, and mixins) of that library.\n\nWhen there is no folder name, the page is expected to be part of the application,
under the pages sub-package of the application's root package.\n\nIf not found there, as a special case, the name is treated as if it were prefixed with "core/". This allows access to the core pages (and more importantly, components -- the search algorithm is the same).\n\nFinally, pages may be organized into folders. These folders become further sub-packages. Thus as page name of "admin/EditUsers" may be resolved to class org.example.myapp.pages.admin.EditUsers.\n\n</div>
<div tiddler="MainMenu" modifier="HowardLewisShip" modified="200609210701" created="200609210643" tags="">MasterIndex\n[[RSS feed|tap5devwiki.xml]]\n\n[[Tapestry 5 Home|http://tapestry.apache.org/tapestry5/]]\n[[Howard's Blog|http://howardlewisship.com/blog/]]\n\n[[Formatting Help|http://www.blogjones.com/TiddlyWikiTutorial.html#EasyToEdit%20Welcome%20NewFeatures%20WhereToFindHelp]]</div>
-<div tiddler="MasterIndex" modifier="HowardLewisShip" modified="200701161448" created="200609202214" tags="">Top level concepts within Tapestry 5.\n\nA //meta-note//: This is where new ideas are first explained, usually before being implemented. In many cases, the final implementation is\nnot a perfect match for the notes. That's OK ... as long as the official Maven documentation does a good job. It's not reasonable to expect developers to jump back in here and dot every i and cross every t if they're already expected to generate good Maven documentation.\n\n* PropBinding -- Notes on the workhorse "prop:" binding prefix\n* TypeCoercion -- How Tapestry 5 extensibly addresses type conversion\n* FormProcessing\n* DynamicPageState -- tracking changes to page state during the render\n* EnvironmentalServices -- how components cooperate during page render\n* ComponentMixins -- A new fundamental way to build web functionality\n* RequestTypes -- Requests, request processing
, URL formats\n* ComponentTemplates -- Issues about Component Templates\n* DeveloperProcedures -- Your a Tapestry committer ... how do you makes changes?\n* SmartDefaults -- do even more with event less\n* RandomIdeas -- stuff that doesn't fit elsewhere\n* ProblemsNeedingSolutions\n* ComponentDocumentation -- Generating Documentation about Components\n* TapestryLookAndFeel -- Default CSS\n* [[Assets]]\n* CaseInsensitivity -- case in URLs should not matter\n* FullReload -- Why limit reloading to just components?\n\n</div>
+<div tiddler="MasterIndex" modifier="HowardLewisShip" modified="200701201404" created="200609202214" tags="">Top level concepts within Tapestry 5.\n\nA //meta-note//: This is where new ideas are first explained, usually before being implemented. In many cases, the final implementation is\nnot a perfect match for the notes. That's OK ... as long as the official Maven documentation does a good job. It's not reasonable to expect developers to jump back in here and dot every i and cross every t if they're already expected to generate good Maven documentation.\n\n* PropBinding -- Notes on the workhorse "prop:" binding prefix\n* TypeCoercion -- How Tapestry 5 extensibly addresses type conversion\n* FormProcessing\n* DynamicPageState -- tracking changes to page state during the render\n* EnvironmentalServices -- how components cooperate during page render\n* ComponentMixins -- A new fundamental way to build web functionality\n* RequestTypes -- Requests, request processing
, URL formats\n* ComponentTemplates -- Issues about Component Templates\n* DeveloperProcedures -- Your a Tapestry committer ... how do you makes changes?\n* SmartDefaults -- do even more with event less\n* RandomIdeas -- stuff that doesn't fit elsewhere\n* ProblemsNeedingSolutions\n* ComponentDocumentation -- Generating Documentation about Components\n* TapestryLookAndFeel -- Default CSS\n* [[Assets]]\n* CaseInsensitivity -- case in URLs should not matter\n* FullReload -- Why limit reloading to just components?\n* RelativeURLs -- rendered links should be short and relative to the base URL\n* SecureClientState -- securing state stored on the client\n\n\n</div>
<div tiddler="OGNL" modifier="HowardLewisShip" modified="200610071249" created="200609202254" tags="">The [[Object Graph Navigation Library|http://ognl.org]] was an essential part of Tapestry 4.\n\nOGNL is both exceptionally powerful (especially the higher order things it can do, such as list selections and projections). However, for the highest\nend sites, it is also a performance problem, both because of its heavy use of reflection, and because it uses a lot of code inside synchronized blocks.\n\nIt will be optional in Tapestry 5. I believe it will not be part of the tapestry-core, but may be packaged as tapestry-ognl.\n\nThe "prop:" binding prefix is an effective replacement for OGNL in Tapestry 5. See PropBinding.\n</div>
-<div tiddler="PageRenderRequest" modifier="HowardLewisShip" modified="200610081333" created="200610071313" tags="">Page render requests are requests used to render a specific page. //render// is the term meaning to compose the HTML response to be sent to the client. Note: HTML is used here only as the most common case, other markups are entirely possible.\n\nIn many cases, pages are stand-alone. No extra information in the URL is necesarry to render them. PersistentProperties of the page will factor in to the rendering of the page.\n\nIn specific cases, a page needs to render within a particular context. The most common example of this is a page that is used to present a specific instance of a database persistent entity. In such a case, the page must be combined with additional data, in the URL, to identify the specific entity to access and render.\n\n! URI Format\n\n{{{\n/page-name.html/id\n}}}\n\nHere "page-name" is the LogicalPageName for the page. \n\nThe &q
uot;.html" file extension is used as a delimiter between the page name portion of the URI, and the context portion of the URI. This is necessary because it is not possible (given the plethora of libraries and folders) to determine how many slashes will appear in the URI.\n\nThe context consists of one ore more ids (though a single id is the normal case). The id is used to identify the specific data to be displayed. Further, a page may require multiple ids, which will separated with slashes. Example: /admin/DisplayDetail.html/loginfailures/2006\n\nNote that these context values, the ids, are simply //strings//. Tapestry 4 had a mechanism, the DataSqueezer, that would encode the type of object with its value, as a single string, and convert it back. While seemingly desirable, this facility was easy to abuse, resulting in long and extremely ugly URIs.\n\nAny further information needed by Tapestry will be added to the URI as query parameters. This may include things like us
er locale, persistent page properties, applicaition flow identifiers, or anything else we come up with.\n\n! Request Processing\n\nOnce the page and id parameters are identified, the corresponding page will be loaded.\n\nTapestry will fire two events before rendering the page.\n\nThe first event is of type "setupPageRender". This allows the page to process the context (the set of ids). This typically involves reading objects from an external persistent store (a database)\nand storing those objects into transient page properties, in expectaion of the render.\n\nThe @SetupPageRender annotation marks a method to be invoked when this event is triggered. The method may take one or more strings, or an array of strings, as parameters; these will be\nthe context values. The method will normally return void. Other values are ''TBD''. It may also take other simple types, which will be coerced from the string values.\n\n{{{\n@SetupPageRender\nvoid setup(long id)\n{\n . .
.\n}\n}}}\n\n\n\nThe second event is of type "pageValidate". It allows the page to decide whether the page is valid for rendering at this time. This most often involves a check to see if the user is logged into the application, and has the necessary privileges to display the contents of the page. User identity and privileges are //not// concepts built into Tapestry, but are fundamental to the majority of Tapestry applications.</div>
+<div tiddler="PageRenderRequest" modifier="HowardLewisShip" modified="200701201348" created="200610071313" tags="">Page render requests are requests used to render a specific page. //render// is the term meaning to compose the HTML response to be sent to the client. Note: HTML is used here only as the most common case, other markups are entirely possible.\n\nIn many cases, pages are stand-alone. No extra information in the URL is necesarry to render them. PersistentProperties of the page will factor in to the rendering of the page.\n\nIn specific cases, a page needs to render within a particular context. The most common example of this is a page that is used to present a specific instance of a database persistent entity. In such a case, the page must be combined with additional data, in the URL, to identify the specific entity to access and render.\n\n! URI Format\n\n{{{\n/page-name.html/id\n}}}\n\nHere "page-name" is the LogicalPageName for the page. \n\nThe &q
uot;.html" file extension is used as a delimiter between the page name portion of the URI, and the context portion of the URI. This is necessary because it is not possible (given the plethora of libraries and folders) to determine how many slashes will appear in the URI.\n\nThe context consists of one ore more ids (though a single id is the normal case). The id is used to identify the specific data to be displayed. Further, a page may require multiple ids, which will separated with slashes. Example: /admin/DisplayDetail.html/loginfailures/2006\n\nNote that these context values, the ids, are simply //strings//. Tapestry 4 had a mechanism, the DataSqueezer, that would encode the type of object with its value, as a single string, and convert it back. While seemingly desirable, this facility was easy to abuse, resulting in long and extremely ugly URIs.\n\nAny further information needed by Tapestry will be added to the URI as query parameters. This may include things like us
er locale, persistent page properties, applicaition flow identifiers, or anything else we come up with.\n\n! Request Processing\n\nOnce the page and id parameters are identified, the corresponding page will be loaded.\n\nTapestry will fire two events before rendering the page.\n\nThe first event is of type "activate". This allows the page to process the context (the set of ids). This typically involves reading objects from an external persistent store (a database)\nand storing those objects into transient page properties, in expectaion of the render.\n\nThis has been implemented, see the reference documentation for more details on passivate/activate.\n</div>
<div tiddler="ProblemsNeedingSolutions" modifier="HowardLewisShip" modified="200701032351" created="200611230401" tags="">There are a few things that I'm concerned about.\n\n!Render Complexity\n\nAll those states in the render component state machine may be a little much, especially ~PreBeginRender, ~BeginRender and ~PostBeginRender. In addition, it doesn't work for a case I'm interested in ... for link components, I'd like to use the RenderInformals mixin, but also support a disable parameter that turns off the <a> tag (but still renders the body). The state machine currently is set up so that returning false in any of the ~BeginRender states skips all the way to ~AfterRender, bypassing the template and/or body.\n\nStill don't have a perfect solution for the above (it may not be solvable via mixins, which may show limitations in the component/mixin model). I have added a @MixinAfter annotation which simplifies the state machine somewhat.</div>
<div tiddler="PropBinding" modifier="HowardLewisShip" modified="200610201450" created="200609202203" tags="bindings">The "prop:" binding prefix is the default in a lot of cases, i.e., in any Java code (annotations).\n\nThis binding prefix supports several common idioms even though they are not, precisely, the names of properties. In many cases, this will save developers the bother of using a "literal:" prefix.\n\nThe goal of the "prop:" prefix is to be highly efficient and useful in 90%+ of the cases. [[OGNL]], or synthetic properties in the component class, will pick up the remaining cases.\n\n!Numeric literals\n\nSimple numeric literals should be parsed into read-only, invariant bindings.\n{{{\nprop:5\n\nprop:-22.7\n}}}\n\nThe resulting objects will be of type Long or type Double. TypeCoercion will ensure that component parameters get values (say, int or float) of the correct type.\n\n!Range literals\n\nExpresses a range of integer values,
either ascending or descending.\n{{{\nprop:1..10\n\nprop:100..-100\n}}}\n\nThe value of such a binding is Iterable; it can be used by the Loop component.\n\n!Boolean literals\n\n"true" and "false" should also be converted to invariant bindings.\n{{{\nprop:true\n\nprop:false\n}}}\n\n!String literals\n\n//Simple// string literals, enclosed in single quotes. Example:\n{{{\nprop:'Hello World'\n}}}\n\n//Remember that the binding expression will always be enclosed in double quotes.//\n\n!This literal\n\nIn some cases, it is useful to be able to identify the current component:\n{{{\nprop:this\n}}}\n\nEven though a component is not immutable, the value of //this// does not ever change,\nand this binding is also invariant.\n\n!Null literal\n\n{{{\nprop:null\n}}}\n\nThis value is always exactly null. This can be used to set a parameter who'se default value is non-null to the explicit value null.\n\n!Property paths\n\nMulti-step property paths are extremely importa
nt.\n\n{{{\nprop:poll.title\n\nprop:identity.user.name\n}}}\n\nThe initial terms need to be readable, they are never updated. Only the final property name must be read/write, and in fact, it is valid to be read-only or write-only.\n\nThe prop: binding factory builds a Java expression to read and update properties. It does not use reflection at runtime. Therefore, the properties of the //declared// type are used. By contrast, [[OGNL]] uses the //actual// type, which is reflection-intensive. Also, unlike OGNL, errors (such as missing properties in the property path) are identified when the page is loaded, rather than when the expression is evaluated.\n</div>
<div tiddler="RandomIdeas" modifier="HowardLewisShip" modified="200701032346" created="200611040039" tags="">!HTML / XHTML DTDs\n\nThe template parser should include local (in JAR) copies of the HTML and XHTML DTDs and redirect the parser to use the local copies. This can be a huge performance boost when parsing a template.\n\n!final should imply @Retain\n\nFinal fields should be treated as if they have the @Retain annotation\n\n! Exceptions from event handler / phase render methods\n\nTapestry should wrap non-runtime exceptions from these methods. I think today, if you declare that such a method throws an exception, you'll get a runtime exception out of Javassist.\n\n! SubForms\n\nPerhaps one way to approach highly dynamic, Ajax pages with forms is to have a logical "sub form" concept. A sub form would work inside an existing form, and organize a group of fields within that form. Processing of the fields would occur only if the sub form was active, which itself\nw
ould be tracked based on visibility of the sub form (a sub form in an invisible panel would not be processed on the server side). This idea needs a lot of fleshing out, even to see if it is viable.\n\n! Ajax Constraints\n\nThe best way to tackle Ajax features, especially w.r.t. forms, is to put some sensible constraints on what the user can do, then make it easy to implement those things.\n\nBasically ... never delete! Deletions are a real pain to handle, unless I suddenly get much smarter. Allow things to be hidden on the client side,\nand for the corresponding fields to do nothing on the server side, but don't allow them to full out delete. \n\nAllow new things to be added, preferable only at the "tail end" of the form. \n\n! SPI Package\n\nA number of interfaces, such as Binding, probably belong in a SPI (Service Provider Interface) package, since they will generally only be used by authors of Tapestry extensions. Perhaps we should just use the oat.services
package as the SPI package?\n\n! Deducing Component Types\n\nSeems to me that a <form> element with a t:id should be a Form component. Likewise, <input type="text" t:id="foo"/> should be a TextField component. A basic set of rules, via a configuration, could allow for a number of cases (mostly related to input controls) to //do the right thing//.</div>
+<div tiddler="RelativeURLs" modifier="HowardLewisShip" modified="200701201403" created="200701201403" tags="">Currently, in T4, when Tapestry creates a URL to an asset, or to an action or page, it generates a complete URI (that is, the URL with the scheme and hostname portion stripped off).\n\nHowever, Tapestry could quite reasonably, compare the request's base URL to the URI for the link, and shorten it from an absolute path to a relative path.\n\nFor instance, when rendering /context/admin/AdminMenu.html, a link to /context/images/admin/border.png could ultimately show up in the HTML as ../../images/admin/border.png.\n\nThis would be especially handy for action events; /context/admin/AdminMenu.action/form would be rendered out as just AdminMenu.action/form.</div>
<div tiddler="RequestTypes" modifier="HowardLewisShip" modified="200610081334" created="200610071243" tags="request">There are three broad categories of user requests (requests from the client web browser):\n\n* PageRenderRequest -- requests to render a specific page, possibly with some configuration\n* ComponentActionRequest -- requests that trigger behaivor within a specific component\n* ResourceRequest -- requests that access a resource file within the classpath\n\nEach of these requests has a specific URI format.</div>
+<div tiddler="SecureClientState" modifier="HowardLewisShip" modified="200701201420" created="200701201420" tags="request state">In several places, including form submissions, Tapestry stores serialized object data on the client.\n\nThe basic process for this is to serialize the data to a bytestream, compress the bytestream using GZip, then encode the compressed bytestream using MIME BASE64 encoding.\n\nLater, the process is reversed.\n\nThis is a powerful approach, but introduces two concerns:\n\n* The MIME encoded string can become quite large (especially for very large and complex forms). This may impact the use of GET request for forms (where that would be appropriate, such as a search form), and may also prevent applications from executing well on limited platforms such as cell phones and PDAs.\n\n* A sufficiently clever "black hat" hacker could hijack the serialized bytestream and substitute different serialized objects, towards some kind of mischief.\n\nAn a
pproach to be explored (possibly using an add-in module) would be to store the serialized data on the server, in a flat file or embedded database.\n\nOnly an identifier for the serialized data would be sent to the client.\n\nThe identifier would be "salted" with the user's session id (if available) or perhaps the user's IP address (if no session exists). Or we would force the creation of a session.\n\nThese ideas raise some new concerns related to clustering, especially if sticky sessions are not used.\n\n\nIn my opinion, it is highly unlikely that any significant compromise could be accomplished in this way.</div>
<div tiddler="SideBarTabs" modifier="HowardLewisShip" modified="200609210652" created="200609210651" tags=""><<tabs txtMainTab Timeline Timeline TabTimeline All 'All tiddlers' TabAll Tags 'All tags' TabTags More 'More lists' TabMore>>\n</div>
<div tiddler="SiteSubtitle" modifier="HowardLewisShip" modified="200609202249" created="200609202155" tags="">\nThe quick and dirty one-stop shopping of random ideas for Tapestry 5.</div>
<div tiddler="SiteTitle" modifier="HowardLewisShip" modified="200609202249" created="200609202155" tags="">Tapestry 5 Brain Dump</div>
Modified: tapestry/tapestry5/tapestry-project/trunk/src/site/resources/tap5devwiki.xml
URL: http://svn.apache.org/viewvc/tapestry/tapestry5/tapestry-project/trunk/src/site/resources/tap5devwiki.xml?view=diff&rev=498124&r1=498123&r2=498124
==============================================================================
--- tapestry/tapestry5/tapestry-project/trunk/src/site/resources/tap5devwiki.xml (original)
+++ tapestry/tapestry5/tapestry-project/trunk/src/site/resources/tap5devwiki.xml Sat Jan 20 07:25:32 2007
@@ -6,21 +6,41 @@
<description>The quick and dirty one-stop shopping of random ideas for Tapestry 5.</description>
<language>en-us</language>
<copyright>Copyright 2007 HowardLewisShip</copyright>
-<pubDate>Tue, 16 Jan 2007 14:51:05 GMT</pubDate>
-<lastBuildDate>Tue, 16 Jan 2007 14:51:05 GMT</lastBuildDate>
+<pubDate>Sat, 20 Jan 2007 14:20:06 GMT</pubDate>
+<lastBuildDate>Sat, 20 Jan 2007 14:20:06 GMT</lastBuildDate>
<docs>http://blogs.law.harvard.edu/tech/rss</docs>
<generator>TiddlyWiki 2.0.11</generator>
<item>
-<title>FullReload</title>
-<description>It has occured to me that by adding yet another smart class loader, we could possibly set up a system where we track date time modified on all the modules, service interfaces, and implementation files loaded by the Registry, such that changes to any of the files could result in a kind of "soft reload", where we reload the changed files and construct and use a new Registry.</description>
-<link>http://tapestry.apache.org/tapestry5/tap5devwiki.html#FullReload</link>
-<pubDate>Tue, 16 Jan 2007 14:50:26 GMT</pubDate>
+<title>SecureClientState</title>
+<description>In several places, including form submissions, Tapestry stores serialized object data on the client.<br /><br />The basic process for this is to serialize the data to a bytestream, compress the bytestream using GZip, then encode the compressed bytestream using MIME BASE64 encoding.<br /><br />Later, the process is reversed.<br /><br />This is a powerful approach, but introduces two concerns:<br /><br />* The MIME encoded string can become quite large (especially for very large and complex forms). This may impact the use of GET request for forms (where that would be appropriate, such as a search form), and may also prevent applications from executing well on limited platforms such as cell phones and PDAs.<br /><br />* A sufficiently clever "black hat" hacker could hijack the serialized bytestream and substitute different serialized objects, towards some kind of mischief.<br /><br />
;An approach to be explored (possibly using an add-in module) would be to store the serialized data on the server, in a flat file or embedded database.<br /><br />Only an identifier for the serialized data would be sent to the client.<br /><br />The identifier would be "salted" with the user's session id (if available) or perhaps the user's IP address (if no session exists). Or we would force the creation of a session.<br /><br />These ideas raise some new concerns related to clustering, especially if sticky sessions are not used.<br /><br /><br />In my opinion, it is highly unlikely that any significant compromise could be accomplished in this way.</description>
+<category>request</category>
+<category>state</category>
+<link>http://tapestry.apache.org/tapestry5/tap5devwiki.html#SecureClientState</link>
+<pubDate>Sat, 20 Jan 2007 14:20:06 GMT</pubDate>
</item>
<item>
<title>MasterIndex</title>
-<description>Top level concepts within Tapestry 5.<br /><br />A //meta-note//: This is where new ideas are first explained, usually before being implemented. In many cases, the final implementation is<br />not a perfect match for the notes. That's OK ... as long as the official Maven documentation does a good job. It's not reasonable to expect developers to jump back in here and dot every i and cross every t if they're already expected to generate good Maven documentation.<br /><br />* PropBinding -- Notes on the workhorse "prop:" binding prefix<br />* TypeCoercion -- How Tapestry 5 extensibly addresses type conversion<br />* FormProcessing<br />* DynamicPageState -- tracking changes to page state during the render<br />* EnvironmentalServices -- how components cooperate during page render<br />* ComponentMixins -- A new fundamental way to build web functionality<br />* RequestTypes -- Requests, requ
est processing, URL formats<br />* ComponentTemplates -- Issues about Component Templates<br />* DeveloperProcedures -- Your a Tapestry committer ... how do you makes changes?<br />* SmartDefaults -- do even more with event less<br />* RandomIdeas -- stuff that doesn't fit elsewhere<br />* ProblemsNeedingSolutions<br />* ComponentDocumentation -- Generating Documentation about Components<br />* TapestryLookAndFeel -- Default CSS<br />* [[Assets]]<br />* CaseInsensitivity -- case in URLs should not matter<br />* FullReload -- Why limit reloading to just components?<br /><br /></description>
+<description>Top level concepts within Tapestry 5.<br /><br />A //meta-note//: This is where new ideas are first explained, usually before being implemented. In many cases, the final implementation is<br />not a perfect match for the notes. That's OK ... as long as the official Maven documentation does a good job. It's not reasonable to expect developers to jump back in here and dot every i and cross every t if they're already expected to generate good Maven documentation.<br /><br />* PropBinding -- Notes on the workhorse "prop:" binding prefix<br />* TypeCoercion -- How Tapestry 5 extensibly addresses type conversion<br />* FormProcessing<br />* DynamicPageState -- tracking changes to page state during the render<br />* EnvironmentalServices -- how components cooperate during page render<br />* ComponentMixins -- A new fundamental way to build web functionality<br />* RequestTypes -- Requests, requ
est processing, URL formats<br />* ComponentTemplates -- Issues about Component Templates<br />* DeveloperProcedures -- Your a Tapestry committer ... how do you makes changes?<br />* SmartDefaults -- do even more with event less<br />* RandomIdeas -- stuff that doesn't fit elsewhere<br />* ProblemsNeedingSolutions<br />* ComponentDocumentation -- Generating Documentation about Components<br />* TapestryLookAndFeel -- Default CSS<br />* [[Assets]]<br />* CaseInsensitivity -- case in URLs should not matter<br />* FullReload -- Why limit reloading to just components?<br />* RelativeURLs -- rendered links should be short and relative to the base URL<br />* SecureClientState -- securing state stored on the client<br /><br /><br /></description>
<link>http://tapestry.apache.org/tapestry5/tap5devwiki.html#MasterIndex</link>
-<pubDate>Tue, 16 Jan 2007 14:48:59 GMT</pubDate>
+<pubDate>Sat, 20 Jan 2007 14:04:15 GMT</pubDate>
+</item>
+<item>
+<title>RelativeURLs</title>
+<description>Currently, in T4, when Tapestry creates a URL to an asset, or to an action or page, it generates a complete URI (that is, the URL with the scheme and hostname portion stripped off).<br /><br />However, Tapestry could quite reasonably, compare the request's base URL to the URI for the link, and shorten it from an absolute path to a relative path.<br /><br />For instance, when rendering /context/admin/AdminMenu.html, a link to /context/images/admin/border.png could ultimately show up in the HTML as ../../images/admin/border.png.<br /><br />This would be especially handy for action events; /context/admin/AdminMenu.action/form would be rendered out as just AdminMenu.action/form.</description>
+<link>http://tapestry.apache.org/tapestry5/tap5devwiki.html#RelativeURLs</link>
+<pubDate>Sat, 20 Jan 2007 14:03:43 GMT</pubDate>
+</item>
+<item>
+<title>PageRenderRequest</title>
+<description>Page render requests are requests used to render a specific page. //render// is the term meaning to compose the HTML response to be sent to the client. Note: HTML is used here only as the most common case, other markups are entirely possible.<br /><br />In many cases, pages are stand-alone. No extra information in the URL is necesarry to render them. PersistentProperties of the page will factor in to the rendering of the page.<br /><br />In specific cases, a page needs to render within a particular context. The most common example of this is a page that is used to present a specific instance of a database persistent entity. In such a case, the page must be combined with additional data, in the URL, to identify the specific entity to access and render.<br /><br />! URI Format<br /><br />{{{<br />/page-name.html/id<br />}}}<br /><br />Here "page-name" is the LogicalPageName for th
e page. <br /><br />The ".html" file extension is used as a delimiter between the page name portion of the URI, and the context portion of the URI. This is necessary because it is not possible (given the plethora of libraries and folders) to determine how many slashes will appear in the URI.<br /><br />The context consists of one ore more ids (though a single id is the normal case). The id is used to identify the specific data to be displayed. Further, a page may require multiple ids, which will separated with slashes. Example: /admin/DisplayDetail.html/loginfailures/2006<br /><br />Note that these context values, the ids, are simply //strings//. Tapestry 4 had a mechanism, the DataSqueezer, that would encode the type of object with its value, as a single string, and convert it back. While seemingly desirable, this facility was easy to abuse, resulting in long and extremely ugly URIs.<br /><br />Any further informatio
n needed by Tapestry will be added to the URI as query parameters. This may include things like user locale, persistent page properties, applicaition flow identifiers, or anything else we come up with.<br /><br />! Request Processing<br /><br />Once the page and id parameters are identified, the corresponding page will be loaded.<br /><br />Tapestry will fire two events before rendering the page.<br /><br />The first event is of type "activate". This allows the page to process the context (the set of ids). This typically involves reading objects from an external persistent store (a database)<br />and storing those objects into transient page properties, in expectaion of the render.<br /><br />This has been implemented, see the reference documentation for more details on passivate/activate.<br /></description>
+<link>http://tapestry.apache.org/tapestry5/tap5devwiki.html#PageRenderRequest</link>
+<pubDate>Sat, 20 Jan 2007 13:48:51 GMT</pubDate>
+</item>
+<item>
+<title>FullReload</title>
+<description>It has occured to me that by adding yet another smart class loader, we could possibly set up a system where we track date time modified on all the modules, service interfaces, and implementation files loaded by the Registry, such that changes to any of the files could result in a kind of "soft reload", where we reload the changed files and construct and use a new Registry.</description>
+<link>http://tapestry.apache.org/tapestry5/tap5devwiki.html#FullReload</link>
+<pubDate>Tue, 16 Jan 2007 14:50:00 GMT</pubDate>
</item>
<item>
<title>CaseInsensitivity</title>
@@ -113,27 +133,6 @@
<description>Tapestry is a big chunk of code, growing every day. We need to not step on each other's toes.<br /><br />//At this time, Tapestry is pretty single threaded, with Howard setting up the main infrastructure. Soon there's going to be a crowd of folks working on it, and we need to coordinate on this ahead of time.//<br /><br />Basic guidelines:<br /><br />* WorkInYourOwnBranch<br />* WatchCodeCoverage<br />* FocusOnTesting<br />* DontTouchInternals<br /></description>
<link>http://tapestry.apache.org/tapestry5/tap5devwiki.html#DeveloperProcedures</link>
<pubDate>Sat, 28 Oct 2006 15:25:00 GMT</pubDate>
-</item>
-<item>
-<title>InvisibleInstrumentation</title>
-<description>A feature of Tapestry 4 where the component id, type and parameters were "hidden" inside ordinary HTML tags.<br /><br />This will show up inside Tapestry 5 pretty soon, and look something like:<br />{{{<br /><span t:type="If" t:test="prop:showWarning" class="warning"> <br /> . . .<br /></span><br />}}}</description>
-<link>http://tapestry.apache.org/tapestry5/tap5devwiki.html#InvisibleInstrumentation</link>
-<pubDate>Fri, 20 Oct 2006 18:03:00 GMT</pubDate>
-</item>
-<item>
-<title>PropBinding</title>
-<description>The "prop:" binding prefix is the default in a lot of cases, i.e., in any Java code (annotations).<br /><br />This binding prefix supports several common idioms even though they are not, precisely, the names of properties. In many cases, this will save developers the bother of using a "literal:" prefix.<br /><br />The goal of the "prop:" prefix is to be highly efficient and useful in 90%+ of the cases. [[OGNL]], or synthetic properties in the component class, will pick up the remaining cases.<br /><br />!Numeric literals<br /><br />Simple numeric literals should be parsed into read-only, invariant bindings.<br />{{{<br />prop:5<br /><br />prop:-22.7<br />}}}<br /><br />The resulting objects will be of type Long or type Double. TypeCoercion will ensure that component parameters get values (say, int or float) of the correct type.<br />&l
t;br />!Range literals<br /><br />Expresses a range of integer values, either ascending or descending.<br />{{{<br />prop:1..10<br /><br />prop:100..-100<br />}}}<br /><br />The value of such a binding is Iterable; it can be used by the Loop component.<br /><br />!Boolean literals<br /><br />"true" and "false" should also be converted to invariant bindings.<br />{{{<br />prop:true<br /><br />prop:false<br />}}}<br /><br />!String literals<br /><br />//Simple// string literals, enclosed in single quotes. Example:<br />{{{<br />prop:'Hello World'<br />}}}<br /><br />//Remember that the binding expression will always be enclosed in double quotes.//<br /><br />!This literal<br /><br />In some cases, it is useful to be able to identify the current component:<br />{{{&
lt;br />prop:this<br />}}}<br /><br />Even though a component is not immutable, the value of //this// does not ever change,<br />and this binding is also invariant.<br /><br />!Null literal<br /><br />{{{<br />prop:null<br />}}}<br /><br />This value is always exactly null. This can be used to set a parameter who'se default value is non-null to the explicit value null.<br /><br />!Property paths<br /><br />Multi-step property paths are extremely important.<br /><br />{{{<br />prop:poll.title<br /><br />prop:identity.user.name<br />}}}<br /><br />The initial terms need to be readable, they are never updated. Only the final property name must be read/write, and in fact, it is valid to be read-only or write-only.<br /><br />The prop: binding factory builds a Java expression to read and update properties. It does not use r
eflection at runtime. Therefore, the properties of the //declared// type are used. By contrast, [[OGNL]] uses the //actual// type, which is reflection-intensive. Also, unlike OGNL, errors (such as missing properties in the property path) are identified when the page is loaded, rather than when the expression is evaluated.<br /></description>
-<category>bindings</category>
-<link>http://tapestry.apache.org/tapestry5/tap5devwiki.html#PropBinding</link>
-<pubDate>Fri, 20 Oct 2006 14:50:00 GMT</pubDate>
-</item>
-<item>
-<title>ComponentEvent</title>
-<description>Component events represent the way in which incoming requests are routed to user-supplied Java methods.<br /><br />Component events //primarily// originate as a result of a ComponentActionRequest, though certain other LifecycleEvents will also originate component events.<br /><br />Each component event contains:<br />* An event type; a string that identifies the type of event<br />* An event source; a component that orginates the event (where applicable)<br />* A context; an array of strings associated with the event<br /><br />Event processing starts with the component that originates the event.<br /><br />Handler methods for the event within the component are invoked.<br /><br />If no handler method aborts the event, then handlers for the originating component's container are invoked.<br /><br />This containues until handlers for the page (the root component) are invoked,
or until some handler method aborts the event.<br /><br />The event is aborted when a handler method returns a non-null, non-void value. The interpretation of that value varies based on the type of event.<br /><br />Events are routed to handler methods using the @~OnEvent annotation.<br /><br />This annotation is attached to a method within a component class. This method becomes a handler method for an event.<br /><br />The annotation allows events to be filtered by event type or by originating component.<br /><br />{{{<br /> @OnEvent(value="submit", component="form")<br /> String handleSubmit()<br /> {<br /> // . . .<br /><br /> return "PostSubmit";<br /> }<br />}}}<br /><br />In the above hypothetical example, a handler method is attached to a particular component's submit event. After processing the data in the
form, the LogicalPageName of another page within the application is returned. The client browser will be redirected to that page.<br /><br />Handler methods need not be public; they are most often package private (which facilitated UnitTesting of the component class).<br /><br />Handler methods may take parameters. This is most useful with handler methods related to links, rather than forms.<br /><br />Associated with each event is the context, a set of strings defined by the application programmer.<br /><br />Parameters are coerced (see TypeCoercion) from these strings. Alternately, a parameter of type String[] receives the set of strings.<br /><br />{{{<br /> @OnEvent(component="delete")<br /> String deleteAccount(long accountId)<br /> {<br /> // . . .<br /><br /> return "AccountPage";<br /> }<br />}}}<br /><br />Here, ther
first context value has been coerced to a long and passed to the deleteAccount() method. Presemuable, an action link on the page, named "delete", is the source of this event.<br /><br /></description>
-<category>requests</category>
-<category>events</category>
-<link>http://tapestry.apache.org/tapestry5/tap5devwiki.html#ComponentEvent</link>
-<pubDate>Sun, 08 Oct 2006 13:59:00 GMT</pubDate>
</item>
</channel>
</rss>