While pondering the many thoughts I have about Drupal, I came with this one.

  • The jQuery interface module should contain the sources of each component, not the packed version.
  • The jQuery interface module should contain a copy of dean edward's packer
  • Modules should add individual components of the interface library to the queue be calling a function
  • Interface library's dependencies should be hard-coded
  • In hook_exit, the fun part happens:
    • First, it fetches the array of components to be loaded
    • Then, we do a ksort on the array
    • We serialize it, and MD5 the serialization
    • We check if there is a JS file by the name of the MD5 in our module's dir
      • If there is, we just drupal_add_js that
      • Otherwise, we call our duplication of _phptemplate_render for each file
      • Then we pack them all together
      • Save a file of that
      • And use drupal_add_js

I will work on a patch in a bit.

Comments

jjeff’s picture

jjeff commented
Title: My grand vision » Aggregate and pack Interface components

That is a grand vision! And if you've got energy to code it, by all means do!

I see a few problems with your plan. Hopefully these tips will save you some time:

1) You will not be able to save the MD5-named files to the module directory. PHP will not have permissions to this directory. However, you can save (a subdirectory of) the files directory. Take a look at the way that this is handled by the CSS aggregator in Drupal 5 for an example: http://api.drupal.org/api/5/function/drupal_build_css_cache

2) You'll probably want to use hook_footer() rather than hook_exit(), this way you can still write to the page afterwards. hook_exit() fires after the page has already been rendered and displayed.

3) Keep in mind that there will/could be a JS aggregator in Drupal 6. There might be some code floating around that you could snag to use. I don't know that it's Edwards-enabled though. :-)

4) You'll find further frustration because the PHP port of Dean Edwards' Packer is LGPL and not GPL (close but no cigar), and we won't be able to include it in the module download. We'll need to do some checking to see if the library is in place and if it's not, display an error and link off to the download. See how I did this for the sIFR and TinyMCE modules.

5) Some other random thoughts: John Resig tells me that there's a smaller/faster/more-efficient version of Interface coming out soon. Let's say that the new file is 50K. This is a one-time download -- the browser will cache this file reuse it for subsequent page loads. If there are several modules all using different parts of Interface in different ways on different pages, you could actually end up serving many different medium-sized packages of the components over many pages, rather than just the one (not that) large one once. That said, this is the way that the D-5 CSS aggregator works, so you could certainly argue that there's a precedence.

I certainly don't mean to discourage you, but I just wanted to make sure that you know what you're getting into.

Some more discussion: http://groups.drupal.org/node/3576

ipwa’s picture

ipwa commented
Issue summary: View changes
Status: Active » Closed (outdated)