FAQ
Say I want to use TT in the .css, so (for example) I can name my colors and other
repeated content easily.

I'm assuming that I can define a Path of some kind on a rule to serve those. Any recipes
to share?
More critically, I want the browser to know that it doesn't have to keep re-fetching it on
every view of every page. How would I manage that?

Search Discussions

  • Jorge Gonzalez at Mar 1, 2011 at 10:45 am
    So what you need then is a templating system which caches the generated
    content from the templates and then when asked for it again later, it
    checks if the template has been changed, and if it hasn't (so the
    content generated will be the same if executed), answer the browser with
    a "Content not changed" instead of sending the content.

    Looks like you might need Template::Plugin::Cache:

    http://search.cpan.org/~perrin/Template-Plugin-Cache-0.13/Cache.pm
    <http://search.cpan.org/%7Eperrin/Template-Plugin-Cache-0.13/Cache.pm>

    Specially interesting the "Any gotchas..." section of the docs :-)

    Regards
    J.


    */Jorge González Villalonga/*
    Director Técnico

    */DAIKON Integración y Desarrollo S.L./*
    Telf: (+34) 91 188 08 28
    Fax: (+34) 91 632 65 42
    *www.daikon.es*


    El 01/03/11 10:23, John M. Dlugosz escribió:
    Say I want to use TT in the .css, so (for example) I can name my
    colors and other repeated content easily.

    I'm assuming that I can define a Path of some kind on a rule to serve
    those. Any recipes to share?
    More critically, I want the browser to know that it doesn't have to
    keep re-fetching it on every view of every page. How would I manage
    that?

    _______________________________________________
    List: Catalyst@lists.scsys.co.uk
    Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
    Searchable archive:
    http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
    Dev site: http://dev.catalyst.perl.org/
    -------------- next part --------------
    Skipped content of type multipart/related
  • John M. Dlugosz at Mar 1, 2011 at 11:49 am
    That's only part of it. It should also answer status 304, and set headers to tell the
    client not to even bother asking again any time soon.

    On 3/1/2011 4:45 AM, Jorge Gonzalez jorge.gonzalez-at-daikon.es |Catalyst/Allow to home|
    wrote:
    So what you need then is a templating system which caches the generated content
    from the templates and then when asked for it again later, it checks if the
    template has been changed, and if it hasn't (so the content generated will be
    the same if executed), answer the browser with a "Content not changed" instead
    of sending the content.

    Looks like you might need Template::Plugin::Cache:

    http://search.cpan.org/~perrin/Template-Plugin-Cache-0.13/Cache.pm
    <http://search.cpan.org/%7Eperrin/Template-Plugin-Cache-0.13/Cache.pm>

    Specially interesting the "Any gotchas..." section of the docs :-)

    Regards
    J.


    */Jorge González Villalonga/*
    Director Técnico

    */DAIKON Integración y Desarrollo S.L./*
    Telf: (+34) 91 188 08 28
    Fax: (+34) 91 632 65 42
    *www.daikon.es*


    El 01/03/11 10:23, John M. Dlugosz escribió:
    Say I want to use TT in the .css, so (for example) I can name my colors and
    other repeated content easily.

    I'm assuming that I can define a Path of some kind on a rule to serve those.
    Any recipes to share?
    More critically, I want the browser to know that it doesn't have to keep
    re-fetching it on every view of every page. How would I manage that?

    _______________________________________________
    List: Catalyst@lists.scsys.co.uk
    Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
    Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
    Dev site: http://dev.catalyst.perl.org/

    _______________________________________________
    List: Catalyst@lists.scsys.co.uk
    Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
    Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
    Dev site: http://dev.catalyst.perl.org/
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20110301/85481ae5/attachment.htm
  • Will Trillich at Mar 1, 2011 at 2:35 pm
    Also see
    http://wiki.catalystframework.org/wiki/adventcalendararticles/2007/11-Making_your_Catalyst_App_Cache-friendly
    for
    a neat approach to setting browser-cache expiry info.

    On Tue, Mar 1, 2011 at 5:49 AM, John M. Dlugosz wrote:

    That's only part of it. It should also answer status 304, and set headers
    to tell the client not to even bother asking again any time soon.


    On 3/1/2011 4:45 AM, Jorge Gonzalez jorge.gonzalez-at-daikon.es|Catalyst/Allow to home| wrote:

    So what you need then is a templating system which caches the generated content
    from the templates and then when asked for it again later, it checks if the
    template has been changed, and if it hasn't (so the content generated will be
    the same if executed), answer the browser with a "Content not changed" instead
    of sending the content.

    Looks like you might need Template::Plugin::Cache:
    http://search.cpan.org/~perrin/Template-Plugin-Cache-0.13/Cache.pm
    <http://search.cpan.org/%7Eperrin/Template-Plugin-Cache-0.13/Cache.pm> <http://search.cpan.org/%7Eperrin/Template-Plugin-Cache-0.13/Cache.pm>


    Specially interesting the "Any gotchas..." section of the docs :-)

    Regards
    J.


    */Jorge González Villalonga/*
    Director Técnico

    */DAIKON Integración y Desarrollo S.L./*
    Telf: (+34) 91 188 08 28
    Fax: (+34) 91 632 65 42
    *www.daikon.es*


    El 01/03/11 10:23, John M. Dlugosz escribió:
    Say I want to use TT in the .css, so (for example) I can name my colors and
    other repeated content easily.

    I'm assuming that I can define a Path of some kind on a rule to serve those.
    Any recipes to share?
    More critically, I want the browser to know that it doesn't have to keep
    re-fetching it on every view of every page. How would I manage that?

    _______________________________________________
    List: Catalyst@lists.scsys.co.uk
    Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
    Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
    Dev site: http://dev.catalyst.perl.org/

    _______________________________________________
    List: Catalyst@lists.scsys.co.uk

    Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
    Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
    Dev site: http://dev.catalyst.perl.org/



    _______________________________________________
    List: Catalyst@lists.scsys.co.uk
    Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
    Searchable archive:
    http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
    Dev site: http://dev.catalyst.perl.org/

    --
    The first step towards getting somewhere is to decide that you are not going
    to stay where you are. -- J.P.Morgan
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20110301/d43baa20/attachment.htm
  • Bill Moseley at Mar 1, 2011 at 3:58 pm

    On Tue, Mar 1, 2011 at 1:23 AM, John M. Dlugosz wrote:

    Say I want to use TT in the .css, so (for example) I can name my colors
    and other repeated content easily.

    I'm assuming that I can define a Path of some kind on a rule to serve
    those. Any recipes to share?
    More critically, I want the browser to know that it doesn't have to keep
    re-fetching it on every view of every page. How would I manage that?
    At build time I minimize and compress css and js (and images) and combine
    into single files grouped by page(s). They could be pre-processed by TT
    very easily. The final file names include an MD5 of their content forcing a
    re-fetch only if they ever change. (Maybe HTML5 manifest files will
    simplify this a bit.)

    They get served by Catalyst with an expiration time a year or so into the
    future. The URL for the resources on the web pages point to a CDN which
    caches the fetched files. A caching proxy with a different domain would
    also work. Under development mode the css files are served directly from
    the Catalyst server as separate files, not minified to make debugging
    easier.

    I've been debating using data URLs for the smaller background images instead
    of using Sprite files, but support is not great yet.

    I thought about using TT for css, but the need has never come up and it
    would mean more training.



    --
    Bill Moseley
    moseley@hank.org
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20110301/dc65836c/attachment.htm
  • John M. Dlugosz at Mar 2, 2011 at 5:43 am

    On 3/1/2011 9:58 AM, Bill Moseley moseley-at-hank.org |Catalyst/Allow to home| wrote:
    At build time I minimize and compress css and js (and images) and combine
    into single files grouped by page(s). They could be pre-processed by TT
    very easily. The final file names include an MD5 of their content forcing a
    re-fetch only if they ever change.
    So you added that to the makefile somehow? I take it the generated name must be supplied
    to the page's template once it is known. I'd like to learn more about your system.

    So if you make a small change, you have to re-install the whole app? If the file name
    changes, I can't just use Unison to sync the directory on the production server.

    As for reaching for templates in CSS: Sure, you can break common lines into different
    tags so you only specify a color once:

    #this, #that, div p .theother { color: xxxxx }

    but that doesn't help making (say) a border color and a background color the same value.
  • Ronald J Kimball at Mar 2, 2011 at 4:15 pm

    On Wed, Mar 2, 2011 at 12:43 AM, John M. Dlugosz wrote:

    As for reaching for templates in CSS: ?Sure, you can break common lines into
    different tags so you only specify a color once:

    ? ?#this, #that, div p .theother { color: xxxxx }

    but that doesn't help making (say) a border color and a background color the
    same value.
    Have you considered using LESS? http://lesscss.org/

    Ronald
  • Tomas Doran at Mar 2, 2011 at 5:22 pm

    On 2 Mar 2011, at 05:43, John M. Dlugosz wrote:

    On 3/1/2011 9:58 AM, Bill Moseley moseley-at-hank.org |Catalyst/
    Allow to home| wrote:
    At build time I minimize and compress css and js (and images) and
    combine
    into single files grouped by page(s). They could be pre-processed
    by TT
    very easily. The final file names include an MD5 of their content
    forcing a
    re-fetch only if they ever change.
    So you added that to the makefile somehow? I take it the generated
    name must be supplied to the page's template once it is known. I'd
    like to learn more about your system.
    Yes, you can append things to the Makefile to
    So if you make a small change, you have to re-install the whole
    app? If the file name changes, I can't just use Unison to sync the
    directory on the production server.
    Yes!

    Installing to production servers via rsync / unison is insane, as
    there is exactly no way of knowing what version the production server
    is on, with what bugs... Which means that all bug reports become
    useless - as you never know if the user was using the site before or
    after you fixed (or, more often, you think you fixed, but didn't
    really fix a bug)..

    Cheers
    t0m
  • Pedro Melo at Mar 2, 2011 at 5:27 pm
    Hi,
    On Wed, Mar 2, 2011 at 5:24 PM, Tomas Doran wrote:
    Installing to production servers via rsync / unison is insane, as there is
    exactly no way of knowing what version the production server is on, with
    what bugs...
    Of course you can. You can include a file .version at the root created
    with 'git describe --always' > .version before you rsync, and then
    include it on your test reports.

    Rsync is a valid deployment method, specially if you use a stage
    server where you make install you app.

    Bye,
    --
    Pedro Melo
    http://www.simplicidade.org/
    xmpp:melo@simplicidade.org
    mailto:melo@simplicidade.org
  • Tomas Doran at Mar 2, 2011 at 5:46 pm

    On 2 Mar 2011, at 17:27, Pedro Melo wrote:
    On Wed, Mar 2, 2011 at 5:24 PM, Tomas Doran wrote:
    Installing to production servers via rsync / unison is insane, as
    there is
    exactly no way of knowing what version the production server is on,
    with
    what bugs...
    Of course you can. You can include a file .version at the root created
    with 'git describe --always' > .version before you rsync, and then
    include it on your test reports.

    Rsync is a valid deployment method, specially if you use a stage
    server where you make install you app.
    Ah, but then you're deploying a specific sha1 from git, rather than
    just rsyncing a directory!

    And as you'll have a script to ensure that you have reset --hard
    MYSHA1 (otherwise you are perfectly screwed just as I described), then
    you can put the build parts in there...

    Cheers
    t0m
  • Pedro Melo at Mar 2, 2011 at 6:39 pm
    Hi,
    On Wed, Mar 2, 2011 at 5:49 PM, Tomas Doran wrote:
    On 2 Mar 2011, at 17:27, Pedro Melo wrote:
    On Wed, Mar 2, 2011 at 5:24 PM, Tomas Doran wrote:
    Installing to production servers via rsync / unison is insane, as there
    is
    exactly no way of knowing what version the production server is on, with
    what bugs...
    Of course you can. You can include a file .version at the root created
    with 'git describe --always' > .version before you rsync, and then
    include it on your test reports.

    Rsync is a valid deployment method, specially if you use a stage
    server where you make install you app.
    Ah, but then you're deploying a specific sha1 from git, rather than just
    rsyncing a directory!

    And as you'll have a script to ensure that you have reset --hard MYSHA1
    (otherwise you are perfectly screwed just as I described), then you can put
    the build parts in there...
    Actually the complete workflow is to push to our production repo, and
    then run a script to publish a particular SHA1 to production. That
    will git pull in the stage server, create a release branch, and then
    run all the deploy scripts (minification of JS, CSS, and whatever is
    needed.).

    Everything is committed to the release branch and the new sha1 from
    that is the one actually used on production servers.

    Right now, thats a git reset to the release-sha1, and then a rsync to
    production servers. I'm actually considering git pull's directly from
    the production servers. Git is actually more effective than rsync,
    given that it can calculate pretty easily which files changed between
    versions.

    Having git workdirs in the production servers has the extra advantage
    of a easy way to revert bad releases, at least from the code
    perspective. Reverting DB schemas is much more interesting.

    Bye,
    --
    Pedro Melo
    http://www.simplicidade.org/
    xmpp:melo@simplicidade.org
    mailto:melo@simplicidade.org
  • John M. Dlugosz at Mar 3, 2011 at 6:09 am

    On 3/2/2011 11:27 AM, Pedro Melo melo-at-simplicidade.org |Catalyst/Allow to home| wrote:
    Of course you can. You can include a file .version at the root created
    with 'git describe --always'> .version before you rsync, and then
    include it on your test reports.
    Nice tip. Thanks.
  • Will Trillich at Mar 2, 2011 at 5:35 pm
    Here's our current dev-to-deploy approach -- we use mercurial and a
    three-step staging process:

    A) sandbox/dev server:

    dev-server$ vi lib/*/blah/yadda
    dev-server$ CATALYST_DEBUG=1 script/*_server.pl

    test dev-server:3000 plenty -- lots of iterating, and then prep for
    deploy-testing:

    dev-server$ hg addremove
    dev-server$ perl Makefile.PL
    dev-server$ make manifest
    dev-server$ hg ci -m "log message here"

    now, on deployment server:

    B) live environment, sandbox port 3000:

    deploy$ hg fetch
    deploy$ CATALYST_DEBUG=0 script/*_server.pl

    now we test deploy:3000 and if all is well...

    C) full "live" deployment:

    deploy$ perl Makefile.PL && make
    deploy$ sudo make install && sudo apache2ctl graceful

    Pretty sweet so far!

    On Wed, Mar 2, 2011 at 5:24 PM, Tomas Doran wrote:


    On 2 Mar 2011, at 05:43, John M. Dlugosz wrote:

    On 3/1/2011 9:58 AM, Bill Moseley moseley-at-hank.org |Catalyst/Allow to
    home| wrote:
    At build time I minimize and compress css and js (and images) and combine
    into single files grouped by page(s). They could be pre-processed by TT
    very easily. The final file names include an MD5 of their content
    forcing a
    re-fetch only if they ever change.
    So you added that to the makefile somehow? I take it the generated name
    must be supplied to the page's template once it is known. I'd like to learn
    more about your system.
    Yes, you can append things to the Makefile to


    So if you make a small change, you have to re-install the whole app? If
    the file name changes, I can't just use Unison to sync the directory on the
    production server.
    Yes!

    Installing to production servers via rsync / unison is insane, as there is
    exactly no way of knowing what version the production server is on, with
    what bugs... Which means that all bug reports become useless - as you never
    know if the user was using the site before or after you fixed (or, more
    often, you think you fixed, but didn't really fix a bug)..

    Cheers
    t0m




    _______________________________________________
    List: Catalyst@lists.scsys.co.uk
    Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
    Searchable archive:
    http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
    Dev site: http://dev.catalyst.perl.org/


    --
    The first step towards getting somewhere is to decide that you are not going
    to stay where you are. -- J.P.Morgan
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20110302/174be1e0/attachment.htm
  • Will Trillich at Mar 2, 2011 at 5:38 pm

    On Wed, Mar 2, 2011 at 5:35 PM, will trillich wrote:

    Here's our current dev-to-deploy approach -- we use mercurial and a
    three-step staging process:

    A) sandbox/dev server:

    dev-server$ vi lib/*/blah/yadda
    dev-server$ CATALYST_DEBUG=1 script/*_server.pl

    test dev-server:3000 plenty -- lots of iterating, and then prep for
    deploy-testing:

    dev-server$ hg addremove
    dev-server$ perl Makefile.PL
    dev-server$ make manifest
    dev-server$ hg ci -m "log message here"

    now, on deployment server:

    B) live environment, sandbox port 3000:

    deploy$ hg fetch
    deploy$ CATALYST_DEBUG=0 script/*_server.pl
    Quick edit, that last command above is actually
    deploy$ *CATALYST_DEBUG=0 sudo -u www-data perl script/*_server.pl*
    to make sure we're using the standard webserver user-permissions

    now we test deploy:3000 and if all is well...
    C) full "live" deployment:

    deploy$ perl Makefile.PL && make
    deploy$ sudo make install && sudo apache2ctl graceful

    Pretty sweet so far!

    On Wed, Mar 2, 2011 at 5:24 PM, Tomas Doran wrote:


    On 2 Mar 2011, at 05:43, John M. Dlugosz wrote:

    On 3/1/2011 9:58 AM, Bill Moseley moseley-at-hank.org |Catalyst/Allow to
    home| wrote:
    At build time I minimize and compress css and js (and images) and
    combine
    into single files grouped by page(s). They could be pre-processed by TT
    very easily. The final file names include an MD5 of their content
    forcing a
    re-fetch only if they ever change.
    So you added that to the makefile somehow? I take it the generated name
    must be supplied to the page's template once it is known. I'd like to learn
    more about your system.
    Yes, you can append things to the Makefile to


    So if you make a small change, you have to re-install the whole app? If
    the file name changes, I can't just use Unison to sync the directory on the
    production server.
    Yes!

    Installing to production servers via rsync / unison is insane, as there is
    exactly no way of knowing what version the production server is on, with
    what bugs... Which means that all bug reports become useless - as you never
    know if the user was using the site before or after you fixed (or, more
    often, you think you fixed, but didn't really fix a bug)..

    Cheers
    t0m




    _______________________________________________
    List: Catalyst@lists.scsys.co.uk
    Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
    Searchable archive:
    http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
    Dev site: http://dev.catalyst.perl.org/


    --
    The first step towards getting somewhere is to decide that you are not
    going to stay where you are. -- J.P.Morgan


    --
    The first step towards getting somewhere is to decide that you are not going
    to stay where you are. -- J.P.Morgan
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20110302/98b97e5b/attachment.htm
  • Octavian Rasnita at Mar 3, 2011 at 7:58 am
    From: will trillich
    Here's our current dev-to-deploy approach -- we use mercurial and a three-step staging process:
    ....



    I think that it could be helpful to add a page to the Cat site that describe the workflow for deployment because it is not clear which are the possible/recommended methods.

    Octavian




    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20110303/d5e318a0/attachment.htm
  • John M. Dlugosz at Mar 3, 2011 at 9:23 am

    On 3/3/2011 1:58 AM, Octavian Rasnita orasnita-at-gmail.com |Catalyst/Allow to home| wrote:
    From: will trillich
    Here's our current dev-to-deploy approach -- we use mercurial and a three-step staging process:
    ....



    I think that it could be helpful to add a page to the Cat site that describe the workflow for deployment because it is not clear which are the possible/recommended methods.

    Octavian







    _______________________________________________
    List: Catalyst@lists.scsys.co.uk
    Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
    Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
    Dev site: http://dev.catalyst.perl.org/
    I'll second that.

    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20110303/44f38bd3/attachment.htm
  • John M. Dlugosz at Mar 3, 2011 at 6:05 am

    On 3/2/2011 11:24 AM, Tomas Doran bobtfish-at-bobtfish.net |Catalyst/Allow to home| wrote:
    Installing to production servers via rsync / unison is insane, as there is exactly no
    way of knowing what version the production server is on, with what bugs... Which means
    that all bug reports become useless - as you never know if the user was using the site
    before or after you fixed (or, more often, you think you fixed, but didn't really fix a
    bug)..
    I don't follow. If it changes the files around on the server to match the build you have
    locally, what difference does it make whether it used a per-file patching method or if it
    wiped out everything and copied all the files including huge graphics that didn't change
    at all? Either way, it now matches what you said to put up there.
  • Bill Moseley at Mar 2, 2011 at 6:01 pm

    On Tue, Mar 1, 2011 at 9:43 PM, John M. Dlugosz wrote:

    On 3/1/2011 9:58 AM, Bill Moseley moseley-at-hank.org |Catalyst/Allow to
    home| wrote:
    At build time I minimize and compress css and js (and images) and combine
    into single files grouped by page(s). They could be pre-processed by TT
    very easily. The final file names include an MD5 of their content forcing
    a
    re-fetch only if they ever change.
    So you added that to the makefile somehow? I take it the generated name
    must be supplied to the page's template once it is known. I'd like to learn
    more about your system.
    We have YAML config files for different classes of resources -- one for css,
    one for js, one for images, and a few for different types of media (pds,
    etc.). There's three sections in the yaml files, the first is a general
    config with a relative source directory and output directory. Other
    settings can be added there like compression threshold.

    The next section defines "output_sets" where each named set consists of an
    output file name e.g. all.css" and a secion "file_sets." There's also
    additional config per set e.g. to specify the meda type (screen/print) and
    things like IE version. The file_sets is a list of names referenced in the
    last section. That section lists the source_files grouped by file_set.

    Things like images and media that we want to version but are not combined
    like css and js are configured also with YAML files but have a regular
    expression to match all files in the source directory tree (so new images
    can be dropped in without editing a config file).

    Yes, Makefile.PL runs a script that uses the YAML files to build the
    resources. Each resource type (css, js) has its own subclass for processing
    that type of file. The css background image locations are parsed, images
    found (relative to css file), compressed (when configured), copied to build
    directory with a new filename (includes the MD5 of the image) and the
    background URL is rewritten. Files are gzipped if over a threshold. The
    build directory ends up with three copies of every file (linked), one with
    the plain file "all.css", one with MD5, and one compressed.

    Part of the build process builds a mapping file of "output_set" name to the
    markup for either the combined version ("all.css") and also to the
    individual files. This allows switching between compressed, minified single
    resource file (used in production) to using the individual files for
    dev/debugging. In the templates, for example, it's basically [%
    css_resource_set( 'dynamic_cms' ) %]

    So if you make a small change, you have to re-install the whole app? If the
    file name changes, I can't just use Unison to sync the directory on the
    production server.
    The entire app gets built and installed to qa, then staging, then rsync to
    production. (Although moving to RPM deployment.)


    Much of this is to minimize the data over the wire and also to minimize the
    number of http requests. And to version and cache, of course. The trade
    off of fewer requests is some css and js ends up being shared by pages where
    that code is not used. All the performance discussion talk about reducing
    number of http requests. I'm not so sure about that trade-off -- fewer
    requests vs. larger files that combine js and css that are not used on every
    page. Now, I'd probably look more at more http request but done in a lazy
    load way over a number of domains.


    As for reaching for templates in CSS: Sure, you can break common lines
    into different tags so you only specify a color once:

    #this, #that, div p .theother { color: xxxxx }

    but that doesn't help making (say) a border color and a background color
    the same value.

    I think that's a different problem. Again, it would be easy for us to
    pre-process our CSS files, but that's just never been an issue. I think much
    of what you are asking about can be taken care of with good css design --
    and design changes don't happen very often so it's pretty easy to hunt down
    and easy to verify by looking at the site. If the same color is used so
    many places that you want to template it maybe then the css is not set up
    clean enough.


    --
    Bill Moseley
    moseley@hank.org
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20110302/45ed4806/attachment.htm

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupcatalyst @
categoriescatalyst, perl
postedMar 1, '11 at 9:23a
activeMar 3, '11 at 9:23a
posts18
users8
websitecatalystframework.org
irc#catalyst

People

Translate

site design / logo © 2022 Grokbase