Well, I've read the topic CommonHeaderFooterTemplate and now propose still MoreCommonHeaderFooterTemplate.
As I mentioned in NationalCharTokenClash, I'm currently working on Korean version of TWiki. For that, I must make HTTP header say "charset=euc-kr" in /bin/* executables and substitute "charset=us-ascii" into "charset=euc-kr" in the HTML head section of many template files. I'm not sure if both these changes are necessary, but at least, the second is inevitable for 2-byte charset users. Plus that, I added stylesheet tags into HTML head section. That will be easier with head section defined in twiki.tmpl and other templates just include TMPL:p{"htmlheadsection"} or something like that.
I hope I can contribute to TWiki with my own enhancement, not only words, someday. (Not now, though:)
-- JikhanJung - 02 Nov 2001
This would help building TWikiSkins as well. -- MattWilkie - 02 Nov 2001
One solution is to redfine what a skin is allowed to do rather than make a series of pathes. What I'm working on with my OO model is to have a skin not be a set of files but an object that describes how the topic is to be rendered. The charset should not be a part of the skin but of the overall system configuration. So the rendering object asks the skin object:
Can you expand on this? -- ArthurClemens - 30 May 2003 This might be the wrong place to mention it, but the OOPS templates seem awfully redundant, too. Shouldn't there be just one OOPS template which reads various TWiki Topics depending on the condition? Some of the OOPS templates already grab TWiki Topics. Why not go the extra mile and get rid of most of the OOPS templates completely? -- TomKagan - 30 May 2003 Can I expand on this? Yes, and I hope to. However there are some things that are like .... a bundle of sticks. You can snap each stick seperately. Nind them together like the 'Eagle' or standard of the old Roman Legions which were supported by a tightly bound bundle of sticks. The legionaires were taught that if the stuck togehter like that bundle they were unbreakable. A design is like that too. If I were just to post about the
This would help building TWikiSkins as well. -- MattWilkie - 02 Nov 2001
One solution is to redfine what a skin is allowed to do rather than make a series of pathes. What I'm working on with my OO model is to have a skin not be a set of files but an object that describes how the topic is to be rendered. The charset should not be a part of the skin but of the overall system configuration. So the rendering object asks the skin object:
- I have a topic of this type amd this language, are there any style sheets I need to put in the header?
- I have a topic of this type and this language, are there any more
METAstatements that I need to put in the header? - I have a topic of this type and this language, are there any pieces of script I need to include?
- I have a topic of this type and this lanuage, can I please have the body template.
Can you expand on this? -- ArthurClemens - 30 May 2003 This might be the wrong place to mention it, but the OOPS templates seem awfully redundant, too. Shouldn't there be just one OOPS template which reads various TWiki Topics depending on the condition? Some of the OOPS templates already grab TWiki Topics. Why not go the extra mile and get rid of most of the OOPS templates completely? -- TomKagan - 30 May 2003 Can I expand on this? Yes, and I hope to. However there are some things that are like .... a bundle of sticks. You can snap each stick seperately. Nind them together like the 'Eagle' or standard of the old Roman Legions which were supported by a tightly bound bundle of sticks. The legionaires were taught that if the stuck togehter like that bundle they were unbreakable. A design is like that too. If I were just to post about the
Skin Object it would contribute
little. I'd need to post about all the object and their relationships and interactions for it
to make sense and for it to represent a coherent whole.
I have that vision of all this in my head and in UML and relationship diagrams and I'm
writing it up and illustrating it. (I beamon that RRose can't generate Perl!)
In due course I'll post it here. Its a lot. I'm already well over 200k of .txt and only
about 1/3 of the way through the write-up.
Plus there are diagrams and charts and illustrative code.
I was brought up to work a design out thoroughly before coding.
That's my discipline and its proven very sucessful for me in the past.
I'll discuss bits here and there. Many of the ideas and suggestions
in this forum, the "demands" - light and heavy - for improvements and the
critique of design limitations have been considered. Compatability with
the exisiting topic base will be a requirement of the inital version, but there
will be presure to upgrade in order to benefit from the performance enhancements
and to allow the additional features to be realized.
Since posting all I will have will swamp Codev, I hope Peter will allow me to set up a new web,
some "The Next Generation" theme in keeping with my Star Trek and "The Stars My Destination"
comments elsewhere.
-- AntonAylward - 30 May 2003
It would be interesting to see if the interface efforts (PatternSkinCodeChanges) and your OO set up can make a match in the near future.
-- ArthurClemens - 30 May 2003
Anton, I don't think compatibility with the existing topic base is all that important as long as migration tools are factored into the design. Compatibility makes migration easier and, most likely, can be achieved. But, I have no problem breaking it for the sake of a much improved product. Problems with incompatibility only start when the migration tools are lacking and/or the "new and improved" product is not implemented well.
-- TomKagan - 02 Jun 2003 
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.