Agree with Bob as far as chat applications are concerned. I recently worked on a cometd-tapestry chat application and I was doing a lot more in javascript than in tapestry although I did integrate tapestry-security and tapestry-ioc which made the job a lot easier.
BTW, there is already a tapestry-cometd module by Lance. regards Taha On 09-Apr-2013, at 7:13 AM, Bob Harner <bobhar...@gmail.com> wrote: > Doesn't the switch to ETags for modules make for much chattier web apps, > with lots more "conditional GET" requests for JS modules coming in after > every page request? > > In any case, good riddance to the application version numbers. > > On Mon, Apr 8, 2013 at 9:10 PM, Howard Lewis Ship <hls...@gmail.com> wrote: > >> With the ETag support in place, there's no longer any need for the module >> asset URLs to have a checksum or version number; they are no longer given a >> far-future expires header. >> >> URLs (by default) look like "/modules/t5/core/dom.js" (where the module >> name is t5/core/dom). >> >> The application version number is no longer used in any URLs; it now exists >> just for documentation purposes (its written to the console at startup and >> in the exception report). This is good news, because you could screw >> yourself by deploying your application and NOT changing the version number >> (in 5.3.6). >> >> Very happy about this ... next up, thoughts on cometd/server-push support? >> >> >> >> On Tue, Mar 12, 2013 at 11:09 AM, Howard Lewis Ship <hls...@gmail.com >>> wrote: >> >>> >>> >>> On Tue, Mar 12, 2013 at 5:37 AM, Dmitry Gusev <dmitry.gu...@gmail.com >>> wrote: >>> >>>> On Tue, Mar 12, 2013 at 12:35 AM, Howard Lewis Ship <hls...@gmail.com >>>>> wrote: >>>> >>>>> I've been working, a few hours a week, on getting per-asset checksums >>>> into >>>>> URLs. >>>>> >>>>> Some parts of this have been a challenge to accomplish without >>>> completely >>>>> breaking the Asset interface and a bunch of public services. >>>>> >>>>> For ordinary assets, it's pretty easy ... but for aggregated >> JavaScript >>>>> libraries its been a pain that's affected a bunch of stuff. >>>>> >>>>> CSS files are now rewritten, since relative URLs will be broken by the >>>>> addition of the checksum. I have a first (but not final) pass at this, >>>> >>>> where url() patterns in the CSS are converted into complete paths. This >>>>> also opens the door to CSS aggregation as well as JavaScript >>>> aggregation. >>>>> >>>>> >>>> It depends on where you put the checksum. >>>> If you put it as a GET parameter - then no relative URLs will be broken. >>>> >>>> Have you read my blog post about Tapestry5 checksums in assets? >>>> >>>> >> http://dmitrygusev.blogspot.ru/2012/03/serving-tapestry5-assets-as-static.html >>> >>> >>> I'll read this shortly. I've generally assumed that URLs with query >>> parameters are less likely to be cached in the browser, or served >> properly >>> by intermediate (reverse proxy) servers, but I haven't done the research. >>> >>> >>>> >>>> >>>>> I still don't have a great solution for JavaScript modules; >>>> RequireJS/AMD >>>>> expect that there's a common root folder name (such as >>>> "/assets/modules/"), >>>>> and module "a/b" is simply "*root*/a/b.js". For individual modules, >> you >>>> can >>>>> write your own overrides. In fact, Tapestry has to strip off the >> ".js' >>>>> part (which is hard-wired by RequireJS) because the actual server-side >>>>> resource could be CoffeeScript or some other language that compiles to >>>>> JavaScript. >>>>> >>>>> Short of iterating all server-side module files and writing a >> RequireJS >>>>> config for each one (mapping each name to a URL with an embedded >>>> checksum), >>>>> there isn't a great solution. Alternately, something could iterate >> all >>>> the >>>>> server-side modules and built a composite checksum, but there are at >>>> least >>>>> a couple of virtual modules generated at runtime (and locale specific >>>> for >>>>> extra kicks). >>>>> >>>>> Modules may have to stay on the 5.3 approach: using the application >>>> version >>>>> number for everything. >>>>> >>>>> Finding the sweet spot where assets of all kinds (CSS, JavaScript >>>>> libraries, JavaScript modules, etc.) can be changed freely and the >> URLs >>>>> automatically reflect the actual content (that is, include a checksum >> of >>>>> that content) for ideal client-side caching ... may simply be out of >>>> reach. >>>>> >>>>> Perhaps for modules we should use an alternate approach based on >> ETags ( >>>>> http://en.wikipedia.org/wiki/HTTP_ETag); in that situation, there >> would >>>>> not >>>>> need to be any version number of checksum in a module URL, but clients >>>>> would request the module content more often (and based on ETag, would >>>> often >>>>> get a 304 Not Modified). I would prefer to see a URL that changes >> when >>>> the >>>>> content changes (which prevents the request entirely). >>>>> >>>>> -- >>>>> Howard M. Lewis Ship >>>>> >>>>> Creator of Apache Tapestry >>>>> >>>>> The source for Tapestry training, mentoring and support. Contact me to >>>>> learn how I can get you up and productive in Tapestry fast! >>>>> >>>>> (971) 678-5210 >>>>> http://howardlewisship.com >>>>> >>>> >>>> >>>> >>>> -- >>>> Dmitry Gusev >>>> >>>> AnjLab Team >>>> http://anjlab.com >>>> >>> >>> >>> >>> -- >>> Howard M. Lewis Ship >>> >>> Creator of Apache Tapestry >>> >>> The source for Tapestry training, mentoring and support. Contact me to >>> learn how I can get you up and productive in Tapestry fast! >>> >>> (971) 678-5210 >>> http://howardlewisship.com >>> >> >> >> >> -- >> Howard M. Lewis Ship >> >> Creator of Apache Tapestry >> >> The source for Tapestry training, mentoring and support. Contact me to >> learn how I can get you up and productive in Tapestry fast! >> >> (971) 678-5210 >> http://howardlewisship.com >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
