|
Author
|
Message
|
|
Carlos Revillo
|
Tuesday 21 June 2011 7:11:50 am
Always :). Seriously, my goal is try to have a really small number of database queries. so, having viewcaching enable, i use cache-blocks in the pagelayout.tpl to achive that. And i try to make this cache-block as unique as possible. i mean, i prefer a cache-block than a cache-block per user_id, for example.
|
|
Jean-Luc Nguyen
|
Tuesday 21 June 2011 7:19:56 am
Thanks Carlos for your answer, but actually, my question was, when, in the process of developing, do you guys implement cache-blocks? Is it after finishing developing the whole website and adding code on pagelayout (or whatever templates), or when implementing pagelayout? Thanks!
http://www.acidre.com
|
|
Carlos Revillo
|
Tuesday 21 June 2011 7:32:34 am
ah, i see. well, i work with all kind of caches enabled. and tell my teammates to do it that way. in our very first times with the product, we used to disable caches in the development stage, but at the end, what it happened is people forgot that. and when caches were enabled for going live, some pages didn't update as expected. a typical case of that was the use of get variables instead of view_parameters. yep, bad practice, but as i said, that was our very first times :)). so, definetily i wouldn't leave the process of adding cache-blocks to the end. for me is another task to be done with the others. My 2 cents :).
|
|
Marko Žmak
|
Tuesday 21 June 2011 11:26:29 am
This is my approach... There are some templates that I reuse very often on different sites, and for this I already have the cache blocks written inside this templates. As for the rest I leave writing cache block code for the last stage of development when most of the templates are done. The reason for this aproach is the fact that during the development many things can change, and often the functional specification of the site changes. Therefore, where and how will you use caceh blocks also changes durign this process. But the important thing is to always plan ahead, and while you code to have in your mind where and how will you use the template. I keep all caching disabled until the last stage of development. And than comes the cache setup part of the development when we are all dedicated to setting up, tweaking and optimizing all eZP caches. This is often done in collaboration with the clients so we can customise the refresh rates and conditions of the parts of pages to their needs. If you have planned ahead and your templates are "ready" to insert cache blocks into them, then this caching part of development won't give you much headache.
--
Nothing is impossible. Not if you can imagine it!
Hubert Farnsworth
|
|
Carlos Revillo
|
Tuesday 21 June 2011 11:45:51 am
i see. well, i prefer use heavily clear script cache in developtment. the reason for that is probably at the end of the development, i forgot what templates i did at first :))
|
|
Gaetano Giunta
|
Wednesday 22 June 2011 10:29:03 am
I develop with all caches off, and recommend devs to do so - it saves so much time when changing a template line a minute... But I also strongly recommend to have a test environment with debug on and caches on, where ideally the end user has access and which is updated by continuous integration (daily ?), that is the only reference environment for both functional and load testing. This way errors due to bad caching dependencies can be spotted before going live. And bad performance problems too. As for when to add cache blocks: just as soon as the pagelayout is finished in its functionality. This gives more time to test the cache blocks and perfs. If we leave this to the last minute, everybody will be in a hurry and it will be either not properly tested or not properly tuned. Last thing: in projects where I do actually put my hands on the keyobard, I have junior devs doing templates, and I do the cache blocks (or at least review them) personally. If not me, the most senior eZ dev in the team is tasked with them.
Principal Consultant International Business
Member of the Community Project Board
|
|
Carlos Revillo
|
Wednesday 22 June 2011 11:10:54 am
let me add more on this interesting topic. i don't think having cache disabled implies quicker development. ez publish is really heavy without caches. i prefer having a shell enabled and to use clear cache script heavily. you say for short changes can be tedious... but for me is more tedious to navigate for all your ezpublish install and wait all that time for the pages (even those you are not working on...) about the test environment, ok, it's a good idea. but for me all those involved in the project should do their tests. in my ideal world, all developer machines should be treated as if they were production environments. obviously with the chance for fails. test environment still should be there, but i would like to have all the team involved in the goal of taking care about perfomance, probably all this is because our own experiences. you know, when you start with ez you try yourself things and probably you end your first project without knowing anyhing about cache-blocks. about your example, probably your end user doesn't know anything about caching and so on. he do test, publish content, all work as expected... so, go on. but he probably doesn't realize that 40 sql queries has been needed for a page request, where probably only two of them are really needed. the end user probably doesn't see having 40 sql queries as problem, but you, as dev, should now that 2 queries are better than 40 :). for being brief, if our goal is to have as less sql queries as possible, we should try to reach this goal from the beginning of the work. i prefer to tell devs, even jr devs, this goal and let them the chance to have problems with caches than waiting for a more experimented one to finish the work. I prefer our junior devs asking me 'hey, i'm login in this page and i should see my name but still seems i'm anoymous' to 'hey, i finished my work. add caches here' And even more with ez publish and its powerful debug tools. Another 2 cents. :)
|
|
Gaetano Giunta
|
Wednesday 22 June 2011 2:24:45 pm
@carlos two things: end user knows squat about caches, but if they test on the same machin e as dev does, it makes it easier to reproduce bug (eliminating the 'it woks here' syndrome devs have) about lecturing all devs on caches and perfs: that's what I do daily to get my salary, you know ;-) I should have said more accurately "I let devs do them but always review them personally"
Principal Consultant International Business
Member of the Community Project Board
|
|
Carlos Revillo
|
Wednesday 22 June 2011 2:31:43 pm
@carlos two things: end user knows squat about caches, but if they test on the same machin e as dev does, it makes it easier to reproduce bug (eliminating the 'it woks here' syndrome devs have) about lecturing all devs on caches and perfs: that's what I do daily to get my salary, you know ;-) I should have said more accurately "I let devs do them but always review them personally"
Yep. agree with these two points. Cheers.
|
