urosm
/
ikiwiki
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Response

master
Giuseppe Bilotta 2011-02-28 16:29:12 +01:00
parent 2300499bb7
commit c8ff86eb4e
1 changed files with 22 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

22
doc/todo/feed_enhancements_for_inline_pages.mdwn
View File

@ -51,6 +51,9 @@ title and wiki name rather than hard-coding the wiki name as description.
>>> I did not mean to imply that I thought it safe. --[[Joey]] >>> I did not mean to imply that I thought it safe. --[[Joey]]
>>>> Sorry for assuming you implied that. I do think it is safe, though
>>>> (I defaulted to not safe just to err on the safe side).
>> The question is what to do for pages that do not have a description >> The question is what to do for pages that do not have a description
>> (and are not the index). With your proposal, the Atom feed subtitle >> (and are not the index). With your proposal, the Atom feed subtitle
>> would turn up empty. We could make it conditional in the default >> would turn up empty. We could make it conditional in the default
@ -64,6 +67,22 @@ title and wiki name rather than hard-coding the wiki name as description.
>>> few RSS consumers likely even use. That's about 3 levels below useful. >>> few RSS consumers likely even use. That's about 3 levels below useful.
>>> --[[Joey]] >>> --[[Joey]]
>>>> The way I see it, there are three possibilities for non-index pages
>>>> which have no description meta: (1) we leave the
>>>> description/subtitle in feed blank, per your current proposal here
>>>> (2) we hard-code some string to put there and (3) we make the
>>>> string to put there configurable. Honestly, I think option #1 sucks
>>>> aesthetically and option #2 is conceptually wrong (I'm against
>>>> hard-coding stuff in general), which leaves option #3: however
>>>> rarely used it would be, I still think it'd be better than #2 and
>>>> less unaesthetical than #1.
>>>> I'm also not sure what's ‘complex’ about having such an option:
>>>> it's definitely not going to get much use, but does it hurt to have
>>>> it? I could understand not wasting time putting it in, but since
>>>> the code is written already … (but then again I'm known for being a
>>>> guy who loves options).
The third patch, ‘inline: allow assigning an id to postform/feedlink’, The third patch, ‘inline: allow assigning an id to postform/feedlink’,
does just that. I don't currently use it, but it can be particularly does just that. I don't currently use it, but it can be particularly
useful in the postform case for example for scriptable management of useful in the postform case for example for scriptable management of
@ -88,6 +107,9 @@ created by `urlto()` by fixing the routine itself.
>>> It's impossible to do for perl-format setup files. --[[Joey]] >>> It's impossible to do for perl-format setup files. --[[Joey]]
>>>> Ok. In that case I think that we should document that it must be
>>>> slash-less. I'll cook up a patch in that sense.
The inline plugin is also updated (in a separate patch) to use `urlto()` The inline plugin is also updated (in a separate patch) to use `urlto()`
rather than hand-coding the feed urls. You might want to keep this rather than hand-coding the feed urls. You might want to keep this
change even if you discard the urlto patch. change even if you discard the urlto patch.