Re: Javascript trigger design
Am 28.11.2014 um 00:04 schrieb Thomas Goirand:
> Hi,
>
> Web application have evolved into monsters that needs lots of
> javascript. It's very common that these javascript applications are
> collecting all the .js library they use, concatenate them into a single
> file, and compress the result using all sorts of tools (node uglify is
> one of the implementation, but that's not the only one).
>
> As much as possible, as good Debian citizens, we do package each and
> every javascript library into a separate package. But then, if there's
> an update of that JS library, the Web application package has to somehow
> know about it, and redo the concatenate & compress job. Otherwise, the
> web app would continue to use the old version.
>
> I have this issue with the OpenStack dashboard (ie: Horizon), but also
> with a second web app which I'm currently packaging (OpenStack Fuel,
> which is a deployment software for OpenStack). Though this could of
> course be generalize to any JS app.
>
> It's been a long time I've been thinking about it, and I believe that
> the only way to do this, would be to use triggers. Though I have never
> used triggers, and I thought it was a good idea to ask my DD friends and
> this list about it. Should there be one trigger per web app? How would
> this work?
>
> Thoughts anyone? Jonas maybe, who did lots of JS packaging?
At least the Ruby On Rails framework notices an updated JS and will
re-compress the whole JS blob from its parts. I don't know about other
server side frameworks, but they _should_ be able to do the same. - ? Or
there shoould be some switch or some additional plugin or such that
enables the same functionality.
Or do I missunderstand you?
*t
Reply to: