On Sun, Sep 7, 2008 at 3:22 PM, Martin <[EMAIL PROTECTED]> wrote:
>
>
>> > visiblefield: some text
>> > :hiddenfield: some other text
>>
>> > This would display in the page as
>>
>> > visiblefield: some text
>> > some other text
>
> My first idea was: I like that. Finally an UTF-8 ready tagging system
> that is not based on page urls with its limitations. It works with
> search plus you can display the tags without showing the fieldname.
Actually I think we are going to want to use BoltWire's new info
capabilities. We need to add only slight modifications (extensions) to
get it working fully. Basically we need need to add CSV list handling
capabilities to info so we can do:
[(info list +tag2)]
and get it to change
some.page: tag1 to some.page: tag1,tag2
The code is all thee, it just need to be wired up.
Second we need a way to search in a field value, rather than just
matching full values, something like inlist. Maybe:
[(info inlist tag1 template=whatever)]
And then it will retrieve all the page names that contain the
appropriate tag and display the output. Of course in all the above,
we'll need to set the target parameter as well, to something like
info.tags.
Oh and to display the tags you simply use:
[(list {info.tags::{p}} template=tags)]
> At second thought, I may say: Is there any difference between an
> anchor and a hiddenfield?
Yes I agree, there is not much advantage to this. Plus, many wiki's
use :field: value to generate definition lists, so I'm hesitant to use
up that markup.
For Linly's specific request, my other suggestion seems more
appropriate, and I'm seriously leaning towards giving it a try:
target=some.page::3
Replace line 3 on some.page with the new content of edit. But I'm not
sure how this will interact with other commands, etc those that use
target. It could generate errors and the like.
Perhaps better still is to go with a custom editline command, with
syntax like the following:
[session editline "3:new content"]
This keeps it from affecting the targeting system in BoltWire and is a
nice clear way to edit individual lines. Other options might be
[session editline "-3"] to delete line 3 as opposed to [session
editline "3"] which simply clears the line but leaves the line return.
And then we could do
[session editline "+:new content"] or [session editline "+0:new
content"] or [session editline "+3:new content"]
Which could mean add to the end, add to the beginning, or insert after line 3.
Combine this with [(getline page=some.page content="some stuff")]
which returns the line number, you could replace individual lines like
this:
[session editline "[(getline some.page 'some stuff')]: new stuff"]
Of course now we are intersecting a bit with the log command--which
suggests we should consider if there isn't some way to merge the two.
Perhaps by adding a line parameter to the log flags. Wow, that's an
idea, and probably much easier to do as log is set up for all this
kind of stuff already. We're just adding one little bit of capability
at a specific point in the logging function... Yeah this is the way
to go....
[session log "content='new stuff'' target=some.page flags='line=-3/3/+3,trim=7"]
Which means insert the 'new stuff' log entry before line 3, over line
3, or after line 3. With log we already have delete capabilities, top
and bottom. And to clear a line we should be able to log a blank space
or something... All we are lacking is the ability to control the
exact insertion point of a log entry. Wow, this is a really cool idea.
And the getline function would be a nice addition too... Working the same way.
One of the best bits of wisdom Pm taught me (among many) was that the
really hard part of wiki design is developing good syntax. The code is
the easy part. Perhaps because you can always improve the code--but
it's hard to change syntax once it get's established. And it's true.
So let's make sure we get it right before we jump in.
I know the above seems like a bit of rambling, but perhaps we may have
ended up with the "right" answer. Comments?
Cheers,
Dan
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"BoltWire" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/boltwire?hl=en
-~----------~----~----~----~------~----~------~--~---
