Menu
▾
▴
phpwiki-talk
|
From: Didier B. <db...@in...> - 2001-02-06 14:36:02
|
Hello,
Do you plan to code the use of table ?
Regards.
--
.------------------------------------------------.
.^. | Didier Bretin, France | db...@in... |
/V\ |-----------------------| www.informactis.com |
// \\ | `------------------------|
/( )\ | Visit: http://www.multimania.com/cieexcalibur/ |
^^-^^ `------------------------------------------------'
|
|
From: Steve W. <sw...@wc...> - 2001-02-06 15:35:51
|
Oh no! Not tables again! We've gotten two patches already! :-) Well, it would be an interesting challenge for Arno ;-) ~swain On Tue, 6 Feb 2001, Didier Bretin wrote: > Hello, > > Do you plan to code the use of table ? > > Regards. > -- > .------------------------------------------------. > .^. | Didier Bretin, France | db...@in... | > /V\ |-----------------------| www.informactis.com | > // \\ | `------------------------| > /( )\ | Visit: http://www.multimania.com/cieexcalibur/ | > ^^-^^ `------------------------------------------------' > > > _______________________________________________ > Phpwiki-talk mailing list > Php...@li... > http://lists.sourceforge.net/lists/listinfo/phpwiki-talk > ...............................ooo0000ooo................................. Hear FM quality freeform radio through the Internet: http://wcsb.org/ home page: www.wcsb.org/~swain |
|
From: Arno H. <aho...@xm...> - 2001-02-07 16:47:01
|
> Oh no! Not tables again! We've gotten two patches already! :-) > Well, it would be an interesting challenge for Arno ;-) Well, I guess my position on tables is clear. They are against wiki philosophy. But heck, now that we have modular code, I could just add a patch (not in= =20 base install) for that. Problem is, I have not yet seen a good markup for tables. Maybe just use the HTML table tags and let users take care of the rest? /Arno |
|
From: Steve W. <sw...@wc...> - 2001-02-07 16:59:07
|
An old saying here is "Give them enough rope and they will hang themselves." This would be my approach to tables. I think someone suggested something like: @ ^cell1 ^cell2 ^cell3 @ ^cell1 ^cell2 ^cell3 @ ^cell1 ^cell2 ^cell3 where @ indicates the start of a table row, ^ the contents of the cell. I'd have to dig it out of the archive. It's a low priority though. I hate tables. If we're supporting multi-line markup now, we can just escape to HTML land for a while, like: ^^^^ (four or more carots starts an HTML block) <table> ... </table> ^^^^ (and closes the HTML block) It's only a warmed over version of the bar syntax. I don't know. It doesn't excite me much. I think a dirt-simple table syntax like the first one is good enough and users can hack it if they want to have more features. I can understand people want to do stuff like: @ ^Judy ^ju...@fo... ^212-444-9999 @ ^Bill ^bi...@mi... ^xxx-yyy-zzzz @ ^Steve ^st...@no... ^aaa-bbb-cccc Even that little bit will be a hassle to code though. ~swain On Wed, 7 Feb 2001, Arno Hollosi wrote: > > > Oh no! Not tables again! We've gotten two patches already! :-) > > Well, it would be an interesting challenge for Arno ;-) > > Well, I guess my position on tables is clear. > They are against wiki philosophy. > > But heck, now that we have modular code, I could just add a patch (not in > base install) for that. > > Problem is, I have not yet seen a good markup for tables. > Maybe just use the HTML table tags and let users take care of the rest? > > /Arno > > _______________________________________________ > Phpwiki-talk mailing list > Php...@li... > http://lists.sourceforge.net/lists/listinfo/phpwiki-talk > ...............................ooo0000ooo................................. Hear FM quality freeform radio through the Internet: http://wcsb.org/ home page: www.wcsb.org/~swain |
|
From: Arno H. <aho...@xm...> - 2001-02-07 17:32:25
|
> @ ^Judy ^ju...@fo... ^212-444-9999 > @ ^Bill ^bi...@mi... ^xxx-yyy-zzzz > @ ^Steve ^st...@no... ^aaa-bbb-cccc <rant> Strange, your example table appeared with columns aligned in the email. How did you do it? Ah, now I know -- I'm using fixed width font. Could we emulate that in wiki? Hmmmm. Woa, we have preformatted text, don= 't=20 we? Now, why do we need tables? </rant> I've added a quick (and dirty?) change to transform.php and stdlib.php --= =20 footnotes work like they do in NBTSCwiki. In order to be able to reference footnotes more than once (assuming the=20 last [x] is always the footnote itself) we could do the following:=20 currently all tokens are replaced by $replacements at the end of the line= =2E Why not hold of this replacement until all lines are done, and then repla= ce=20 them in one big swoosh. Then $replacements of previous lines could still = be=20 redefined. The other solution is to provide hooks for post- &=20 pre-processing of the entire $content. /Arno |
|
From: Steve W. <sw...@wc...> - 2001-02-07 18:48:37
|
On Wed, 7 Feb 2001, Arno Hollosi wrote: > Could we emulate that in wiki? Hmmmm. Woa, we have preformatted text, don't > we? Now, why do we need tables? I want a straw poll here on the list. All in favor of simple HMLT table syntax, or not, speak your piece now. ~swain ...............................ooo0000ooo................................. Hear FM quality freeform radio through the Internet: http://wcsb.org/ home page: www.wcsb.org/~swain |
|
From: Jeff D. <da...@da...> - 2000-07-14 22:38:32
|
In message <Pin...@bo...>,Steve Wa
instead writes:
>On Fri, 14 Jul 2000, Arno Hollosi wrote:
>
>> Hm, I don't think using special fields within the ZIP is a good idea.
>> That way, if someone should touch the ZIP for whatever reason, that
>> data will be lost. I suggest using an extra file, or a meta-file for every
>> page-file.
>
>I didn't catch this before, but now I do, and I agree with Arno.. the less
>we rely on proprietary solutions the better. I'd rather hack a loader to
>read two files per page that suffer Jeff with mucking with Zip files too
>much. It hides the information from the user as well (a separate metadata
>file can be edited in a text editor, can be cat'd, grep'd and so on).
>Putting it in the Zip file means it's almost human-inaccessible.
Yes, I see your point --- however php-serialized() meta-data is basically
human-inaccessible anyway. I don't see much point in making the meta-data
more easily accessible unless it's in some human-friendly format.
So, I think we'd need to come up with some sort of metadata file format
(XML comes to mind, but as lots of PHP's don't have XML support compiled in,
something simpler is probably called for.)
An Internet-messageish format might work well, for example:
---Snip---
Author: 12.34.56.78
Version: 23
Flags: 0
Lastmodified: 2000-07-14T21:39:08Z
Created: 2000-07-02T12:01:22Z
!!!Sample Page
Here's the page contents, with a WikiLink.
---Snip---
(If we're devising our own metadata format, I see no reason to separate the
metadata and file content into two separate files.)
Is this a good idea? Is it worth the effort? (Actually it's probably
not that much effort...)
Also, what's the thinking about whether we should include all the archived
versions of a page (rather than just the most recent) in the ZIP?
I.e.: do we want to be able to:
1) Make a snapshot of the complete state of the database (all versions
of all pages)?
2) Make a snapshot of the current state of the Wiki (most recent version
of all pages)?
3) Have the option to do either 1 or 2?
If you chose 2 or 3, a secondary question is: what are the semantics of
"restoring" from a type 2 snapshot? Some choices:
A) Wipe the entire wiki, reinitialize from the snapshot.
o Archived pages are lost.
B) Essentially edit each page in the wiki so that it coincides with
the page in the snapshot:
o Resulting page version number won't necessarily agree with snapshot.
o Lastmodified date should probably be set to time of restore,
rather than the time in the snapshot.
o Current (pre-restore) version of the page gets archived?
Jeff
PS
In other news: the bug bit me, so I've started working on a modularized,
OOPified
version of wiki_transform and GeneratePage() (a la Arno's suggestions).
When I get it to where I'm happy with it I'll post it here for comments
before CVSing it.
|
|
From: Steve W. <sw...@wc...> - 2000-07-15 16:55:07
|
On Fri, 14 Jul 2000, Jeff Dairiki wrote: > > Yes, I see your point --- however php-serialized() meta-data is basically > human-inaccessible anyway. I don't see much point in making the meta-data > more easily accessible unless it's in some human-friendly format. Very true.. does this make me a hypocrite? ;-) > An Internet-messageish format might work well, for example: > > ---Snip--- > Author: 12.34.56.78 > Version: 23 > Flags: 0 > Lastmodified: 2000-07-14T21:39:08Z > Created: 2000-07-02T12:01:22Z > > !!!Sample Page > > Here's the page contents, with a WikiLink. > ---Snip--- This works for me. While XML would be keen, "don't let the best be the enemy of the good." (best=XML, good=simple reliable solution) Human-readable and human-editable are good things... if the metadata is in the Zip file it's hard to see, hard to edit. With simple plain text files you can write ex scripts to manipulate them, Perl scripts to transform them, change them in Wordpad, etc. (Admittedly I've been reading "The Pragmatic Programmer" again ;-) > (If we're devising our own metadata format, I see no reason to separate the > metadata and file content into two separate files.) > > Is this a good idea? Is it worth the effort? (Actually it's probably > not that much effort...) One file probably is better... and the mail-message format is simple and tried-and-true. NNTP also uses a similar format. > Also, what's the thinking about whether we should include all the archived > versions of a page (rather than just the most recent) in the ZIP? > > I.e.: do we want to be able to: > 1) Make a snapshot of the complete state of the database (all versions > of all pages)? > 2) Make a snapshot of the current state of the Wiki (most recent version > of all pages)? > 3) Have the option to do either 1 or 2? > > If you chose 2 or 3, a secondary question is: what are the semantics of > "restoring" from a type 2 snapshot? Some choices: > A) Wipe the entire wiki, reinitialize from the snapshot. > o Archived pages are lost. > > B) Essentially edit each page in the wiki so that it coincides with > the page in the snapshot: > o Resulting page version number won't necessarily agree with snapshot. > o Lastmodified date should probably be set to time of restore, > rather than the time in the snapshot. > o Current (pre-restore) version of the page gets archived? > This parallels the question "How do you restore a project to a particular release tag (in CVS)?" I suppose in an ideal world, you get a nice wizard box that steps you through all the choices for getting a snapshot, from the "whole thing" to "just the pages, no metadata." But in a practical sense, the thing that concerns me is having a simple way to make backup copies, and a way to port from one Wiki to another. Anyway, my suggestion is: do the simplest thing first, which in fact you've already done since I can make Zip files of PhpWiki.. your choice of what comes next! I favor #3 and #2 in that order. Restoring a Wiki should work through the InsertPage() interface, so unzipping and loading a Wiki would not overwrite existing pages but move them to an archive. > In other news: the bug bit me, so I've started working on a modularized, > OOPified > version of wiki_transform and GeneratePage() (a la Arno's suggestions). > When I get it to where I'm happy with it I'll post it here for comments > before CVSing it. Excellent! You know, CVS has the ability to allow you to develop your own private experimental "branch" and tinker away w/o losing the benefits and freedom CVS provide. I haven't tried it myself yet but if you used this approach, others could check out your work and test it. cheers! sw ...............................ooo0000ooo................................. Hear FM quality freeform radio through the Internet: http://wcsb.org/ home page: www.wcsb.org/~swain |
|
From: Arno H. <aho...@in...> - 2000-07-15 17:43:46
|
Jeff, > > In other news: the bug bit me, so I've started working on a modularized, > > OOPified > > version of wiki_transform and GeneratePage() (a la Arno's suggestions). could you post your class definition, before you start implementing? Maybe the list can give you some valuable feedback. One wish I have is this: make the wiki_transform generic enough, so that it can be used for savepage as well. Let me explain: sooner or later we want to populate the wikilinks database table. In order to get the outgoing links they have to be extracted from the document at save time. Extracting those links is exactly what wiki_transform does right now (among other things). So some sort of PreparePage() or AnalyzePage() which transforms the wiki markup into a semi-state with placeholders and separate arrays for wiki links and external links would be most useful. It could then be reused in wiki_savepage. /Arno |
|
From: Steve W. <sw...@wc...> - 2000-07-15 18:14:04
|
On Sat, 15 Jul 2000, Arno Hollosi wrote: > One wish I have is this: make the wiki_transform generic enough, so > that it can be used for savepage as well. Let me explain: sooner or > later we want to populate the wikilinks database table. In order to > get the outgoing links they have to be extracted from the document at > save time. Extracting those links is exactly what wiki_transform does > right now (among other things). > > So some sort of PreparePage() or AnalyzePage() which transforms the > wiki markup into a semi-state with placeholders and separate arrays > for wiki links and external links would be most useful. It could then > be reused in wiki_savepage. This would allow the renaming of pages as well, and all links for that page would be changed automatically, e.g. SteveWainsteadEatsWorms to SteveWainsteadIsANiceGuy. sw ...............................ooo0000ooo................................. Hear FM quality freeform radio through the Internet: http://wcsb.org/ home page: www.wcsb.org/~swain |
|
From: Arno H. <aho...@in...> - 2000-07-15 21:02:11
|
> > One wish I have is this: make the wiki_transform generic enough, so > > that it can be used for savepage as well. > This would allow the renaming of pages as well, and all links for that > page would be changed automatically, e.g. SteveWainsteadEatsWorms to > SteveWainsteadIsANiceGuy. I haven't thought of this one :o) Wiki pages would still get saved as they are now, only that we save links in the wikilinks table as well. So, renaming a page would need a larger function than simply replacing the pagename in the wikilinks table. Or do you think we should store the intermediate state instead? Btw, I committed a changed UpdateRecentChanges() which adds a diff link :o) And I fixed two more magic_quotes_gpc=1 bugs. This time in wiki_pageinfo and wiki_diff /Arno |
|
From: Steve W. <sw...@wc...> - 2000-07-15 21:07:40
|
On Sat, 15 Jul 2000, Arno Hollosi wrote: > > > > One wish I have is this: make the wiki_transform generic enough, so > > > that it can be used for savepage as well. > > > This would allow the renaming of pages as well, and all links for that > > page would be changed automatically, e.g. SteveWainsteadEatsWorms to > > SteveWainsteadIsANiceGuy. > > I haven't thought of this one :o) > Wiki pages would still get saved as they are now, only that we save > links in the wikilinks table as well. So, renaming a page would need a > larger function than simply replacing the pagename in the wikilinks table. > Or do you think we should store the intermediate state instead? Yes, this is an idea I had a long time ago. I had a problem at work where we wanted to merge two separate Wikis and there were all sorts of namespace collisions I had to think about. I thought that if all pages links were stored externally, and the pages were stored with tokens, that it would open up some interesting possibilities, among them the renaming of pages and therefore all the links to that page. I had some other ideas about the possibility of this architecture which I hope I wrote down somewhere... if not we'll rediscover them! :-) > Btw, I committed a changed UpdateRecentChanges() which adds a diff > link :o) And I fixed two more magic_quotes_gpc=1 bugs. This time in > wiki_pageinfo and wiki_diff Yes, got it, it will go out in the 1.1.7 release, which I am close to doing. Are you going to make any more commits? sw ...............................ooo0000ooo................................. Hear FM quality freeform radio through the Internet: http://wcsb.org/ home page: www.wcsb.org/~swain |
|
From: Arno H. <aho...@in...> - 2000-07-15 21:19:30
|
> > Or do you think we should store the intermediate state instead? > > Yes, this is an idea I had a long time ago. > I thought that [...] it would open up some interesting possibilities Sure :o) I'm in favour of this change. We have to think about some side effects like links to pages not yet existing. Jeff: I guess you have to take this into account when creating your classes for pages and stuff. Basically it means we also need a routine to transform the intermediate state back to 'normal' wiki markup for EditPages. I guess this will lead to some major refactoring. > Yes, got it, it will go out in the 1.1.7 release, which I am close to > doing. Are you going to make any more commits? No. Go ahead :o) /Arno |
|
From: Jeff D. <da...@da...> - 2000-07-29 01:05:51
|
I've checked in my latest (extensive) hacks into the jeffs_hacks-branch of the CVS repository. Take a look. I'm sure there are bugs. Jeff |
|
From: <ph...@de...> - 2001-02-07 19:02:12
|
On Wed, 7 Feb 2001 13:48:50 -0500 (EST), you wrote: => I want a straw poll here on the list. All in favor of simple HMLT table => syntax, or not, speak your piece now. [Leaving the corner, where I was quiet for at least a day ...] As a newbie to the list/application, it doesn't matter to me if you care to add HTML tables (but I personally think it's not really on the path). I'd suggest making the feature toggle on/off thru config.php if you do, so folks can select as they choose. I'd put this at the bottom of the to-do list, and ask first for tasks such as multi-install capability (db and shareable code) as it would be great to have a series of independant mini-wikis for one situation I'm working with. Also I'd prefer time/attention be spent on those things that make the wiki UI so great - it's simplicity and absolute immediate hyper-link abilities. Perhaps faster/better cross-link lists including that great little "related" feature. Another area would be tightening up the ADMIN stuff so that it's completely transparent to the regular visitor. Mulit-level archives were suggested earlier and that would come before tables for me as well. In summary, my vote is: it depends. Thanks again for such a great little all-powerful app. - Don |
|
From: J C L. <cl...@ka...> - 2001-02-08 06:40:45
|
On Wed, 07 Feb 2001 11:01:55 -0800 phpwiki <ph...@de...> wrote: > Also I'd prefer time/attention be spent on those things that make > the wiki UI so great - it's simplicity and absolute immediate > hyper-link abilities. Perhaps faster/better cross-link lists > including that great little "related" feature. Explicit support for SeeAlso: is a Good Thing. -- J C Lawrence cl...@ka... ---------(*) http://www.kanga.nu/~claw/ --=| A man is as sane as he is dangerous to his environment |=-- |
|
From: <ph...@de...> - 2001-02-12 23:47:41
|
On Wed, 07 Feb 2001 11:01:55 -0800, I earlier wrote: => On Wed, 7 Feb 2001 13:48:50 -0500 (EST), you wrote: => => I want a straw poll here on the list. All in favor of simple HMLT table => => syntax, or not, speak your piece now. => As a newbie to the list/application, it doesn't matter to => me if you care to add HTML tables (but I personally think it's => not really on the path). I'd suggest making the feature toggle => on/off thru config.php if you do, so folks can select as they => choose. <snip the rest of my own extremely well-written message> I've had some more thought about HTML: I now think that it would be very handy to be able to use a simple table in wiki when writing about an image included for display on that same page, so that you could keep all the comments to the left or right with <tr><td>etc. Just a thought (but I ran into a case for it over the weekend). Cheers, - Don |
|
From: Aredridel <are...@nb...> - 2001-02-07 21:53:47
|
: > Could we emulate that in wiki? Hmmmm. Woa, we have preformatted text, don't : > we? Now, why do we need tables? : : I want a straw poll here on the list. All in favor of simple HMLT table : syntax, or not, speak your piece now. Well, it's useful in some cases; HOever, using just HTML makes for a nasty change in syntax; nowhere ielse in Wiki is there a tag syntax. Might as well allow using Raw html for that. I kind of liked the caret-syntax -- that could be implemented with a nice regexp. Really, though, tables are not really that neccesary. It's not often that they're the best way to show a certain bit of information. All in all: make it if you wish, make it optional, please. Ari |
|
From: J C L. <cl...@ka...> - 2001-02-08 06:38:24
|
On Wed, 7 Feb 2001 13:48:50 -0500 (EST) Steve Wainstead <sw...@wc...> wrote: > I want a straw poll here on the list. All in favor of simple HMLT > table syntax, or not, speak your piece now. I'm in favour of somethine like TWiki's | format |. -- J C Lawrence cl...@ka... ---------(*) http://www.kanga.nu/~claw/ --=| A man is as sane as he is dangerous to his environment |=-- |
|
From: J C L. <cl...@ka...> - 2001-02-08 06:39:20
|
On Wed, 7 Feb 2001 18:32:07 +0100 Arno Hollosi <aho...@xm...> wrote: > In order to be able to reference footnotes more than once > (assuming the last [x] is always the footnote itself) we could do > the following: currently all tokens are replaced by $replacements > at the end of the line. Why not hold of this replacement until > all lines are done, and then replace them in one big swoosh. Then > $replacements of previous lines could still be redefined. The > other solution is to provide hooks for post- & pre-processing of > the entire $content. The last [x] strting in column zero is the footnote. Everything else is a link to its anchor -- J C Lawrence cl...@ka... ---------(*) http://www.kanga.nu/~claw/ --=| A man is as sane as he is dangerous to his environment |=-- |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X