And that leads to the whole question of serving size. While the CSS document totals out at 16kb after it's generated, having the system regenerate it over and over again seems foolish, unless there was a compelling reason, like, say, using the current actual time of day to define the base color and then having math define all the other colors of the scheme.
Still, the resulting file is small, and having read and reread the documentation on Django, i keep reading that the system is faster when not cached - is this right? If so, it's a no-brainer to go ahead with this experiment, and if not, it's just a bit more testing of the load placed on the system before going live.
Either way, tho, I would think you could tie the css/js files that Django serves out to the web server rather than individual end-users. That's what is recommended with CSS and media files anyway. Just move the CSS generation a step back from the Django-served documents and have Django only serve it to the actual webserver it's running aside.
To illustrate, in the template you'd have
<link rel="stylesheet" href="" type="text/css" />
and you'd have an app with models based on colors or elements of your choice, predefined or designed with math already. When the end-users' browser asks for the file, Apache (or whatever web server is used) goes "I have that, it's right here" and hands it off, never realizing that in the background Django created that file on the fly. The end result is what you want - dynamic css served in such a way that the caching of the end-user's browser is still in effect, provided that the apache request has a sessionID that Django uses to create/maintain/recreate the CSS with.
So how about it? SessionID work for this?
On 7/21/06, Tyson Tate <[EMAIL PROTECTED]> wrote:
On Jul 21, 2006, at 3:19 PM, [EMAIL PROTECTED] wrote:
> I'm thinking about making a simple _javascript_ and CSS manager that
> would look like this:
> - It generates one _javascript_ and one CSS file for a current
> page/template
This could get ugly fast when you take into account CSS cascading.
CSS is heavily code-order dependent and breaks easily when your
various styles are in different orders. Conditional-comment-included
IE6 hack files usually must come last in the load order. How would
you ensure that the order the files are compiled are correct? I'm no
JS expert, but I imagine that could be a PITA, too.
> - It uses a database or a pickle/shelve/flat files (?) to store code
> snippets: id, code, comment, show_always
How would this impact the designer? Remember: Django has a nice
separation between programmer and designer which allows designers to
style pages and write HTML without knowing the intricacies of what's
going on on the programmer's side of things. Adding the CSS/JS
manager would break this separation and require designers to waste
time getting their code in to the database and ensuring that the
order is correct etc etc.
Breaking the designer's process is a big no-no! We've got enough on
our hands with programming for broken browsers without the extra work.
> - Extra code snippets can be added dynamicaly in the template,
> something like:
> <link rel="stylesheet" href="" type="text/
> css" />
> which would add code snippets with ids: 14, 52 etc.
As Jay mentioned, this kills CSS and JS caching. CSS and JS caching
is an important part of keeping sites fast. Imagine a site that gets
2,000 visitors in a day. Every visitor loads, on average, 5 pages.
All pages include the same 2 CSS files and 3 JS files for a total of
100k (they're using crazy AJAX libraries, perhaps).
Under the flat-file storage method, each user would load 100k once
and only once, unless they manually hit refresh. That would be a
total of 200mb of CSS and JS and 10,000 flat-file calls. Under your
proposed method, users would, in the space of five pages, potentially
load as much as 500k in CSS and JS and cause as many as 10 dynamic
content-generation calls. For 2,000 users in a day, that would be
over 900mb of CSS and JS and 20,000 extra dynamic content-generation
calls. Ouch!
Of course, this shouldn't prevent you from implementing your idea. I
just don't see this sort of idea ever being truly feasible for a
production site.
Regards,
Tyson
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/django-users
-~----------~----~----~----~------~----~------~--~---
