You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Bård Magnus Kvalheim <ma...@kvalheim.eu> on 2013/11/07 13:13:47 UTC
[T5.4] A Tapestry upgrade experience
*Movellas - Our [T5.4] Tapestry upgrade experiences*
5.4 is underway and think a lot of users are wondering if or when they can
start using it for their applications. New or existing ones.
We've upgraded ours to 5.4 and hope our experiences can be helpful for
other and also help improving 5.4 towards a GA release.
Large site - tapestry from 2009/10
Initially 5.1.x line, but continuously upgraded up to 5.3.7
Movellas is today 150k registered users and about 1.5M visitors. And hope
to grow much larger :-)
As everywhere else in the industry - mobile traffic continues to grow.
Website is not mobile optimized, but have a separate version for that. As
well as a number of apps in the appstores.
Creating a responsive/adaptive experience on website is something we wanted
to get started, and after experimenting with 5.4.22 - we felt comfortable
enough about upgrading to an alpha.
Here are some of the experiences and challenges we’ve faced.
General process:
* Remove thirdparty modules incompatible or redundant for 5.4
* Set JQuery as infrastructure provider
* Migrate all(still valid) prototype scripts to JQuery
* Keep a checklist of pages and components to verify (can get from log or
T5Dashboard)
* On a page by page (and component) basis from checklist - update and
verify all
In general the migration took a lot of effort, but was not complicated.
For javascript and RequireJS some difficulties occurred, especially with
thirdparty js plugins/modules, but more on that below.
Thirdparty tapestry modules
- tapestry-jquery. Mostly for jquery and jqueryui support. Have made
alternative versions of the components used from tapestry-jquery
- t5conduit (less & coffeescript). Used tapestry-webresources. Mostly
effortless
- tapestry-yuicompressor -> tapestry-webresources
RequireJs
Never used that before, so was also a (good) learning experience.
Dependency management and injection of modules is great.
Combine files
We do have a lot of scripts which we’ve previously combined in stacks - and
cannot (easily) be done in 5.4.22.
New in 5.4.24. Howard have just announced possibility to add modules to
stacks - YAY.
Contribute to configuration
It is very common that thirdparty js modules also rely on RequireJs.
Therefore a way to configure/contribute to requirejs config is needed in
tapestry, especially paths. Would be great if it could be in
stack/page/component level so that the config is not global.
Have created a JIRA so please vote:
https://issues.apache.org/jira/browse/TAP5-2196
Underway: Thiago are working on it so think we’ll have a solution soon. YAY.
CDN / CloudFront
As a worldwide service we want to serve the assets as quickly as possible.
With AWS CloudFront we can configure the tapestry app as origin and the
assets will be ‘lazily’ populated to the edges around the world. This is
simple and effective and have served us well.
To enable this we’ve made a AssetPathConverter service which prepend the
CloudFront domain.
In 5.4 a few things changed that made it more difficult to support, at
least in our case - and have not yet been able to run reliably like in
5.3.x-
Expanded URLS in css
Now urls in css is expanded (which is good). However the AssetPathConverter
is eventually invoked and the full url with scheme and domain is inserted.
This is bad news for us for us as we do non atomic updates and rely on
sticky sessions while upgrading. After that we re-enable cloudfront ‘on the
fly’. This causes the checksums to mismatch and the site is broken.
I’ve made a workable hack to set a thread/request attribute once a css is
processed to avoid adding the full url and keep it relative to the css
domain. (See JIRA for more details:
https://issues.apache.org/jira/browse/TAP5-2201)
I’d like to have another pipeline for resolving css resources or
adding/knowing that it’s from inside a css so that we have better control.
Asset and module versioning
This have now been removed as it’s relying on checksums. However I do like
the extra control of versioning so I can easily force renewal of all
assets. Luckily it’s an easy way to bring this back by configuring the
“Asset path Prefix”. Great.
Module cache response headers
Requirejs modules have the following response headers
Cache-Control:max-age=0, must-revalidate
I think this means that they have to be checked at origin for every request
- and something I’d like to avoid as a global service. With module
versioning back in place I’d like to cache these aggressively for a long
period of time - just like the other assets.
I’ve adviced ResourceStreamer in order to cache js modules. See JIRA if
interested: https://issues.apache.org/jira/browse/TAP5-2201
Other challenges
As js is loaded and executed later, quite a bit of ajax functionality might
not have been bootstrapped and not working immediately on a rendered page.
It’s not really tapestry related I suppose, but sideeffect of late
(requirejs) execution.
Tapestry could possibly have some helper callbacks, blocking mechanisms or
just helpful tips and documentation.
Conclusion (sort of)
Overall I’m amazed of how stabile and great 5.4 is in current alpha and
will only continue to improve towards GA release. Think Howard (and other
committers) have done a tremendous job on 5.4 and will help keeping
Tapestry relevant for new projects.
There are gotchas, but can be picked up for production use now in my
opinion and experience.
My top wishlist:
- Better control and flexibility of Requirejs configuration
- Asset management (url generation and request handling). For CDN use
it’s not yet reliable in our experience. Would like to see more
configuration options and should be easier to override/decorate/advice in
case you need to.
We’re just getting started and have done just the initial migration and
will continue to improve and optimize for bootstrap(responsive/adaptive)
and requirejs. 5.4 definitely is a great leap forward and will help us
providing modern responsive experiences for the web.
Best
Magnus
Re: [T5.4] A Tapestry upgrade experience
Posted by Thiago H de Paula Figueiredo <th...@gmail.com>.
On Fri, 08 Nov 2013 06:39:33 -0200, Bård Magnus Kvalheim
<ma...@kvalheim.eu> wrote:
> Yes, so what I see in 24 is that core stack css is inserted after my own
> stack css. In 22 the core stack css was inserted before.
> In practice, bootstrap.css is now ordered after my own css so the
> 'overrides' don't work no more.
> Here's example screens:
> https://docs.google.com/presentation/d/12R7MmvtsG3XF6H5XY3fiUmh7oY-LJmWnihlZPP38RQw/edit?usp=sharing
>
> Let me know if more details is desired..
Thanks for the information, Magnus! I'll try to investigate and fix this
issue in the weekend.
--
Thiago H. de Paula Figueiredo
Tapestry, Java and Hibernate consultant and developer
http://machina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [T5.4] A Tapestry upgrade experience
Posted by Bård Magnus Kvalheim <ma...@kvalheim.eu>.
On Fri, Nov 8, 2013 at 2:31 AM, Thiago H de Paula Figueiredo <
thiagohp@gmail.com> wrote:
> On Thu, 07 Nov 2013 19:27:11 -0200, Bård Magnus Kvalheim <
> magnus@kvalheim.eu> wrote:
>
> ... On slightly different note while discussing 24 - the ordering of
>> stack css have changed from 22->24 which I currently have no workaround for.
>>
>
> Could you provide a concrete example? For another bug I fixed, I just made
> sure the CSS stylesheets from stacks are always put before the @Import'ed
> and the ones declared inside <head> directly. If any other ordering
> changed, then a regression happend and I should fix it.
Yes, so what I see in 24 is that core stack css is inserted after my own
stack css.
In 22 the core stack css was inserted before.
In practice, bootstrap.css is now ordered after my own css so the
'overrides' don't work no more.
Here's example screens:
https://docs.google.com/presentation/d/12R7MmvtsG3XF6H5XY3fiUmh7oY-LJmWnihlZPP38RQw/edit?usp=sharing
Let me know if more details is desired..
>
>
> True. Quite important to get rendered page as quick as possible. One
>> sideeffect is that it may take a while for all javascript to actually
>> execute and make all pieces work correctly. That could be ajax links for
>> partial render - which instead will trigger another full page reload if
>> not 'intercepted'.
>>
>
> Yep. But, if the event handler is checking for AJAX vs non-AJAX
> (Request.isXHR()), it will work in both ways.
In most cases where it's an issue we actually want it to be ajax/javascript
functionality only.
Think I'll look into making an 'Event/bind' mixin that provides desired
properties. I see Tapestry-JQuery have a similar one -
http://tapestry5-jquery.com/mixins/docsbind .
Re: [T5.4] A Tapestry upgrade experience
Posted by Thiago H de Paula Figueiredo <th...@gmail.com>.
On Thu, 07 Nov 2013 19:27:11 -0200, Bård Magnus Kvalheim
<ma...@kvalheim.eu> wrote:
> Okay, that's great. Didn't know it made it into alpha 24 - thanks again
> for this!
I couldn't check it but yet, as I recall the alpha being created after I
finished the JIRA ticket, alpha 24 should have it already. If not, next
alpha or beta will.
> ... On slightly different note while discussing 24 - the ordering of
> stack css have changed from 22->24 which I currently have no workaround
> for.
Could you provide a concrete example? For another bug I fixed, I just made
sure the CSS stylesheets from stacks are always put before the @Import'ed
and the ones declared inside <head> directly. If any other ordering
changed, then a regression happend and I should fix it.
> Yes, it's all there - but I'll try to clean it up a bit..
Thanks!
> True. Quite important to get rendered page as quick as possible. One
> sideeffect is that it may take a while for all javascript to actually
> execute and make all pieces work correctly. That could be ajax links for
> partial render - which instead will trigger another full page reload if
> not 'intercepted'.
Yep. But, if the event handler is checking for AJAX vs non-AJAX
(Request.isXHR()), it will work in both ways.
--
Thiago H. de Paula Figueiredo
Tapestry, Java and Hibernate consultant and developer
http://machina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [T5.4] A Tapestry upgrade experience
Posted by Bård Magnus Kvalheim <ma...@kvalheim.eu>.
On Thu, Nov 7, 2013 at 2:03 PM, Thiago H de Paula Figueiredo <
thiagohp@gmail.com> wrote:
> On Thu, 07 Nov 2013 10:13:47 -0200, Bård Magnus Kvalheim <
> magnus@kvalheim.eu> wrote:
>
> It is very common that thirdparty js modules also rely on RequireJs.
>> Therefore a way to configure/contribute to requirejs config is needed in
>> tapestry, especially paths. Would be great if it could be in
>> stack/page/component level so that the config is not global.
>>
>> Have created a JIRA so please vote:
>> https://issues.apache.org/jira/browse/TAP5-2196
>>
>
> No need for that. :)
>
>
> Underway: Thiago are working on it so think we’ll have a solution soon.
>> YAY.
>>
>
> It's done already and it should have been included in alpha 24. Check the
> new ModuleConfigurationCallback interface and JavaScriptSupport.
> addModuleConfigurationCallback() method. Basically, you can implement a
> callback that will receive a JSONObject containing the RequireJS
> configuration, so you can change it in any way you need, then return it.
Okay, that's great. Didn't know it made it into alpha 24 - thanks again for
this!
... On slightly different note while discussing 24 - the ordering of stack
css have changed from 22->24 which I currently have no workaround for.
Howard mentioned you might have a something cooking for this too..?
I’ve made a workable hack to set a thread/request attribute once a css is
>> processed to avoid adding the full url and keep it relative to the css
>> domain. (See JIRA for more details:
>> https://issues.apache.org/jira/browse/TAP5-2201)
>>
>> I’d like to have another pipeline for resolving css resources or
>> adding/knowing that it’s from inside a css so that we have better control.
>>
>
> That's a very good idea. Is it included in TAP5-2201? If not, include it
> there or open a separate JIRA.
Yes, it's all there - but I'll try to clean it up a bit..
>
> As js is loaded and executed later, quite a bit of ajax functionality
>> might not have been bootstrapped and not working immediately on a rendered
>> page. It’s not really tapestry related I suppose, but sideeffect of late
>> (requirejs) execution.
>>
>
> The overall JavaScript good practice is to place the JS inclusions as late
> as possible in the page so it doesn't block the download of other assets.
>
True. Quite important to get rendered page as quick as possible. One
sideeffect is that it may take a while for all javascript to actually
execute and make all pieces work correctly. That could be ajax links for
partial render - which instead will trigger another full page reload if not
'intercepted'.
Top of my head - Some options could be to:
* disable link:
http://stackoverflow.com/questions/2091168/disable-a-link-using-css
* Use buttons instead of links - possibly use disabled attribute as well
* hide/show elements
Don't know if tapestry could help (or if it's place), but it is more of an
issue now coming from 5.3 where everything loaded upfront.
- magnus
Re: [T5.4] A Tapestry upgrade experience
Posted by Thiago H de Paula Figueiredo <th...@gmail.com>.
On Thu, 07 Nov 2013 10:13:47 -0200, Bård Magnus Kvalheim
<ma...@kvalheim.eu> wrote:
> It is very common that thirdparty js modules also rely on RequireJs.
> Therefore a way to configure/contribute to requirejs config is needed in
> tapestry, especially paths. Would be great if it could be in
> stack/page/component level so that the config is not global.
>
> Have created a JIRA so please vote:
> https://issues.apache.org/jira/browse/TAP5-2196
No need for that. :)
> Underway: Thiago are working on it so think we’ll have a solution soon.
> YAY.
It's done already and it should have been included in alpha 24. Check the
new ModuleConfigurationCallback interface and
JavaScriptSupport.addModuleConfigurationCallback() method. Basically, you
can implement a callback that will receive a JSONObject containing the
RequireJS configuration, so you can change it in any way you need, then
return it.
> I’ve made a workable hack to set a thread/request attribute once a css is
> processed to avoid adding the full url and keep it relative to the css
> domain. (See JIRA for more details:
> https://issues.apache.org/jira/browse/TAP5-2201)
>
> I’d like to have another pipeline for resolving css resources or
> adding/knowing that it’s from inside a css so that we have better
> control.
That's a very good idea. Is it included in TAP5-2201? If not, include it
there or open a separate JIRA.
> As js is loaded and executed later, quite a bit of ajax functionality
> might not have been bootstrapped and not working immediately on a
> rendered page. It’s not really tapestry related I suppose, but
> sideeffect of late
> (requirejs) execution.
The overall JavaScript good practice is to place the JS inclusions as late
as possible in the page so it doesn't block the download of other assets.
> My top wishlist:
> - Better control and flexibility of Requirejs configuration
Wish already granted! :D
> - Asset management (url generation and request handling). For CDN use
> it’s not yet reliable in our experience. Would like to see more
> configuration options and should be easier to
> override/decorate/advice in
> case you need to.
>
>
> We’re just getting started and have done just the initial migration and
> will continue to improve and optimize for bootstrap(responsive/adaptive)
> and requirejs. 5.4 definitely is a great leap forward and will help us
> providing modern responsive experiences for the web.
>
>
> Best
>
> Magnus
--
Thiago H. de Paula Figueiredo
Tapestry, Java and Hibernate consultant and developer
http://machina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org