create new tag
, view all tags
Wouldn't it be handy if we would have a pub dir with js files to include, instead of putting javascript verbatim in templates?

-- ArthurClemens - 20 Aug 2005

you mean kinda like makeing the templates directory an administrative web? just simply not a TWikiMarkup based one....?

-- SvenDowideit - 21 Aug 2005

Uhh? I mean put the javascript out of the templates into .js files that can be included.

-- ArthurClemens - 21 Aug 2005

if you attach it to a topic, it will be in the pub directory

-- WillNorris - 22 Aug 2005

BTW, JavaScript can now be safely included in topic text (it is protected from mangling by TWiki).

I think Arthur has a good idea, for several reasons.

  1. Performance. Putting stuff in other files gives the browser a chance to cache it, far more effectively than is possible with rendered content.
  2. Customisation. It's easier to get your head around javascript in a separate file, and it's easier to debug as well.
  3. Encapsulation. From a purely architectural perspective, the content templates are already way too complex.

-- CrawfordCurrie - 22 Aug 2005

Because the files don't belong to a topic, the javascript dir should be in the root of pub. For example: /pub/js/

-- ArthurClemens - 22 Aug 2005

why can't they belong to a topic? eg, something in the TWiki web, even if it's a new topic to contain the TwistyIncludes JavaScript? i don't favor adding a /pub/js directory (it's not orthagonal to the rest of the directory structure---i was glad when you eliminated the /pub/icn directory, for example, and attached those icons to topics)

-- WillNorris - 22 Aug 2005

A topic would be possible if managing the script attachments is secured, i.e. not changed by others than TWikiAdminGroup.

-- ArthurClemens - 22 Aug 2005

Don't mix javascript of skins with javascripts of TWikiApplications. Javascript that supports a skin do belong to the templates. There are different javascript requirements per action (save, renamemove, etc). The obvious way to encapsulate javascripts is to collect it into a defaultjavascript.tmpl, and optional <action>javascript.tmpl. This will ease subtemplating also and allow to deal with the different checkAll()s (urgs) inlining only a limited amount of data. Inlined javascript is not a performace problem (if at all measuarable). It enables serverside caching along with its html. If the client cache gets proper html headers then the complete page is found in the browsers cache including the javascript. TWikiApplications should put their javascript into dedicated javascript topics.

-- MichaelDaum - 22 Aug 2005

I always thought that TWiki pages are not cached.

-- ArthurClemens - 23 Aug 2005

if templates become topics (just not TML based ones) then the js files would belong to them as attachements. These template topics would be in a web that would generally not be edited by anyone (readonly / admin only), but would make distributing skins easier - as it would be the same as any other topic based TWikiApplication.

-- SvenDowideit - 23 Aug 2005

Sven is right; if templates were topics. Of course they are not currently, but all it would take would be someone brave enough to translate the templates directory into topics (a twenty-minute job, IMHO).

Of course you have to be aware of the differences; a topic read and rendered as a viewed topic goes through a different rendering pipeline to a topic read and rendered as a template. It is this difference that has made me reluctant to make the switch in the past. Before you ask, it would be a major piece of work to make the rendering pipelines the same (it's about this point I usually start thinking about TemplateToolkit again).

Anyway, the point is that attaching JS files to topics is the right way to go.

Michael, inlined Javascript is a performance problem, if the HTML it is contained in is not cached. Pages change much more rapidly and completely than Javascript files, so will be invalidated from the cache that much more often.

-- CrawfordCurrie - 23 Aug 2005

JS as attachments: this will floor performance if attachments go thru viewfile for security reasons. Then each page goes thru one fresh TWiki engines per attachment, afaik, which is very bad anyway. Crawford, frankly, I do not belief you. About how much javascript are we talking? Inlining javascript or not is not significant to performance which is dominated by other issues. There's lots of html that does not change per request.

-- MichaelDaum - 23 Aug 2005

why would you secure template attachements to force them through viewfile? that would be quite silly wouldn't it?

Michael, it sounds to me like you're focusing on a corner case.

and i do agree with Crawford.. though seeing actual figures would be interesting

just to be explicit - although i want templates and their attachemts to be in an admin / config web, this does not mean that they would have to be accessed directly, rather that the TMPL would be able to INCLUDE the attached text OR use a URL to allow the browser to get it as a seperate file.

  • How would this work, practically? -- ArthurClemens - 23 Aug 2005
    • exactly like it does now (basically, its a mv templates data/_templates, and then we add syntax like TMPL::INCLUDE{THISPUBDIR/someinline.js}, and similar for referenceing the URL to do client side (as CDot said, its trivial to implememnt, just time consuming to test & verify) -- SD

-- SvenDowideit - 23 Aug 2005

I don't have figures, I'm just mentally counting up the rocks on the road, like everyone else. If everything is going through viewfile then yup, that would be a real killer. I was assuming direct access, such as you get when you refer to the JS by a full URL. As for the amount of Javascript, well, Kupu editor has about 350K (bytes). That's obviously an extreme example.

-- CrawfordCurrie - 23 Aug 2005

Changed the classification of this topic to FeatureRequest for DakarRelease.

-- ArthurClemens - 24 Aug 2005

Edit | Attach | Watch | Print version | History: r15 < r14 < r13 < r12 < r11 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r15 - 2005-09-09 - WillNorris
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.