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 [EMAIL PROTECTED] 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>
