AndreaSterbini had the idea in UseTemplatesEverywhere to split up the template files and move them into the TWiki.TWiki web.
The idea here is to introduce special scripts to maintain templates. These scripts need to be protected by AuthenticationBasedOnGroups (once implemented) so that only TWiki administrators can edit them. I don't think that template files need to be viewed, in fact if you would view a template file you would get nested <HTML> and <HEAD> tags which is not legal HTML. Andrea might have had the idea of splitting up the template files because of this.
Functionality to maintain template files:
The same feature could also be used to edit the Perl scripts, but that is a somewhat scary story.
-- PeterThoeny - 03 Sep 2000
PeterThoeny ModularTemplates has some interesting stuff relating to this. -- TravisBarker -16 Mar 2003 This is a really good idea. I am pushing my company to make our TWiki installation run by our operational guys. For them to accept this I have to assure them that we do not need filespace access to the server; your idea here would really help. -- MartinCleaver - 30 Mar 2001
I'm not sure, but I suspect that this is a serious security issue, especially if wiki security is not as stringent as site security This would not be unusual, because the Wiki style of editing freedom is not notably secure. For example a site might be happy with unencrypted logins for the wiki, but allow no access from off-site at all otherwise. It is especially dicy for updating the Perl scripts. -- HendrikBoom - 31 Mar 2001
I do agree that I would not want access to the scripts as this would be seen as a software upgrade. I would want access to the templates only accessible to a TWikiTemplateGroup or similar. -- MartinCleaver - 01 Apr 2001
The security concerns above are alleviated by TWiki's AuthenticationBasedOnGroups ... This idea can proceed now that there's a working security framework. A web-based means of adding new categories for pages is a win, no matter if it involves editing twikicatitems or simply adding a new category to a form and submitting it. -- PaulReiber - 07 Apr 2001
Would it be possible to have topics such as WebViewTemplate and WebEditTemplate that contained the templates for edit and view for the current web? The security concerns would disappear once the security lists for any given page would be held as meta data. -- MartinCleaver - 24 May 2001
Even simpler than my previous idea, why not have a special topic, say TWikiTemplates in each web and a TWikiDefaultTemplates in the TWiki web that has the templates (*.tmpl) as attachments? That would require very little coding and would be editable by whoever could edit the topic. The one thing that would need caution if someone uploaded a broken template, until attachments become under revision control. -- MartinCleaver - 07 Jun 2001
My main concern is to avoid any FilespaceAccess to our server running TWiki. Our PowerUsers are pretty competant, they read the documentation and they will spend the time working out exactly what the Template files (both presentation templates and category tables) they need to upload should look like. I want to give them WebAccess to the areas they administer on TWiki such that I don't need to be involved. I think I understand what you say in (1). You are saying that both categories and presentation templates are Templates (stored in /twiki/templates) and that categories would be best edited using a wizard. (If so, I agree that it would be nice to have a tool, but my PowerUsers can work out the syntax). (2) has left me a bit flummuxed - as given the example of TWikiPreferences, I believe that we do keep special topics in TWiki06x01. -- MartinCleaver - 07 Jun 2001
It's certainly true that TWikiPreferences works this way, but templates don't at present and I think the template model is cleaner. I guess I'm lucky that file level access (via unix and Samba) isn't a problem for me. Still doing this as attachments certainly is simple from an implementation point of view and could be made safer by a new script that uses no templates and can reverse most recent templates changes to get back to a stable system. -- JohnTalintyre - 08 Jun 2001
Okay, so if I implement HTML templates as attachments to WebViewTemplate I will need the latest version of an attachment. Is there an API call that I can use to get the attachment, that uses the latest version if there are multiple versions? Thanks. -- MartinCleaver - 10 Jun 2001
There isn't a different call for this at present, however it would be good to change existing method to allow this. The latest version is in the pub directory and could be read via Store::readFile. I would think best bet would be to alter the Store::readTemplate method, could go for attachment and if not present could go for normal area. -- JohnTalintyre - 11 Jun 2001
I've been thinking recently about templates as (special) topics, and fullblown skins as (special) webs. To this end I simply though "What happens if we try symlinking all the templates into a data directory?" The result was encouraging - things largely just worked as you'd probably want them to. A few gotchas to work out:
Using the skin in another web is then just a matter of replacing the templates directory with a link to the skins' template directory. (Which the also effectively means that skins sit in directories which it looks like people have been asking for)
Also a nice side effect is that creating a new skin based on an old one becomes simpler - you can simply use the existing add/clone web
functionality, and then go from there.
Me neither. Not at all.
This is the intent behind my method. On my Twikis I use the layout I describe in data and code separation. This makes web creation simple:
An admin won't want to edit templates. Full stop . They might want to pick a nice one, or not bother if the default looks nice, but they'll rarely want to. Users do. Imagine a hypothetical situation whereby Twiki grows from being used by one user in one dept in a company to being seen by most users in lots of depts. The people who run their own web say "can I create our own look"? You could say no, but that's not ideal at all. Des the admin want to grant a sales person access to the company webserver simply to edit templates? In my experience the answer is an emphatic no. Sales people are paid to be good at selling, not to be good at not breaking the company webserver. Does the admin want to edit the templates for them ? Again, absolutely not. Do they even want to get involved in a big way? No - an admin friendly system is one they set up, and then the users go away, happily use the system, and only come back if things break, preferably very rarely. If however a collection of templates is kept in a web, and edittable in that web, then our actions end up being quite simple:
I sure as heck don't want to design a skin using textarea, but it would be awfully nice to be able edit a template in one (as opposed to: download to local machine, edit, upload, test; lather, rinse, repeat). Especially for things like fixing spelling mistakes, changing the web background colour, etc. -- MattWilkie - 26 Jun 2003
- The
viewtemplatescript shows the directory list of templates. Has also links to subdirectories, similar to the index page of a directory where theindex.htmlfile is missing. The script has an edit and delete link for each file, and an edit field to add the name of a new template file. - The
edittemplatescript is to edit a template, it looks similar to theeditscript, except that it has just a [ save ] button, no [ preview ]. - Simply use TWiki itself to check the result of a change you did.
- The
deletetemplatescripts deletes a file after confirmation. (Confirmation can be done with theoopsscript.)
viewtemplate script: (FYI, links do not work)
| TWiki Template File Maintenance |
PeterThoeny ModularTemplates has some interesting stuff relating to this. -- TravisBarker -16 Mar 2003 This is a really good idea. I am pushing my company to make our TWiki installation run by our operational guys. For them to accept this I have to assure them that we do not need filespace access to the server; your idea here would really help. -- MartinCleaver - 30 Mar 2001
I'm not sure, but I suspect that this is a serious security issue, especially if wiki security is not as stringent as site security This would not be unusual, because the Wiki style of editing freedom is not notably secure. For example a site might be happy with unencrypted logins for the wiki, but allow no access from off-site at all otherwise. It is especially dicy for updating the Perl scripts. -- HendrikBoom - 31 Mar 2001
I do agree that I would not want access to the scripts as this would be seen as a software upgrade. I would want access to the templates only accessible to a TWikiTemplateGroup or similar. -- MartinCleaver - 01 Apr 2001
The security concerns above are alleviated by TWiki's AuthenticationBasedOnGroups ... This idea can proceed now that there's a working security framework. A web-based means of adding new categories for pages is a win, no matter if it involves editing twikicatitems or simply adding a new category to a form and submitting it. -- PaulReiber - 07 Apr 2001
Would it be possible to have topics such as WebViewTemplate and WebEditTemplate that contained the templates for edit and view for the current web? The security concerns would disappear once the security lists for any given page would be held as meta data. -- MartinCleaver - 24 May 2001
Even simpler than my previous idea, why not have a special topic, say TWikiTemplates in each web and a TWikiDefaultTemplates in the TWiki web that has the templates (*.tmpl) as attachments? That would require very little coding and would be editable by whoever could edit the topic. The one thing that would need caution if someone uploaded a broken template, until attachments become under revision control. -- MartinCleaver - 07 Jun 2001
- The editing of categories is the one template area I'm keen to see editable and I think it cries out for form based editing.
- Having templates as attachments to a specific topic does make a fair amount of sense, but at present they mostly live outside any web, and unless we have a hierarchy of Webs it will be odd to have the defaults on a special topic in TWiki06x01.
My main concern is to avoid any FilespaceAccess to our server running TWiki. Our PowerUsers are pretty competant, they read the documentation and they will spend the time working out exactly what the Template files (both presentation templates and category tables) they need to upload should look like. I want to give them WebAccess to the areas they administer on TWiki such that I don't need to be involved. I think I understand what you say in (1). You are saying that both categories and presentation templates are Templates (stored in /twiki/templates) and that categories would be best edited using a wizard. (If so, I agree that it would be nice to have a tool, but my PowerUsers can work out the syntax). (2) has left me a bit flummuxed - as given the example of TWikiPreferences, I believe that we do keep special topics in TWiki06x01. -- MartinCleaver - 07 Jun 2001
It's certainly true that TWikiPreferences works this way, but templates don't at present and I think the template model is cleaner. I guess I'm lucky that file level access (via unix and Samba) isn't a problem for me. Still doing this as attachments certainly is simple from an implementation point of view and could be made safer by a new script that uses no templates and can reverse most recent templates changes to get back to a stable system. -- JohnTalintyre - 08 Jun 2001
Okay, so if I implement HTML templates as attachments to WebViewTemplate I will need the latest version of an attachment. Is there an API call that I can use to get the attachment, that uses the latest version if there are multiple versions? Thanks. -- MartinCleaver - 10 Jun 2001
There isn't a different call for this at present, however it would be good to change existing method to allow this. The latest version is in the pub directory and could be read via Store::readFile. I would think best bet would be to alter the Store::readTemplate method, could go for attachment and if not present could go for normal area. -- JohnTalintyre - 11 Jun 2001
I've been thinking recently about templates as (special) topics, and fullblown skins as (special) webs. To this end I simply though "What happens if we try symlinking all the templates into a data directory?" The result was encouraging - things largely just worked as you'd probably want them to. A few gotchas to work out:
- Rendering of templates when viewed resulted in TWiki markup in the template getting marked up/replaced, ideally it should be treated more like verbatim. Wrapping the %TEXT% with <verbatim> in a special view skin in this web didn't result in the text not being parsed. ie skin looked crap in, but worked
- When saving since there's no idicator to twiki fields got added, adding a nice header to the top of each page ever after.
- Mark in WebPreferences which topics are templates. (preferably as a pattern match)
- Suppress writing of META tags to templates. or
- Write copies without the META tags to the templates directory
- Automatically change to a verbatim style text for template/skin pages.
# ls *tmpl|perl -e 'while (<>){chomp; $a = $_; s/.tmpl$//g; \
s/^(.)(.*)/uc($1)."$2"/e; s/\./DOT/g; s/$/Template.txt/; $f=$_; \
$l=`pwd`; chomp($l); print "ln -s $l/$a ../data/$f\n"; uc("a")}'
| Topic | template |
|---|---|
AttachTemplate.txt AttachagainTemplate.txt AttachnewTemplate.txt ChangeformTemplate.txt ChangesTemplate.txt EditDOTiejsTemplate.txt EditTemplate.txt GenhtmlTemplate.txt MailnotifyTemplate.txt MoveattachmentTemplate.txt OopsaccesschangeTemplate.txt OopsaccessgroupTemplate.txt OopsaccessrenameTemplate.txt OopsaccessviewTemplate.txt OopsauthTemplate.txt OopsbadpwformatTemplate.txt OopschangepasswdTemplate.txt OopsemptyTemplate.txt OopslockedTemplate.txt OopslockedrenameTemplate.txt OopsmissingTemplate.txt OopsmoreTemplate.txt OopsmoveerrTemplate.txt OopsnoformdefTemplate.txt OopsnotwikiuserTemplate.txt OopsnowebTemplate.txt OopspreviewTemplate.txt OopsregexistTemplate.txt OopsregpasswdTemplate.txt OopsregrequTemplate.txt OopsregthanksTemplate.txt OopsregwikiTemplate.txt OopsrenameerrTemplate.txt OopsresetpasswdTemplate.txt OopsrevTemplate.txt OopssaveTemplate.txt OopssaveerrTemplate.txt OopssendmailerrTemplate.txt OopstopicexistsTemplate.txt OopsuploadTemplate.txt OopswrongpasswordTemplate.txt PreviewTemplate.txt RdiffTemplate.txt RegisterTemplate.txt RegisternotifyTemplate.txt RenameTemplate.txt RenamebaseTemplate.txt RenameconfirmTemplate.txt RenamerefsTemplate.txt SearchTemplate.txt SearchbookviewTemplate.txt SearchformatTemplate.txt SearchmetaTemplate.txt SearchrenameviewTemplate.txt TwikiTemplate.txt ViewDOThideformTemplate.txt ViewDOTplainTemplate.txt ViewDOTplainnoextrasTemplate.txt ViewDOTprintTemplate.txt ViewDOTrawTemplate.txt ViewDOTrssTemplate.txt ViewDOTsimpleTemplate.txt ViewDOTverbatimTemplate.txt ViewTemplate.txt | attach.tmpl attachagain.tmpl attachnew.tmpl changeform.tmpl changes.tmpl edit.iejs.tmpl edit.tmpl genhtml.tmpl mailnotify.tmpl moveattachment.tmpl oopsaccesschange.tmpl oopsaccessgroup.tmpl oopsaccessrename.tmpl oopsaccessview.tmpl oopsauth.tmpl oopsbadpwformat.tmpl oopschangepasswd.tmpl oopsempty.tmpl oopslocked.tmpl oopslockedrename.tmpl oopsmissing.tmpl oopsmore.tmpl oopsmoveerr.tmpl oopsnoformdef.tmpl oopsnotwikiuser.tmpl oopsnoweb.tmpl oopspreview.tmpl oopsregexist.tmpl oopsregpasswd.tmpl oopsregrequ.tmpl oopsregthanks.tmpl oopsregwiki.tmpl oopsrenameerr.tmpl oopsresetpasswd.tmpl oopsrev.tmpl oopssave.tmpl oopssaveerr.tmpl oopssendmailerr.tmpl oopstopicexists.tmpl oopsupload.tmpl oopswrongpassword.tmpl preview.tmpl rdiff.tmpl register.tmpl registernotify.tmpl rename.tmpl renamebase.tmpl renameconfirm.tmpl renamerefs.tmpl search.tmpl searchbookview.tmpl searchformat.tmpl searchmeta.tmpl searchrenameview.tmpl twiki.tmpl view.hideform.tmpl view.plain.tmpl view.plainnoextras.tmpl view.print.tmpl view.raw.tmpl view.rss.tmpl view.simple.tmpl view.verbatim.tmpl view.tmpl |
functionality, and then go from there. - This implies it's better to copy templates from
datatotemplatesrather than symlink.
repRev command (which entails losing your latest revision unfortunately).
-- MattWilkie - 25 Jun 2003
An alternative might be to hold the templates as attachments to a set of suitably named topics, which, incidently could hold documentation/discussion.
This would have the advantage that the templates would not need verbatim tags around them, would guarantee no wiki-type interpolation and would be as fast as the attachment delivery system and still be subject to version control.
The only disadvantage I can see would be that to edit them people would have to upload/download the attachment; but: - this could be cured with a nice-to-have attachment PageType editor system.
- people tend to edit sets of templates together anyway
- I'm sure I read a Support response about 3 months ago saying that the latest alpha had facilities for uploading directory-full loads of files in bacthes
- The method I propose already works with a minor quirk that's easy to resolve in a couple of ways.
- The method you propose I can already do (did actually), using a patch I wrote around 18 months back but I disliked the download, upload aspect. (You lose immediacy/typo checking/resolving)
Me neither. Not at all.
- Why on earth would any admin want to edit templates in that awful textarea widget?
- Sure: it's an entertaining exercise to edit the edit template in the edit box. But I find it hard to believe, that this mingling of levels is easy for non-programmers
- And the versioning of TWiki is not suitable for this: it's just on file level. To manage sets of files, TWiki just doesn't cut it. Even RCS/SCCS on the command-line would be hard for this. You need at least CVS, really
- Merging customisations with new releases in a TWiki web -- anybody wants to do that?
This is the intent behind my method. On my Twikis I use the layout I describe in data and code separation. This makes web creation simple:
- cp -R _default Newweb
- Upsides: This copies all the templates, default data, local tutorials, attachments in one go.
- Downside: I need a new _default web for each skin I use to make this truly trivial.
An admin won't want to edit templates. Full stop . They might want to pick a nice one, or not bother if the default looks nice, but they'll rarely want to. Users do. Imagine a hypothetical situation whereby Twiki grows from being used by one user in one dept in a company to being seen by most users in lots of depts. The people who run their own web say "can I create our own look"? You could say no, but that's not ideal at all. Des the admin want to grant a sales person access to the company webserver simply to edit templates? In my experience the answer is an emphatic no. Sales people are paid to be good at selling, not to be good at not breaking the company webserver. Does the admin want to edit the templates for them ? Again, absolutely not. Do they even want to get involved in a big way? No - an admin friendly system is one they set up, and then the users go away, happily use the system, and only come back if things break, preferably very rarely. If however a collection of templates is kept in a web, and edittable in that web, then our actions end up being quite simple:
- To create a new web: cp -R _default Newweb
- To create a new collection of templates for modification: cp -R _defaultSkin NewSkin
I sure as heck don't want to design a skin using textarea, but it would be awfully nice to be able edit a template in one (as opposed to: download to local machine, edit, upload, test; lather, rinse, repeat). Especially for things like fixing spelling mistakes, changing the web background colour, etc. -- MattWilkie - 26 Jun 2003
Topic revision: r22 - 2005-07-21 - JaimeHernandez
Site map
Blog web
Create New Topic
Index
Search
Advanced search
My topics of interest
Changes
Major changes only
All tags
Notifications
RSS Feed
Statistics
Preferences
Community 
Readme first
Developers News
How you can help
Community roles
#twiki IRC
Lima Release
Feature Proposals
Bugs Changes
Categories 
Account 
Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.Copyright © 1999-2026 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.