Is there an official TW API document?

[Mark S.]

I've been cutting and pasting, into wiki format, the core prototyped
functions out of the TW source. I had previously asked in the users
forum if there already existed such a document. It just occurred to
me, as I finished up the Tiddler class, that maybe I should have asked
in the developers forum.

Thanks!
Mark

---------------------
My formatting is looking like this, if anyone is interested.
!! Tiddler class
* ''.getLinks''()
* ''.getInheritedFields''()
<<<
Returns the fields that are inherited in string field:"value"
field2:"value2" format
<<<
* ''.incChangeCount''()
> Increment the changeCount of a tiddler
...

[Jel]

That's 2 of us both at the same stage playing catchup - the simple
answer is no there isn't, I had a look before wasting time, and worse,
it's about to become redundant as the grown-ups are planning a major
upgrade. Part of the reason is it's an open system, you just throw a
plugin into the pot and hope it works - it doesn't always, one obvious
reason is that there's no guarantee you won't get into Tiddler Wars
with different plugins fighting over who has the top overload. I hope
they do something about that, as it's begging for viral abuse soon.
Jel

[Paul Downey]

There has been discussion on irc and during our unit testing hackathon
about formally documenting the core as a part of the jQuery
refactoring, which could be used to generate javadoc like
documentation, which could be useful, if nothing else to work out test
coverage and what needs refactoring, however most developers get by
with view-source, which isn't too bad given the size of TiddlyWiki.

I did make a start on putting together a introductory developers'
guide for TiddlyWiki, but didn't get as far I'd like, and now think
that developing for TW is about to get a lot easier with the advances
made by incorporating jQuery and thus simplify the guide ..

My mention this is not intended to stop others writing documentation,
and contributions made to http://tiddlywiki.org are always appreciated
and could form the basis for other people, including myself, writing
guides.

As for "viral abuse" - there is a trust when you take a plugin it's
from a good source, and addressing that as a social problem through a
plugin repository would seem to me to be more rewarding than, say,
building a trusted computing platform for plugins, no?

Paul (psd)
--
http://blog.whatfettle.com

[FND]

> formally documenting the core as a part of the jQuery refactoring

I still expect that to happen - see here:
http://groups.google.com/group/TiddlyWikiDev/t/35b9c2ea5433c36b

Once we have documented the individual components, providing an API
overview should be much easier.

> most developers get by with view-source

True - but it can be quite daunting when getting started, not knowing
where to begin.
Also, there are sometimes a few different ways to achieve the same
thing, and it's not always obvious which is the right one (think
addressing properties vs. using accessors, implications for server-side
saving etc.).

> My mention this is not intended to stop others writing documentation,
> and contributions made to http://tiddlywiki.org are always appreciated

Indeed - and of course any code or code-documentation contributions
would be extremely welcome as well.

> As for "viral abuse"

I agree with Paul; while a plugin architecture has some inherent risks,
it comes down to whether you trust the developer/distributor. (There's
some work going on in this regard.)
Nevertheless, it would be great if you could elaborate on those concerns
(preferably in a separate thread).

-- F.

[Jel]

OK, new thread started <a href="http://groups.google.com/group/
TiddlyWikiDev/browse_thread/thread/537e48be9d9b6c1f/
225b5ba536dcadf8#225b5ba536dcadf8">here</a>.
The point I make there is that even the innocent get caught - that's
exactly the root of the problem in the first place, and there's been a
case over on the UserWeb since we started this, just to drive the
point home. What I'm looking at isn't just the trust question, however
- it's the long-term politics of the industry, which is becoming
increasingly anally-retentive in such respects, sadly. I've been at
this game since 1962, and I dearly love Open Source as a result, as
I'm from the generation who built this industry on that basis, but we
DO need to be careful not to make it a laughing stock along the MS
lines.