> In my prototype it is a random string generated once at startup. So > this is the same for all css/js references. But this is imposed just > by the default implementation of the LiftRules.attachResourceId > function. A different implementation can generate unique MD5 sequences > based on each individual file. But I'm not convinced that this should > be on the framework side.
>From a high level perspective, I think a framework should (in order) 1) Provide flexibilty to do what users want 2) Provide the best defaults possible, with the least surprises and best performance such that all users don't have to reinvent the same wheel. [...] > 1. Detect when files changes ... for that we'd need a polling > mechanism as we wouldn't want hash calculation on each page rendering. > 2. Maintain the hash cache I think it should be sufficient to do this once per app restart. > Personally I do not think this is an imperative thing for the > framework. I think it is more important for Lift to allow the > flexibility to apply this type of logic and this is what I'm aiming > to. Agreed cf. the above. > Furthermore if one of the committers wants to add this MD5 logic after > this support is in, he can certainly do it. If no one beats me to it, I'll have a look at some point, but really busy now with other stuff >To me the proper > abstraction in allowing that is more important right now. Yep /Jeppe -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
