{
"info": {
"author": "Balazs Ree",
"author_email": "ree@greenfinity.hu",
"bugtrack_url": null,
"classifiers": [
"Development Status :: 4 - Beta",
"Intended Audience :: Developers",
"Programming Language :: Python",
"Topic :: Internet :: WWW/HTTP",
"Topic :: Internet :: WWW/HTTP :: WSGI",
"Topic :: Internet :: WWW/HTTP :: WSGI :: Application"
],
"description": "gf.rejuice\n==========\n\n**`gf.rejuice` provides additional tools for developers to use `Juicer`\nfor the compression of Javascript and CSS resources,\nin the\ncontext of python web applications that run via WSGI.**\n\n**Q:** Is this for me, shall I use it?\n\n**A:** If you develop javascript with some python based (WSGI) application, and you already\nuse Juicer, or consider using some method for compressing your resources, then you may\nfind `gf.rejuice` useful.\n\n**This is a package under active development.**\n\n**Q:** Is is safe to use it?\n\n**A1:** No. Although it is well tested, it may contain bugs, or may not support your use\ncase. Things can also change substantially, in a following version.\n\n**A2:** Yes, it is safe, because you actually only use it for development. It is not\neven installed on the production website. So, the risk is minimal.\n\nObjectives\n----------\n\n`gf.rejuice` attempts to provide additional tools for developers to use `Juicer` in the\ncontext of python web applications that run via WSGI.\n\n`Juicer`_ is a CSS and JavaScript packaging tool, that provides a method to compress \n(minify) and concatenate the\nresources for a website or a software package. \n(Juicer supports the widely used and stable `YUI Compressor`_.)\nThis compression happens manually, offline.\nThen, if this resource is used in a website page, the\npage can use the compressed resources directly.\n\n.. _Juicer: http://cjohansen.no/en/ruby/juicer_a_css_and_javascript_packaging_tool\n\n.. _YUI Compressor: http://developer.yahoo.com/yui/compressor/\n\nIt is, however, very difficult or close to impossible to debug and develop websites with fully\ncompressed resources.\nAs a developer, my every day work routine needs an easy way to switch to a \"development mode\",\nwhere I am able to access the original set of uncompressed, undeveloped resources.\n\nOne possible solution for this would be to provide two sets of resources from the website pages: one for\nproduction that contains the compressed resources, and one for development. This can\nbe achieved in several ways, for example, by providing two sets of resources from the html headers\nconditionally, or use some kind of registry that supports a Development / Production mode switch.\nThe problem with these approaches is that they almost always require\nchanges in the software and possibly extra administration, redundancy, which can be\nespecially painful if the project has many resources.\n\nAs an alternate solution, to avoid a dual set of resources, \nsome tool can be used that supports the compression and\nminification of the original sources on the fly. This however has the disadvantage that\ndue to the fact that even the most robust compression methods are prone to errors,\nit is more difficult to verify the validity of the produced resources, than in offline\nmode.\n\n`gf.rejuice` attempts to provide a simple way to aid this process.\nIn comparision with existing tools, that support the compression and\nminification of the original sources on the fly, `gf.rejuice` supports a workflow the other way around.\nIt takes the minified resources as the reference, and provides access to the uncompressed\nresources for development.\n\nIt does this by providing a way to transparently switch a site\nthat contains and refers the compressed (minified) resources only, into development mode.\nIt does this without the need to change the original software and templates.\nIn addition, it also provides a way to automate the process of compressing or recompressing\nthe resources for production, in case this becomes necessary due to some changes\nthat have been made to the sources.\n\n\nLicense\n-------\n\n`gf.rejuice` is dual-licensed by the GPLv2 and BSD licenses. You have to choose\nany one or both of these licenses for the redistribution of this software.\n\n`gf.rejuice` does not contain or redistribute Juicer itself, Juicer still needs to be\ninstalled separately, but even this is not necessary for each use case.\n\nInstallation\n------------\n\nYou need to install the `gf.rejuice` package to be importable from your project.\nIf you use buildout, this can be done by adding `gf.rejuice` to your egg section::\n\n eggs =\n ....\n gf.rejuice\n\nIn addition, you need to configure a `paster.ini` file that you will use for development.\n\nTo use the current newest development version, you can download the package from its\nsource repository and install it\npackage manually. Alternately, you can use a recipe like `gf.recipe.bzr` or similar from your buildout\nto install the software directly from the source repository::\n\n [src]\n recipe = gf.recipe.bzr\n urls =\n bzr+ssh://gfpublic@greenfinity.hu/home/gfpublic/gf.rejuice/trunk gf.rejuice\n\n(To use gf.recipe.bzr, you need to have Bazaar installed on your computer.)\n\nSimple configuration\n--------------------\n\nTo configure `gf.rejuice`, you need to provide a development configuration for paster.\nThis can be done by copying your original ini file to a second ini file.\nThen, add the necessary configuration\nto the development (second) ini.\n\nFor example, your application had a paster configuration file `myapp.ini`, and you\ncreate a second `myapp-devel.ini` from it.\n\nFollowing this, you can use paster with the original, unchanged ini file `myapp.ini` to run the\napplication in production mode, and the `myapp-devel.ini` file\nwill be used to run the application in development mode.\n\nThe following describes the parts to be added to `myapp-devel.ini` to produce a simple\nworking configuration::\n\n [filter:rejuice]\n use = egg:gf.rejuice#develjuice\n url_prefix = /static\n filepath = egg:my.package/views/static\n\n # Resource composition:\n default.min.js = default.js\n min/default.min.css = custom/default.css\n\n [pipeline:main]\n pipeline =\n ...\n rejuice\n main_app\n\n\nThe WSGI filter section\n\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\n\nIn the above example, the `[filter:rejuice]` section defines the wsgi middleware that does the transformation\nfrom production resource urls produced by the the `main_app`, to the corresponding\ndevelopment resource urls. Which application is generating the page to be transformed, \nor in which particular method this happens,\nis ambivalent for this process.\n\nThe `url_prefix` and `filepath` parameters are needed to specify *where* the resources reside,\nfollowing that a resource list specifies *what* resources the WSGI filter should consider.\n\n\nurl_prefix, filepath: specifying the static tree of resources\n\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\n\nThe `url_prefix` and `filepath` parameters must always stand together with the actual list of resources.\nTogether they specify a static tree in your application.\n\n`url_prefix` specify the prefix of the url where the root of this static tree appears in the\napplication's url space. The setting::\n\n url_prefix = /static\n\nspecifies that the `http://127.0.0.1:6543/static` url is the root of the static tree that your application\npublishes.\n\n`filepath` specifies where the same static tree can be found in the filesystem::\n\n filepath = views/static\n\nIn this example, the path is constructed relatively to the directory of the `myapp-devel.ini` configuration\nfile that holds the declaration.\n\nNote that the `gf.rejuice` middleware does not actually publish this static tree, it still is the\nresponsibility of your application. The parameters are needed for url rewrite.\n\n\nSpecifying resource composition\n\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\n\nWith the rest of the section content, you can specify a list of javascript or css resources here.\nAnything ending with `.js` or `.css` will be considered to be a resource::\n\n default.min.js = default.js\n min/default.min.css = custom/default.css\n\nEach line contains two values here. The value on the left of the equal sign specifies the \ncompressed, minified resource (the result of compression). The right value specified the\noriginal, uncompressed source (the origin of compression).\nAll file paths are applied relatively from the root of the static\ntree, specified by `url_prefix` and `filepath`.\n\nLater we will see that it is also possible to produce one resource from a list of resources,\nwhich, in that case will be compressed and concatenated to a single resource. The configuration\nallows a list of resources in multiple lines::\n\n default.min.js = \n dependency.js\n ...\n default.js\n\n\nResult of the configuration\n---------------------------\n\nLet's assume that you have the following resources specified from the head section of your html page::\n\n \n \n\nThe middleware will transform this to a website that loads the original sources::\n\n \n \n\nJuicer also allows to specify dependencies for the resources. The dependent resources\nmay also contain further dependencies. For further explanation, please read the\ndocumentation of `juicer`.\n\n`default.js`::\n\n /* @depends a/source_a.js\n @depends b/source_b.js\n */\n\n`custom/default.css`::\n\n @import ../a/style_a.css\n @import ../b/style_b.css\n\nThe middleware will add the dependent javascript resources to the html headers. For css\nthis is not needed, as `@import` describes the inclusion dependencies in a native way for the browser.\nThe end result will be a html that contains the full set of original resources::\n\n \n \n \n \n\nFor more complex examples on how to specify dependencies for `juicer`, you can look \nat the sources of the `Bottlecap UI`_, that provides the dependencies to compress the `jquery-ui` framework.\n\n.. _Bottlecap UI: https://github.com/Pylons/bottlecap\n\n\nTwo ways to produce the same result\n\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\n\nRather than specifying the dependencies in the style of Juicer, \nby using `@import` for css and `@depends` for js, the same results can be achieved\ndirectly from the configuration as well::\n\n default.min.js =\n a/source_a.js\n b/source_b.js\n default.js\n min/default.min.css =\n a/style_a.css\n b/style_b.css\n custom/default.css\n\nThis configuration could replace and is equivalent with the usage of `@import` and `@depends`\nin the above example.\n\nWhich one of the two ways are better to use, depends on use case and personal taste.\n\n\nCompression\n-----------\n\nAlthough it is quite easy to use Juicer directly from the command line to produce the\ncompressed resources, `gf.rejuice` provides an automation for this.\n\nTo use Juicer, you must have Juicer and its dependencies already installed. The\ndocumentation of Juicer describes this simple process. This installation\n(including java and ruby) does not need to be present for the middleware to work,\nonly for carrying out the actual compression.\n\nIf you use buildout, you can enter the following from the command line::\n\n bin/rejuice paster_devel.ini filter:rejuice\n\nWith the example ini file described earlier, this will produce or reproduce both `default.min.js` and\n`default.min.css` from their original sources. `filter:rejuice` here refers to\nthe juicer definition section from the ini file. Any extensions referred from this\nsection are also processed.\n\nAn extension section can also be specified directly::\n\n bin/rejuice another_config_file.ini juice_resources\n\nIf you do not use buildout, you can also run the `rejuice_script.py` file directly::\n\n python path/to/package/gf/rejuice/rejuice_script.py paster_devel.ini juice_resources\n\n\n\nAdvanced configuration\n----------------------\n\nIn this section we explain the usage of all parameters. They belong to two groups: the first group\nspecifies which urls the middleware should consider for transformation at all, the second\ngroup gives control over selecting the resources that should be considered, by specifying a static\ntree and by specifying the resource composition itself.\n\n\nAffecting which urls the middleware should consider\n\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\n\nThe task of the middleware is to transform only resources that are on the same server as where the\npage is. So it needs to decide which resources are local and which not.\n\nBy default, the middleware considers those resources as local, whose domain matches the domain\nof the currently served page. To do this, nothing needs to be specified.\n\nFor example, if your application is served from this url::\n\n http://127.0.0.1:6543/\n\nThen the following resources will be considered local, if they appear in the page header::\n\n http://127.0.0.1:6543/default.js\n http://127.0.0.1:6543/static/default.css\n /any/absolute/path/my.js\n any/relative/path/my.css\n\nBut the following resources will be considered remote, and thus ignored::\n\n http://github.com/jquery/qunit/raw/master/qunit/qunit.js\n http://ajax.googleapis.com/ajax/libs/jqueryui/1.8.2/themes/smoothness/jquery-ui.css\n http://localhost:6543/static/default.css\n \nThis is adequate for most web applications, that generate resource names in a way that they\nuse the base domain of the currently served page. If this is not a case (note that `localhost` would not\nbe accepted as local if the page is served on `127.0.0.1`), or the use case needs finer control, there\nare two parameters that make this possible.\n\n\nbase_urls: specifying the url host to consider\n''''''''''''''''''''''''''''''''''''''''''''''\n\nThe `base_urls` parameter specifies the domain and prefix url for the static tree, in which\nboth the production and development resources must be available and accessible from the web.\nOnly the resources that match this url, will be transformed.\n\nIt is also possible to specify a list of urls for this, in which case any of the urls\nwill be considered for matching::\n\n base_urls =\n http://127.0.0.1:6543/\n http://localhost:6543/\n http://foo.bar/\n\nOne specific case when this is needed, if the local resources may have a different domain than\nthe base url of the page in which they are referred from. In this case you simply list all the\npossible urls you may want to use during development. Specifying more does not do any harm,\nbesides making the designated resources local.\n\n\nallow_request_url: disabling to consider the url host of the current request\n''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''\n\n`allow_request_url` is by default True, meaning that *both* the domains from `base_urls` *and*\nthe domain of the current request url designate the locality of resources.\n\nIt is possible to specify `allow_request_url` as False, in which case, the use of the request\nurl is prohibited, and only the declaration `base_urls` will be considered.\n\nThis would be useful, if your portal is not at the root of domain, for example, it is served from the following\nroot url::\n\n http://127.0.0.1:6543/myportal/...\n\nIn this case you would use the following specification, which will cause `url_prefix` to be applied\n*after* the prefix you specify from `base_urls`::\n\n allow_request_url = false\n base_urls =\n http://127.0.0.1:6543/myportal\n http://localhost:6543/myportal\n http://foo.bar/myportal\n\nSpecifying `allow_request_url = false`, without also specifying `base_urls` to a sensible value, does not make sense,\nalthough it will not yield an error. The middleware will simply do nothing,\nnot being able to identify any url as local.\n\n\nSpecifying the static tree containing the resources\n\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\n\nEach resource that `gf.rejuice` handles is part of a static tree.\nBoth the development, and the production resources\nare in some static tree. This tree resides somewhere on the filesystem, and the application also\npublishes this tree somewhere in its url space. The following parameters make it possible to define\nthis tree. Both `url_prefix` and `filepath` need to be defined together.\n\nurl_prefix: specifying the url prefix of the static tree root\n'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''\n\nThe `url_prefix` parameter is an url path segment that\ndefines where the tree root is located in the application's url space:: \n\n url_prefix = /static\n\nThe above example defines that the static tree url is::\n\n http://127.0.0.1:6543/static\n\nThe `/` in the beginning (or end) of the prefix is optional, that is, the following parameters\nhave an equivalent meaning::\n\n url_prefix = /static/path\n\n::\n\n url_prefix = static/path\n\n::\n\n url_prefix = /static/path/\n\n\nfilepath: specifying the static tree root in the filesystem\n'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''\n\nThe application uses the`filepath` parameter to locate the static tree on\nthe filesystem. This must be the same static tree that is published under\nthe `url_prefix` parameter described earlier::\n\n filepath = views/static\n\nIf the path is a relative path, (does not starts with a `/`), then the path\nwill be interpreted relatively from the ini file that holds the declaration.\n\nIt is also possible to use an absolute file path::\n\n filepath = /Path/To/my/static/tree\n\nIt is also possible to specify a file path relative from a python egg::\n\n filepath = egg:my.package/views/static\n\nThe above declaration will locate the import location of the `my.package` egg,\nand locate the tree from there, using the path section that follows the egg's name.\n\nThe parameters `url_prefix` and `filepath` need to be defined together.\n\nSpecifying and extending the composition of resources\n\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\n\n`gf.rejuice` provides a simple and flexible way to define how the production (compressed)\nresources are produced from the development resources (the original sources).\n\nSpecifying the composition of resources\n'''''''''''''''''''''''''''''''''''''''\n\nA list of javascript or css resources can be specified from the configuration file.\nAnything ending with `.js` or `.css` will be considered to be a resource::\n\n default.min.js = default.js\n min/default.min.css = custom/default.css\n\nEach line contains two values here. The value on the left of the equal sign specifies the \npath of the compressed, minified resource (the result of compression). The right value specifies the\npath of original, uncompressed source (the origin of compression).\n\n\nAll file paths are applied relatively from the root of the static\ntree, specified by `url_prefix` and `filepath`.\n\n\nDerive a resource from a list of resources\n''''''''''''''''''''''''''''''''''''''''''\n\nIt is also possible to produce one resource from a list of resources,\nwhich, in that case will be compressed and concatenated to a single resource. The configuration\nallows a list of resources in multiple lines::\n\n default.min.js = \n dependency.js\n dependency2.js\n default.js\n min/default.min.css = \n a/css1.css\n b/css2.css\n custom/default.css\n\nJuicer's scheme for specifying resource dependencies from inside the resources (by using\n`@import` from css files and `@depends` from commented parts of javascript files)\nis also taken into consideration. But if such dependencies are specified from the\nresources themselves, then they do not need to be (should not be) listed from the\nconfiguration section as well.\n\n\nextend_resources: adding more static trees to the configuration\n'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''\n\nFor more flexibility, it is possible to define the resource composition from a separate\nconfiguration file section. In this case the filter section will refer to this section\nwith the `extend_resources` parameter::\n\n [filter:rejuice]\n use = egg:gf.rejuice#develjuice\n base_urls = http://127.0.0.1:6543/static\n extend_resources = juice_resources\n\n [juice_resources]\n url_prefix = /static\n filepath = views/static\n\n # Resource composition:\n default.min.js = default.js\n min/default.min.css = custom/default.css\n\n\nThe `extend_resources` option selects a section in the ini file,\nthat configures the actual resources to be considered for the transformation.\n\nInstead of a single section, a list of sections can also be specified::\n\n extend_resources =\n juice_resources_1\n juice_resources_2\n\n\nExtending resources from another configuration file\n'''''''''''''''''''''''''''''''''''''''''''''''''''\n\nFollowing the same syntax that `PasteDeploy` uses for extending its\nconfiguration, it is also possible to extend the resources from\na section residing in an arbitrary .ini file::\n\n extend_resources = config:another_config_file.ini#juice_resources\n\nThis makes it possible to separate the resource configuration for `gf.rejuice`\ninto a separate file.\n\nIn the file `my-devel.ini` the following could be entered::\n\n [filter:rejuice]\n use = egg:gf.rejuice#develjuice\n base_urls = http://127.0.0.1:6543/static\n extend_resources = config:another_config_file.ini#juice_resources\n\nWhile the referred file `another_config_file.ini` could look like this::\n\n [juice_resources]\n url_prefix = /static\n filepath = egg:my.package/views/static\n\n # Resource composition:\n default.min.js = default.js\n min/default.min.css = custom/default.css\n\n\nThe config: prefix makes it possible to refer a configuration file\nrelatively from the location of the current configuration file::\n\n extend_resources = config:another_config_file.ini#juice_resources\n\nAlternately, an absolute file path can be used as well::\n\n extend_resources = config:/Path/To/my/place/another_config_file.ini#juice_resources\n\nFinally, the configuration file can be selected relative from a python egg import::\n\n extend_resources = egg:my.package/path/to/another_config_file.ini#juice_resources\n\nInstead of a single extension section, a list of extension sections can also\nbe specified::\n\n extend_resources = \n base_resources\n more_resources\n egg:my.package/path/to/another_config_file.ini#juice_resources_1\n egg:my.package/path/to/another_config_file.ini#juice_resources_2\n\nPutting the resource declarations to a separate file makes it easier to manage them. The\nconfiguration file behaves just as expected from python configfiles or Paster configuration\nfiles. The `[DEFAULT]` section can specify a default value for the `url_prefix` and the\n`filepath` parameters, which then each section in the same file inherits, or can overwrite::\n\n [DEFAULT]\n url_prefix = /static\n filepath = egg:my.package/views/static\n\n [juice_resources_1]\n default.min.js = default.js\n min/default.min.css = custom/default.css\n\n [juice_resources_2]\n some_other.min.js = some_other.js\n ...\n\n [juice_resources_3]\n url_prefix = /static2\n filepath = egg:another.package/views/static\n\n different.min.js = different.js\n ...\n\n\nIt is also possible, just as in every python config file, to use `%(varname)` style interpolation\nanywhere inside the declarations. `%(here)` containing the full path of the current ini file, as\nwell as `%(__name__)` containing the name of the current section, are also available, just\nas usual in the Paster configuration files. \n\n\nImporting resources from another static tree\n''''''''''''''''''''''''''''''''''''''''''''\n\nIt is an important need to construct resources from another static tree than the one the final\nresource will be located in. Important use cases are: reusing the concatenation scheme of a\nresource defined elsewhere, or, making a site resource out of resources produced by separate\njavascript checkouts, or python eggs.\n\nA resource originating from another section can be specified by providing the section name,\nfollowing the resource path by one or more spaces::\n\n default.min.js = default.js othersection\n\nIn a more realistic example, the resource would typically be produced from a list\nof resources from separate sections::\n\n [main]\n url_prefix = /static\n filepath = egg:my.site/views/static\n\n default.min.js =\n jquery-1.4.4.min.js jquery_section\n jquery-ui-1.8.min.js jquery-ui_section\n default.js\n extend_resources =\n jquery_section\n jquery-ui_section\n\n [jquery-section]\n url_prefix = /static-jquery\n filepath = egg:my.jquery/static\n\n [jquery-ui_section]\n url_prefix = /static-jquery-ui\n filepath = egg:my.jqueryui/static\n\n\nNote that all the sections used as an import source, *must* also be listed in the `extend_resource`\nparameter. Failing to do so, will result in an error message.\n\nAs seen from the above example, the resources imported from another section (`jquery-1.4.4.min.js`,\nand `jquery-ui-1.8.min.js` in this case) need not be specified as resources in that\nsection. They just need to be present in the source tree.\n\nIf however the imported resources are not themselves compressed, they will be. Also, if they \ncontain further dependencies specified by `@import` or `@depends`, these dependencies will\nproperly be included in the resulting resource.\n\nIf the referenced sections contain further resource concatenation rules, they will\nbe processed as well::\n\n [main]\n url_prefix = /static\n filepath = egg:my.site/views/static\n\n default.min.js =\n jquery-1.4.4.min.js jquery_section\n jquery-ui-1.8.min.js jquery-ui_section\n default.js\n extend_resources =\n jquery_section\n jquery-ui_section\n\n [jquery-section]\n url_prefix = /static-jquery\n filepath = egg:my.jquery/static\n \n jquery-1.4.4.min.js = jquery.1.4.4.js\n\n [jquery-ui_section]\n url_prefix = /static-jquery-ui\n filepath = egg:my.jqueryui/static\n\n jquery-ui-1.8.min.js =\n ui/jquery.ui.core.js \n ui/jquery.ui.widget.js \n ui/jquery.ui.mouse.js \n ...\n ui/jquery.effects.transfer.js\n\n\nWhat will result from this configuration, that the middleware will explode every single\nresource to its development resources, recursively. Also, running `bin/rejuice myconfig.ini main`\nwill produce all resources specified in all sections, providing a complete update\nbased on the original sources.\n\nTo make the example even more realistic, let us suppose that each static tree\nhas a standalone configuration as well, which are referred from the configuration of the site.\n\n`site.ini`::\n\n [main]\n url_prefix = /static\n filepath = views/static\n\n default.min.js =\n jquery-1.4.4.min.js egg:my.jquery/juicer.ini#jquery_section\n jquery-ui-1.8.min.js egg:my.jqueryui/juicer.ini#jquery-ui_section\n default.js\n extend_resources =\n egg:my.jquery/juicer.ini#jquery_section\n egg:my.jqueryui/juicer.ini#jquery-ui_section\n\n`juicer.ini` in `my.jquery` egg::\n\n [jquery-section]\n url_prefix = /static-jquery\n filepath = views/static\n \n jquery-1.4.4.min.js = jquery.1.4.4.js\n\n`juicer.ini` in `my.jqueryui` egg::\n\n [jquery-ui_section]\n url_prefix = /static-jquery-ui\n filepath = views/static\n\n jquery-ui-1.8.min.js =\n ui/jquery.ui.core.js \n ui/jquery.ui.widget.js \n ui/jquery.ui.mouse.js \n ...\n ui/jquery.effects.transfer.js\n\n\nLocalizing images for imported css resources\n''''''''''''''''''''''''''''''''''''''''''''\n\nA valuable feature of `gf.rejuice` is the support of concatenation a single css resource\nfrom foreign css resources, that is normally\nnot supported by Juicer and hard to be achieved by Juicer alone.\n \nCss resources contain `url(...)` directives to refer to other resources, typically images.\nWhile Juicer takes care of rewriting the urls in these directives, so that the original\nresources can be located from the compressed css, the scheme will\nstop working as soon as a css file is composed from many different source trees or eggs.\n\nTo support this use case, `gf.rejuice` copies all images referenced in the compressed\ncss file, that reside in different source trees. This only happens if a css image\ncompresses from any resource from a section which has a different `filepath` than\nthe target section.\n\nFor example, in case of a following configuration::\n\n [main]\n url_prefix = /static\n filepath = egg:my.package/views/static\n default.min.css =\n other_package.css other_section\n default.css\n extend_resources = other_section\n\n [other_section]\n url_prefix = /other-static\n filepath = egg:other.package/static\n \nif we run `bin/rejuice myconfig.ini main`, the result will be \na `default.min.css` file, and a `default.min.css.images` directory,\ncreated in the same directory next to each other. The `default.min.css.images`\ndirectory will contain a copy of all the resources that `default.min.css`\nreferences.\n\nAs a consequence of this, any other sections than the main section, are only needed\nfor development mode while the middleware resolves urls to the original sources,\nand for the time when the compression is done by running `bin/rejuice`. Following\nthat, the other trees can be brought to offline as they are not needed to\nbe present in the production website at all, that operates solely on the\ncompressed resources.\n\nThis makes it possible to establish a development scheme, when the production\nwebsites contains the compressed resources only, and the library dependencies,\npresent in checked-out static trees or development eggs, are only present\nduring the time of development.\n\n\nExample use cases\n-----------------\n\nXXX\n\n\n\n\nChangelog for gf.rejuice\n========================\n\n\n0.2 (2011-03-08)\n----------------\n\n- Fix a bug in the resolver lists that prevented to resolve from any other\n resolver then the first one in the list\n [ree]\n\n- Small refactoring, fix docs \n [ree]\n\n\n0.1 (2011-03-04)\n----------------\n\n- Initial release\n [ree]",
"description_content_type": null,
"docs_url": null,
"download_url": "UNKNOWN",
"downloads": {
"last_day": -1,
"last_month": -1,
"last_week": -1
},
"home_page": "https://launchpad.net/gf.rejuice",
"keywords": "web middleware wsgi css js juicer merging minifying development",
"license": "GPL",
"maintainer": null,
"maintainer_email": null,
"name": "gf.rejuice",
"package_url": "https://pypi.org/project/gf.rejuice/",
"platform": "UNKNOWN",
"project_url": "https://pypi.org/project/gf.rejuice/",
"project_urls": {
"Download": "UNKNOWN",
"Homepage": "https://launchpad.net/gf.rejuice"
},
"release_url": "https://pypi.org/project/gf.rejuice/0.2/",
"requires_dist": null,
"requires_python": null,
"summary": "`gf.rejuice` provides additional tools for developers to use `Juicer` for the compression of Javascript and CSS resources, in the context of python web applications that run via WSGI.",
"version": "0.2"
},
"last_serial": 792395,
"releases": {
"0.1": [
{
"comment_text": "",
"digests": {
"md5": "33d32297e31585e6d075cf4eab3d0b12",
"sha256": "825e9a7fd94a52b972bb9b10fcf1ec3d6bf2cb4d80e7145a0bbbe92aa9240b9e"
},
"downloads": -1,
"filename": "gf.rejuice-0.1.tar.gz",
"has_sig": false,
"md5_digest": "33d32297e31585e6d075cf4eab3d0b12",
"packagetype": "sdist",
"python_version": "source",
"requires_python": null,
"size": 31225,
"upload_time": "2011-03-04T15:20:42",
"url": "https://files.pythonhosted.org/packages/5a/4b/8b1f6a14981942f14b467780875f32b3c2663222ef795c1268762c7ec201/gf.rejuice-0.1.tar.gz"
}
],
"0.2": [
{
"comment_text": "",
"digests": {
"md5": "8aefad28d56521b0c237df17a2d4892a",
"sha256": "84ea5957504e6bec151f62b7c1653e550c2652a6411b2f42dab88ac3e7fb7bd7"
},
"downloads": -1,
"filename": "gf.rejuice-0.2.tar.gz",
"has_sig": false,
"md5_digest": "8aefad28d56521b0c237df17a2d4892a",
"packagetype": "sdist",
"python_version": "source",
"requires_python": null,
"size": 32194,
"upload_time": "2011-03-08T12:14:15",
"url": "https://files.pythonhosted.org/packages/c4/be/c4550971c77017d8286a688cf789b92c20bfa3e8fbc67fa65d8c97e295be/gf.rejuice-0.2.tar.gz"
}
]
},
"urls": [
{
"comment_text": "",
"digests": {
"md5": "8aefad28d56521b0c237df17a2d4892a",
"sha256": "84ea5957504e6bec151f62b7c1653e550c2652a6411b2f42dab88ac3e7fb7bd7"
},
"downloads": -1,
"filename": "gf.rejuice-0.2.tar.gz",
"has_sig": false,
"md5_digest": "8aefad28d56521b0c237df17a2d4892a",
"packagetype": "sdist",
"python_version": "source",
"requires_python": null,
"size": 32194,
"upload_time": "2011-03-08T12:14:15",
"url": "https://files.pythonhosted.org/packages/c4/be/c4550971c77017d8286a688cf789b92c20bfa3e8fbc67fa65d8c97e295be/gf.rejuice-0.2.tar.gz"
}
]
}