Tags:
discussion1Add my vote for this tag create new tag
, view all tags
In the following, a form definition is a topic defining the schema for a form. A form is an instantiation of a form definition that is associated with a topic and has some data associated with it. The words must, should and may have their conventional specific meanings in the following.

  1. "Old format" forms must still be editable.
    • There must be no data lost from old style forms
  2. Old TWiki releases are not required to be able to edit new-style forms.
  3. A form must be associated with a specific location in text (embedded).
    • "Old format" forms should be treated as being embedded at the end of the topic
  4. A form field should be editable just by clicking on it.
    • Note that together with the previous requirement this would support the ideas espoused by PeterThoeny, that individual preferences embedded in text be editable, because individual preferences would just be templated from their own form definitions.
      • I don't think so, as PeterThoeny suggested that all preferences can be edited at once, but your requirement does not say that all forms fields belonging to all forms on a page can be edited together (which, I think, is quite hard). --TW
    • Are you sure that people would be interested editing one field in the form? It seems to me that editing portions of text in the style of SectionalEditPlugin and friends is a much wider asked for requirement but it does not seem to get much usage on TWiki (and is not even installed on TWiki.org). Why would editing of individual form fields be more desireable? --TW
  5. A form must be editable as an entity (e.g. by clicking on a button)
  6. An embedded form may become editable when the topic text is edited.
  7. It must be possible to search a field in a specific form, even if the same field exists in multiple forms
  8. It must be possible to move a form from one topic to another (and from a topic in one web to a topic in another)
  9. A specific revision of a form must be independent of the form definition i.e. it must be possible to recover a previous revision of a topic without reference to any form definition.
    • This requirement is really hard, I think. It seems to imply that we either keep two topics in synch (the form definition and use) or that we keep the form definition with the topic. --TW
    • Quite the reverse! Maybe there is some misunderstanding; the current methodology is as I describe in the requirement - a topic containing a form is totally independent of the associated form definition, and that must be the case for multiple-forms-in-a-topic as well. - CC
      • Hmmm. The way I read this requirement you should be able to get the data back in spite of that in the meantime the form definition has changed. In the current implementation, when you go into edit mode on the retrieved data, the fields referring to outdated form definitions will be lost. (Isn't this what had started the whole discussion in the first place?)
  10. Form definitions should be embeddable in other form definitions
  11. Old category style forms (pre-Athens) need not be handled by new-style forms.
  12. NEW multiple forms of the same type must be embeddable in a single topic

-- CrawfordCurrie, ThomasWeigert - 10 Apr 2005

While I sympathize with many of the requirements above, I am concerned that we are mixing two applications together:

  • The form application, and
  • The white board application.
In the current style forms, these do not intrude upon each other. In the proposal above, the white board text is intermixed with form data (at least, the form reference probably a "form one goes here" variable).

Having the forms out of the way is part of their attractiveness (I think).

Most of the requirements above we can already have today with SimpleTableEntryUsingForms. I will make this available on a public TWiki, so that you can try it out...

-- ThomasWeigert - 10 Apr 2005

Ok, then you need some use cases:

  1. "Task" form embedded alongside text that describes how the task was derived
  2. many small bug reports collected together on a single page during a customer meeting
  3. "MyClassicalCDs" topic containing lots of teeny-weeny CDLibraryForm instances. "MyRockCDs" topic somewhere else.
I'm driven by future directions as well. I see forms as integral to the Whiteboard application (c.f. object embedding in powerpoint). I want the option to have "active forms" - for example, the "AlbumCoversPlugin" may process the CDLibraryForm and render the gif image in-line. the "SpreadSheetPlugin" should handle the "SpreadSheetForm" and render calculated results (I never liked spreadsheets in TWiki tables the way they are - they are just too darned hard to use). I'm not saying I want all this now, but I do want to make sure we don't make decisions today that make it impossible,

I added "multiple forms of the same type" to the list.

-- CrawfordCurrie - 10 Apr 2005

I can see your point. Wouldn't an action tracking entry processed by the ActionTrackerPlugin qualify as well?

-- ThomasWeigert - 10 Apr 2005

You read my mind....

-- CrawfordCurrie - 10 Apr 2005

Maybe a silly idea: Why not add some 'this is a form'-attribute to ordinary edit(t)able tables and use them instead of forms.

-- FranzJosefSilli - 10 Apr 2005

Crawford, one more thing.... in your picture of forms being rendered by custom processing capabilities of, e.g., plugins, we need to somehow associate several things with the form:

  • an ability for a plugin to latch onto so it can recignize some text as a form
  • a default layout if it is not processed specially by a plugin
Regarding the latter, I can imagine that we (as I already do it in AlternateFormRendering) would associate layout instructions with the form, so that each form can be rendered in a form-specific way.

-- ThomasWeigert - 10 Apr 2005

Franz, the synergy between forms and tables hadn't escaped me; I'm sure you recall that TWiki tables can be read into FormQueryPlugin. But I don't want to overload one concept or the other. A TWiki table is a valuable formatting concept, very handy for most people to enter a quick table. A form is something significantly different; a block of highly structured (strongly typed) data. A key point is that the same form definition (data type) is used in many different topics. IMHO it is important for efficiency to keep the concepts separated.

Thomas, I see forms as being quite disjoint to 'normal' text. Forms are already held in meta-data, and I see no reason for that to change - quite the reverse, there are strong arguments for maintaining the separation. We may have to keep a "placeholder" in the whiteboard text, for ease of reference, but in all other respects a form is a different kind of object.

The 'normal' layout of a form is already well defined by the current code. That code can be thought of as the "default" rendering handler. I would like plugins to be able to intercept and process forms at several points, in the same way as text is currently handled. And not just the rendering pipeline, either; just as there is a beforeEditHandler there should be a beforeFormEditHandler.

(Of course I'd prefer that there was a form base class, and plugins were able to subclass it to declare their own form types; but historically there has been so much resistance to OO concepts that I've almost given up on that angle, even though it's obviously the right way to go).

-- CrawfordCurrie - 10 Apr 2005

I've been thinking about this alot recently because I've concluded that being able to flexibly embed and display TWikiApplication data within the topic is the key to a "next generation" wiki - leaping beyond anything JotSpot or other wikis have to offer. A question I have for you, Crawford, is have you thougt about how do you deal with multiple incidences of the same form data in different topics. Taking your example of a bug reporting application, what if one wanted to reference a bug created in one topic from another topic? Could the same form data be displayed (and edited) in two different places? This line of thinking has made me wonder if, in some cases, the form data might be easier to manage if not stored locally in the topic's metadata.

BTW, I think another good example that world lend itself to this kind of treatment is events. For that matter, how about attachments?

I agree with Thomas' assertion that it is not necessary to provided single-field editing. Most form data lends itself to editing as a set.

-- LynnwoodBrown - 10 Apr 2005

I've never been comfortable with forms being meta data (implementation layer aside). Its not data about the page, its structured data relevant to the page.

And what if someone wants two instances of the same form on the same page?

-- MartinCleaver - 10 Apr 2005

Aren't there the same 'problems' with attachments? IMHO the separation of the 'white board application' and various kinds of meta data (thinking about mail-messages 'attached' to the 'white board') should be kept in mind but postponed for now. Let's get Dakar ready! smile

-- FranzJosefSilli - 11 Apr 2005

Give me a break, Franz - this is a welcome break from Dakar. And it's important stuff, IMHO.

  • smile You definitely deserve that break. Thanks for all your great work! - FJ

Lynnwood: yes, I have thought about that. I don't think it's a valid concept, in the TWiki architecture. Let me explain.

The TWiki architecture can be thought of as a hierarchy of containers. Each of these containers (web, topic, form, attachment) is strongly typed - a web can contain topics but not forms or attachments. A topic (whiteboard) can contain text and forms and attachments, but not webs. A form can contain text and specialised form fields, but not webs or attachments. Any data container should be linkable from any other data container (it isn't but that's another story). The strong typing is important to TWiki, because it imposes a model that can be easily comprehended by the end user. While a purely abstract hierarchy of data containers would permit inclusion of any type in any type, it is inappropriate for TWiki because it is too hard for most users to visualize.

My vision has always included the ability to cross-reference any data container from any other place. There have been various discussions on the naming scheme used to do this. The logical approach is a natural extension of the existing link naming scheme. Of course form instances have to be named (as Martin points out, the same form may be instanced several times in a single topic) but that can be done explicitly or implicitly. This is really no different to the naming anywhere else in the hierarchy (web, topic, attachment, formfield names). Argh, brain overload, I need to give an example:

Here is some topic text
%FORM{def="ThisForm" name="form1"} % # visible to user
%META:FIELD{form="form one" name="Field".... } % # not visible to user, this is just how it is stored
...

%META:FORM{name="ThisForm"} %
%META:FIELD{name="Field" ...} %

AnotherTopic:Form.TheField      # Reference to a field in the default form in another topic
AnotherWeb.SubWeb.Topic:form6   # Reference to a _whole form_ in another topic

One other thing; I envisage views on links, much as we have wikiwords, and INCLUDEs of wikiwords, today. The view would dictate how that link is referenced/rendered/whatever. I haven't worked out a syntax for this; I was sort of anticipating that %INCLUDE would be one of the views (%INCLUDE{"AnotherWeb.SubWeb.Topic:form6"}) though I clearly haven't worked out all the details.

-- CrawfordCurrie - 11 Apr 2005

Crawford - what aspect of what I said are you referring to as not a valid concept? Reading your response, I think you were picking up on my use of the work "embed" and if so, I gave you the wrong impression. What you say about "strongly typed" makes sense to me. Perhaps it would have been better for me to say something like "flexibly create, refer to and display application-related data (i.e. data in forms) within the main body of the topic." I'm really just supporting your suggestion earlier of making the forms more "integral to the Whiteboard application." And of course, I speaking here only to the user's experience, not the underlying data architecture. I'm still not sure where the best place to store this data is - or if it needs to be treated all in the same way.

I'm also totally with you about the views on linked data. I've been making some notes on that but will share them another time.

-- LynnwoodBrown - 11 Apr 2005

I worry about referential integrity.

Crawford, I know you're trying to use TWiki as a database in many applications, but in reality its more like XBase than Oracle or DB2 or Progress. The tables, nay perhaps even the rows, are seperately built; it is not a database that all within a 'wrapper'. There is nothing to enforce the integrity constraints.

For example, when you do an %INCLUDE, there is nothing that gaurentees the target is there to be included. Now this is tolerable if all you are including is in-line text, and sort of tollerable if you are including style sheet over-rides (for at least the text is there even if its not in the wanted style). But for a database ...

Perhaps its the security maven in me, thinking first about what can go wrong ....

-- AntonAylward - 12 Apr 2005

Lynnwood, I was referring to instantiation of the same data in multiple places. I thought you were meaning to decouple the form data from topics, and allow it to be democratically accessed from two different topics - I was trying to make the point that the strict hierarchical model that TWiki adopts doesn't admit to that concept.

Anton, TWiki is, by design, a "sloppy" data store. Referential integrity is not important (well, it is, but TWiki must be totally robust to failures). A query cannot fail simply because the data to fulfil the query isn't there. This has pros and cons - it makes it harder to debug a failing query, or write an all-encompassing query, but it makes it much easier to build simple DBs, fast. IMHO the latter is TWiki's target market.

Consider how you are "supposed" to use TWiki to build these kind of DBs today; forms or tables, with free-form searches. The ultimate in flexibility. I'm just looking to trade a bit of that flexibility for greater efficiency and some improvement in integrity.

-- CrawfordCurrie - 12 Apr 2005

An interesting conversation with TravisBarker and LynnwoodBrown on IRC just now.

  • The chat started with the idea that %META:FIELD entries in a topic do not have to belong to a form def.
    • currently, they would be deleted, but let's imagine that they are kept
    • and a default editing model - say, a textarea - applied.
    • they would always be sorted below "typed" fields.
  • That led to the idea that a form field could exist in more than one form, if there were multiple forms "attached" to the topic.
    • e.g. two forms could both contain "NameField"
  • In which case, the forms could each present different editing "views" on the same data
  • Also, because data need not be attached to a form, it never gets lost when the form def changes
  • It simply falls back to a "default editing model"
  • and can only be got rid of through explicit deletion.
  • if the range of "editing types" were extended through plugins, this becomes extremely powerful.....

-- CrawfordCurrie - 15 Apr 2005

Just to understand, are you arguing that FIELD is only metadata when it is mentioned in a form definition, but data when it is not? And in the latter case, you see the full FIELD text in all its cumbersomeness in the text area?

-- ThomasWeigert - 15 Apr 2005

Nope. FIELD is always metadata. It's just that a FIELD in a topic does not have to correspond to a field in the form definition.

-- CrawfordCurrie - 16 Apr 2005

So how do you show this field in the topic, when it is not defined in the table? As

%META:FIELD{name="Know.TopicClassification" title="Topic Classification" value="NoDisclosure"}
or just as
NoDisclosure

I remember there was quite some debate several years ago whether one should be able to show metadata in a topic. I have actually implemented a variable that allows you to show arbitrary metadata then...

-- ThomasWeigert - 16 Apr 2005

It would be shown in the topiv view in the same way as any other field - as an entry in a table at the end of the topic. It would have to be disambiguated from meta-data tied to forms, of course, but that isn't hard. It would not be seen in the text of the topic, if that is what you mean.

-- CrawfordCurrie - 16 Apr 2005

So we have three things now:

  • the topic text
  • a table of orphaned fields
  • a set of form tables

In edit mode these are

  • text area
  • text area (per your earlier comments)
  • as defined by form

Is this what you had in mind? I am not sure whether this is a good idea. Why really should orphaned form fields be in a table visible? Wouldn't orphaning them mean that one did not need them any more?

I think the best strategy is to warn the user that she is about to loose data due to the change of the form and maybe even record in the change log that a form was changed and what it was before so that she could recover this when reverting to an earlier topic.

What we need is a mechanism to go back to an earlier topic which does also recover the appropriate form if the form topic was moved or deleted. So a particular version of a topic is really also associated with a particular version of a form.

I am also not quite sure why we are making such a fuss over data getting orphaned upon change of a form. Other data is orphaned similarly:

  • When you include text, but the included topic is changed or deleted.
  • When you have a link, where the topic linked to is deleted.

I come to the conclusion that the current design of how to deal with orphaned form fields) is the correct one, albeit it could stand better recovery of past versions.

-- ThomasWeigert - 16 Apr 2005

Please forgive this tangent, but I was hoping I could have some feedback on a totally different issue: I have captured the requirements from the top in ThreadedDiscussionPlugin, using the "list" style, see the referenced topic.

The idea there is that you can edit the individual bullets without editing the topic, and also add comments (as sub-bullets) by editing these directly.

I was hoping to get feedback on this type of plugin and suggestions for improvements...

-- ThomasWeigert - 16 Apr 2005

Re: your comments above, no, it is not what I had in mind. I guess I'm not explaining myself very well.

At the moment, the form topic defines a type which specifies the semantics of a set of data fields. It constrains the topic to contain only those fields defined in the form topic. We are discussing extending that to permit multiple forms in a topic. Now, if I have two forms in a topic, then the two sets of data fields may be disjoint. Alternatively, they may overlap - in which case there is field data which is common to both form types. For example, I may have a data field which is defined as a textfield in one form definition, but a select in another - but they would display the same _data.

Thus, a form definition specifies a view onto data, and not the data itself. I can freely add new fields to topics, and I can apply different form types to the same topic to get different views onto the same data without changing the data itself.

Logically this requires supporting the idea of data fields in the topic which are not defined in any form attached to the topic. These fields require a default view or they would be inaccessible to anyone editing the topic.

Data fields which are defined in at least one form attached to the topic would be rendered as part of that (those) form(s). Data fields which do not appear in any form get default semantics, which during view would make it a simple text entry in the form, and during edit would make it look like the current textarea form type.

-- CrawfordCurrie - 17 Apr 2005

Crawford, this was good. I think I now see the difference here...

  1. The standard twiki form is an application that holds structured data (with its semantics). It is not related to the whiteboard application (the topic text) except for that data in the form application can be reflected by queries or variables.
  2. You are describing a form as a presentation of part of the data kept in the topic, just as the whiteboard is a presentation of part of the data. There is only one set of data in the topic, shown in different, and maybe, multiple ways.

I think (2) is a valid way, but a huge change. I think it really requires a different model of storing the topic data, once you head that way. And it does require very detailed thoughts of how to differentiate between the applications using that data and the data. For example, typically the applications would edit the data they care about, but at times you might need a whole sale "edit everything" operation.

Your picture jives well with my views on TWikiWhatWillYouBeWhenYouGrowUp but there is much detailed conceptual work ahead...

-- ThomasWeigert - 17 Apr 2005

Yes, (2) is spot on. Why do you think a different storage model is required? It seems to me that the current methodology of embedded meta-data in topic text is still very valid. Also, this is not a huge change, at least in terms of the code. The user model is different, yes, as there is no concept at the moment of "data" and "view" separation (note; this is second nature to anyone with database experience). But the current model is almost a subset of what I am proposing; it's just that you are currently limited to one view per topic.

I imagine that 90% of applications will employ disjoint data sets. The place where this really kicks in is when you want to view existing data in a different way.

For example, the standard data-entry form may use a form that has a select on it with a finite range of states - for example "yes" and "no". However the administrator of that application may wish to reclassify, and use an alternative view that has "yes", "no" and "maybe", or even a textfield.

Another use is roll-up views. I want to see only one or two fields from a large form, for example.

-- CrawfordCurrie - 17 Apr 2005

Crawford, you are right, a change in storage is not required for this model. Albeit it would make certain things much simpler.

My view of how things should work is summarized in this graphics:

This is what I tried to write up in TWikiWhatWillYouBeWhenYouGrowUp. I think that the interaction with each application should be application specific and not mixed into the single edit mode.

Then there is an interaction that defines the overall topic layout (how it is composed from the various applications) and one that can get at all the topic data (to deal with data orphaned by some application.

I think your picture above matches much of this...

-- ThomasWeigert - 17 Apr 2005

Yes - great minds think alike! wink

I actually see the "whiteboard" view as just one view among equals.

The hardest part of all this is working out the relationship between "forms" and "templates", as they are basically the same thing.

-- CrawfordCurrie - 17 Apr 2005

... on the other hand, fools never differ wink

-- ThomasWeigert - 17 Apr 2005

Pushing aside all the bells and whistles, I found a way to support multiple form in a topic in a backward compatible way.

The main concern is that there are parts of TWiki that assume that the name of the form in a topic is stored as META:FORM and that the field are stored as META:FIELD.

With a little cleanup, we can add a new META to store additional forms.

META:FORM{name="DefaultForm"}
META:FIELD{name="FieldA" value="value" <all the other attributes>}
META:FORMFIELD{name="FormName::FieldNameA" value=" " <all the other attributes>}
META:FORMFIELD{name="FormName::FieldNameB" value=" " <all the other attributes>}

This way, the form in META:FORM can be refered as the "default" form (the one showing up know in the skins), and the forms in META:FORMFIELD are "additional" forms.

I have the code to back this up (still proof-of-concept, I'll clean it up and post a patch tomorrow), but I would like some feedback before going further:

  • Should I change the META{"form"} tag to show all the forms in a topic, or add %META{"additionalforms"}%?
  • Would it be better to have a argument "form" in the META:FIELD tag?
  • What should be the behavior of the edit script?
    • Add a name parameter to action=form, to edit the specified form
    • Without a name parameter, edit all forms
    • Without a name parameter, edit the default form. If name=all edit all forms
  • FORMFIELD should be changed:
    • Add a form parameter to specify the form to look for
    • Allows the syntax "FormName::Field"
  • METASEARCH should be changed:
    • Add a form parameter to specify the form to look for
    • Allows the syntax "FormName::Field" in the name field.
  • TWikiForms must be updated

Any other thing that needs to be addressed?

-- RafaelAlvarez - 17 Jul 2006

Sounds very promising! And it's in line with KISS, isn't it?

-- FranzJosefSilli - 17 Jul 2006

For simplicity, do we need a new meta? I think stacking forms on top of each other is a clearly defined the sequence. Example:

META:FORM{name="FooForm"}
META:FIELD{name="Field1" title="Field1" value="F-1" ...}
META:FIELD{name="Field2" title="Field2" value="F-2" ...}
META:FORM{name="BarForm"}
META:FIELD{name="FieldX" title="FieldX" value="B-X" ...}
META:FIELD{name="Field2" title="Field2" value="B-2" ...}

FORMFIELD and SEARCH would search for the first occurance of a field. It can also be extended to search for "FormName::FieldName" as you suggest.

Thinking this further, one could even allow multiple inheritance for forms, such as META:FORM{name="VehicleForm, PersonForm"} to get a big form that has all fields of the referenced forms (first one wins if same field used more than once). Example based on above forms:

META:FORM{name="FooForm, BarForm"}
META:FIELD{name="Field1" title="Field1" value="F-1" ...}
META:FIELD{name="Field2" title="Field2" value="F-2" ...}
META:FIELD{name="FieldX" title="FieldX" value="B-X" ...}

-- PeterThoeny - 17 Jul 2006

I'd love to have inheritance for forms!

-- MichaelDaum - 18 Jul 2006

As a compromise between the "no new meta" view and the "compatibility" view (which implies a horrible ordering problem), why not simply add a form attribute to the META:FIELD and a def attribute to the META:FORM? Thus:

Old-style
META:FORM{name="OldStyleForm"}%
META:FIELD{name="Field1" title="Field1" value="F-1" ...}%
New-style
META:FORM{name="MyFormName" def="OldStyleForm"}%
META:FIELD{name="Field1" form="MyFormName" title="Field1" value="F-1" ...}%
The first time you edit a topic with old-style forms in, it can auto-add the def for the default form and form fields:
Old-style
META:FORM{name="OldStyleForm" def="OldStyleForm"}%
META:FIELD{name="Field1" form="OldStyleForm" title="Field1" value="F-1" ...}%
METASEARCH would still have to be changed as you describe.

I don't think that's significantly more difficult to code, but it's significantly cleaner. Further, code that currently iterates over all form fields in a topic requires no changes...

-- CrawfordCurrie - 18 Jul 2006

What does the def paramter in the form meta data do?

I'd like to avoid yet another change in the form field meta data. When you save a TWiki 3 form in TWiki 4, rdiff shows all form fields as changed because of the parameter change.

-- PeterThoeny - 18 Jul 2006

It would be nice if we could avoid NihSyndrome. See FrameBasedLanguages for one instance of an approach to a solution of this problem.

-- MeredithLesly - 18 Jul 2006

Adding a form parameter to META:FIELD has a "problem": There can't be two forms with fields with the same name, as the FIELD tags are indexed by name.

So, I used the following sintax:

META:FIELD{name="SomeForm::name"}

It works, has little impact on the META code, and allows the "old style" and the "new style" to coexist happily.

CrawfordCurrie idea of having the a def parameter on the META:FORM tag may serve to allow multiple inheritance. I'm envisioning something like this:

META:FORM{"MyForm"} <--- this would be the "default" form
META:FORM{"MyAdditionalForm" def="FormOne,FormTwo} <--- this would be an additional form, with all the fields in FormOne and FormTwo

META:FIELD{name="field" value="value"} <-- This is a field of the "default" form
META:FIELD{name="MyAdditionalForm::field1" value="value"} <-- this is a field of the "additional" form

This way, topic formats don't need to be "upgraded", wild plugins don't need to be rewritten and clever SEARCH hacks don't need to be rethough.

-- RafaelAlvarez - 18 Jul 2006

I suggested the form parameter on META:FIELD for two reasons:

  1. to save having to parse the form name to extract the form def
  2. to avoid reserving the ':' character#
But I'm not wedded to it; if there is a good reason for doing it in the existing field, fair enough.

Note that there is no need to change form meta-data unless a topic has multiple forms, in which case I would expect rdiff to tell me.

-- CrawfordCurrie - 18 Jul 2006

Are overlapping form field names a problem? I see this as an opportunity to merge useful fields of multiple forms into one big form. Picture a TestDefinitionForm and a TestResultForm, both with a "Owner" form field. The combined form would need fields from both forms, with duplicates removed.

-- PeterThoeny - 18 Jul 2006

That needs to be defined. The impact on the code is minimal, but once the code is released, the spec will be "set into stone".

-- RafaelAlvarez - 18 Jul 2006

An interesting question. Personally I see collapsing forms as non-core functionality, that might be handled by an extension. The extension would be responsible for defining the field name resolution rules. The reason I don't see it as core is that the collapsing is basically a UI problem; you want to maintain the full form in the background, otherwise an edit is lossy (not good).

-- CrawfordCurrie - 19 Jul 2006

Topic attachments
I Attachment History Action Size Date Who Comment
GIFgif TWikiapps.gif r1 manage 10.4 K 2005-04-17 - 15:38 ThomasWeigert  
Edit | Attach | Watch | Print version | History: r41 < r40 < r39 < r38 < r37 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r41 - 2006-07-19 - CrawfordCurrie
 
  • 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.