Extra attributes in storeArea divs

[Frank McIngvale]

Hi, I have a technical question regarding the storeArea. Playing
around, it appears I can freely add extra attributes to the <divs> in
the storeArea and TW preserves them when the tiddlers are later
edited. Is this behavior "officially" supported, or does it just
happen to work at the moment? I'd like to take advantage of this on
the server side, but wanted to make sure this behavior was
intentional.

thanks,
Frank

[Eric Shulman]

The attributes you see in the storeArea tiddler DIV are actually the
storage format for the tiddler 'fields'. This includes both standard
core-defined fields (title, modifier, created, modified, tags, and
changecount), and any *custom* fields, which can be plugin-accessible
(using the store.getValue() and store.setValue(...) functions) or
entered via a custom EditTemplate and displayed using a custom
ViewTemplate (with the <span macro='view fieldname'></span> syntax).

For example, check out this tiddler:
http://www.TiddlyTools.com/#%5B%5B2008.06.18%20TiddlyWest%5D%5D

Because it is tagged with "task" it uses a custom template (e.g.,
"TaskViewTemplate", selected via the TaggedTemplateTweak plugin).
This custom template uses form controls provided by ListboxPlugin and
CheckboxPlugin to set various task-related custom fields, including
status, urgent, and assigned, which are then saved in the storeArea
DIV as attributes, like this:

<div title="2008.06.18 TiddlyWest" modifier="ELSDesignStudios"
created="200805181707" modified="200806150527" tags="sample
TaskPackage task Done" status="not started" changecount="50"
urgent="false" assigned="all">

So, in summary: yes, if you are using a server-side script to generate
storeArea DIVs that contain non-standard attributes, not only will
they be properly preserved in the file, but you can even access (and
modify) those attributes from within TiddlyWiki by using custom
templates to display/write the values, accessed internally as custom
tiddler fields.

enjoy,
-e

[Frank McIngvale]

On Jun 15, 9:20 pm, Eric Shulman <elsdes...@gmail.com> wrote:
> > Hi, I have a technical question regarding the storeArea. Playing
> > around, it appears I can freely add extra attributes to the <divs> in
> > the storeArea and TW preserves them when the tiddlers are later
> > edited. Is this behavior "officially" supported, or does it just
> > happen to work at the moment? I'd like to take advantage of this on
> > the server side, but wanted to make sure this behavior was
> > intentional.
>

<snip>

> So, in summary: yes, if you are using a server-side script to generate
> storeArea DIVs that contain non-standard attributes, not only will
> they be properly preserved in the file, but you can even access (and
> modify) those attributes from within TiddlyWiki by using custom
> templates to display/write the values, accessed internally as custom
> tiddler fields.

Great! Thanks for the detailed explanation. I had vague notion that
others were doing things like that with extra attributes, but wanted
to confirm it.

thanks again,
Frank

>
> enjoy,
> -e

[FND]

> I had vague notion that others were doing things like that with extra
> attributes, but wanted to confirm it.

There's also some information on the community wiki:
http://www.tiddlywiki.org/wiki/Tiddler_Fields
http://www.tiddlywiki.org/wiki/Extended_Fields
Feel free to add your info there as well.

-- F.

[Frank McIngvale]

Thanks! Is there a consensus on whether additional fields should be
named like "namespace.attr" or "namespace_attr"? I see both forms on
the wiki. I suppose it doesn't matter too much, just curious.

frank

[FND]

> Is there a consensus on whether additional fields should be
> named like "namespace.attr" or "namespace_attr"?

Good point! (Consistency is not unimportant... )
As far as I can tell, the core uses a dot for namespace separation (e.g.
"server.host"), so that could be considered the implicit consensus.

It might be better to discuss this on the developers list:
http://groups.google.com/group/TiddlyWikiDev/

-- F.

[Frank McIngvale]

Ah, thanks for the pointer. This discussion has answered my questions
on this point, but I'll make sure to post dev questions there in the
future.

frank