From: Jan H. <hi...@wi...> - 2000-12-06 04:06:47
|
Hello Steve and everybody, There are some questions I would like to ask about phpwiki but not before I have said that I have used it a little now and really like it, especially its simplicity and accessability. I have plans of using it to set up some kind of FAQ / dictionary for database theory or even something with a broader scope like www.foldoc.org. So here are my questions: 1. What is the relationship between phpwiki and pwiki? The projects look very similar to me, although pwiki seems heavier on features (not neccessarily a good thing). Are there plans for cooperation in the future? 2. Is [link name|PageName] considered not WikiWiki? It is my opinion that this would be a very logical and useful extension; it solves some problems such as unnatural WikiWikiNames and plurals. I foudn a "patch" by Antti Kaihola but that doesn't work for the latest version. So I made a new one for the latest version of phpwiki. Is anyone interested in that or am I just making it harder for myself to migrate to the next version? :-) During my efforts to get this done I noticed a minor bug in the function ExtractWikiPageLinks. If you have something in your text like "[[not a link]" then the page name "[not a link" is extracted as a link name and turns up, for example, in MySQL in the table wikilinks. My patch also fixes this. 3. Are square brackets in page names allowed? If you try things like "[link[3]]" or "[ [[link]" or "[ a[[a]]a ]" you will see some funny symbols appearing in the output. Maybe this has something to do with tokenization inside page names that is not taken into account? The way that things are implemented now, you can never have a closing bracket inside a page name. I think that is an unnecessary restriction. To solve this I would suggest that closing brackets should also be escaped, i.e., ']' should be written as ']]' if it is not meant as an end of a page name. As far as I can see this is not very hard to implement with regular expressions. You can, for instance, recognize bracketed links because they begin with an uneven number of '['s and end with an uneven number of ']'s. Anyway, these were my questions. I hope you will find some time to answer them. Kind regards, -- Jan Hidders |
From: Steve W. <sw...@wc...> - 2000-12-06 04:39:47
|
On Wed, 6 Dec 2000, Jan Hidders wrote: > There are some questions I would like to ask about phpwiki but not before I > have said that I have used it a little now and really like it, especially Glad you like it! > 1. What is the relationship between phpwiki and pwiki? I don't think I've ever installed Pwiki... is that the purely OOD PHP wiki? Oh, that's John Jorgensen's. I have installed that. There's no formal connection but he was an early tester of PhpWiki last December... he also let me keep the name PhpWiki. He was going to use it but never released anything under that name. We haven't shared much code. I recall a discussion on regexps to match links, which was and still is a tricky thing to do. > The projects look very similar to me, although pwiki seems heavier on > features (not neccessarily a good thing). Are there plans for cooperation in > the future? No, not at this time. > 2. Is [link name|PageName] considered not WikiWiki? It is now :-) Arno added this in the last few weeks, and if you try a nightly build you'll see it works. I just tested it. > During my efforts to get this done I noticed a minor bug in the function > ExtractWikiPageLinks. If you have something in your text like "[[not a > link]" then the page name "[not a link" is extracted as a link name and > turns up, for example, in MySQL in the table wikilinks. My patch also fixes > this. Confirmed on my Postgresql installation... nice catch! > 3. Are square brackets in page names allowed? > > If you try things like "[link[3]]" or "[ [[link]" or "[ a[[a]]a ]" you will > see some funny symbols appearing in the output. Maybe this has something to > do with tokenization inside page names that is not taken into account? The funny symbols are the $FieldSeparator tokens we use as placeholders... something pathological is happening here. > The way that things are implemented now, you can never have a closing > bracket inside a page name. I think that is an unnecessary restriction. To Well, can you give some reasons why it should be allowed? I now regret allowing [link] notation. I think a more flexible BumpyText pattern would have served us better. I would never go back at this point of course, but this touches on the larger issue of Wiki useability. If all the links are consistently BumpyCaseLinks, I think the Wiki gains a little in consistency and usability. Others disagree, and since I'm a nice guy we have and will keep [bracket links]. :-) > solve this I would suggest that closing brackets should also be escaped, > i.e., ']' should be written as ']]' if it is not meant as an end of a page > name. As far as I can see this is not very hard to implement with > regular expressions. You can, for instance, recognize bracketed links > because they begin with an uneven number of '['s and end with an uneven > number of ']'s. That's logically consistent... What do you think Arno? thx Jan! 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-12-06 11:18:36
|
> > During my efforts to get this done I noticed a minor bug in the > > function ExtractWikiPageLinks. If you have something in your text like > > "[[not a link]" then the page name "[not a link" is extracted as a link > > name and turns up, for example, in MySQL in the table wikilinks. My > > patch also fixes this. > > Confirmed on my Postgresql installation... nice catch! This bug has been fixed since stdlib.php v1.12 from November 16th. Are you sure you tested the latest build? If you are using an existing database there still might be some of those links in there - they should go away after loading/saving the page. While verifying this, I discovered that I didn't include another bugfix I have had in my local wiki for some time. I have committed it now. From the log: :: fixed another bug in ExtractWikiPageLinks(): wiki-unknown-named was not :: recognized and named wiki links had the wrong linktext inserted into the :: wikilinks table > > 3. Are square brackets in page names allowed? Currently: no. And yes, any attempt to use "]" inside links has unpredicted consequences. > Well, can you give some reasons why it should be allowed? Me wonders too. You know, for my petproject "Sensei's Library" I have modified it the following way. Bracketlinks are possible, but they have a restricted regexp. Basically it boils down to that [some page] is equal to SomePage or [yet another page] == YetAnotherPage. I.e. it is only used for readability purposes. Well, ok I filter out some chars as well so that e.g. [Sensei's Library] == SenseisLibrary. The only thing you can do inside brackets that you can't replicate with BumpyText is single words like [Link]. > > solve this I would suggest that closing brackets should also be > > escaped, i.e., ']' should be written as ']]' if it is not meant as an > That's logically consistent... What do you think Arno? Logical, yes, but I still don't like it. I'm not too keen to include it, but of course I won't stay in the way of progress either ;) I assume that allowing those brackets causes more trouble for casual visitors seeing and trying to recreate links like "cool [awesome] page". A straight-forward failure to use "]" is easier to understand. And don't tell me it can be found in the manual somewhere. People don't read manuals. /Arno |
From: Jan H. <hi...@wi...> - 2000-12-06 15:14:40
|
On Wed, Dec 06, 2000 at 12:18:23PM +0100, Arno Hollosi wrote: > > > > During my efforts to get this done I noticed a minor bug in the > > > function ExtractWikiPageLinks. If you have something in your text like > > > "[[not a link]" then the page name "[not a link" is extracted as a link > > > name and turns up, for example, in MySQL in the table wikilinks. My > > > patch also fixes this. > > > > Confirmed on my Postgresql installation... nice catch! > > This bug has been fixed since stdlib.php v1.12 from November 16th. > Are you sure you tested the latest build? Oops. I didn't. My apologies. The latest nightly build in the FTP directroy seems to be the one of Nov. 5. But I will probably be able to get it by CVS. > > > 3. Are square brackets in page names allowed? > > Currently: no. > And yes, any attempt to use "]" inside links has unpredicted consequences. Well, a single "]" is predictable; it always closes the link. And a single "[" does also what you would expect. Its when you use "]]" or "[[" that things become funny. But this is besides the point. > > Well, can you give some reasons why it should be allowed? Well, in a FAQ I would expect link names like "Why can't I have ']'s in my link names?". :-) But seriously, no, I have no concrete example of a useful link name with brackets in it. But then again, I am also not really sure that no-one is ever going to need one. > Me wonders too. You know, for my petproject "Sensei's Library" I have > modified it the following way. Bracketlinks are possible, but they have a > restricted regexp. Basically it boils down to that [some page] is equal to > SomePage or [yet another page] == YetAnotherPage. I.e. it is only used for > readability purposes. Well, ok I filter out some chars as well so that > e.g. [Sensei's Library] == SenseisLibrary. But wouldn't then the title of the page show up as "Senseis Library"? > > > solve this I would suggest that closing brackets should also be > > > escaped, i.e., ']' should be written as ']]' if it is not meant as an > > That's logically consistent... What do you think Arno? > > [..] > > I assume that allowing those brackets causes more trouble for casual > visitors seeing and trying to recreate links like "cool [awesome] page". Hm. Maybe, but if you are going to recreate something, you can always easily check how the original was done. In fact, if I hadn't seen the example of [[link name] I probably would have tried [[link name]] first. > A straight-forward failure to use "]" is easier to understand. And don't > tell me it can be found in the manual somewhere. People don't read manuals. In the edit page it now says 'escape "[" with "[["'. You could simply change that into escape '"[" and "]" with "[[" and "]]"'. I don't think that is really hard to understand. And the way that things are currently implemented (replacing escaped things with tokens) the standard example of "[[link name]" would still work. The only thing that would really change is that "bla ]] bla"" will be transformed to "bla ] bla". But how often do you write something like that? The only two difficulties that I see are that 1. during transformation you have to take into account that link names may contain tokens 2. when extracting links you have to take into acount that link names may contain escaped symbols such as [[ and ]] -- Jan Hidders |
From: Steve W. <sw...@wc...> - 2000-12-06 16:05:12
|
On Wed, 6 Dec 2000, Jan Hidders wrote: > > This bug has been fixed since stdlib.php v1.12 from November 16th. > > Are you sure you tested the latest build? > > Oops. I didn't. My apologies. The latest nightly build in the FTP > directroy seems to be the one of Nov. 5. But I will probably be able to get > it by CVS. Fixed. I removed a tmp/ directory that the script was using. Nightly builds are available again, and I put a new tarball up. > link names?". :-) But seriously, no, I have no concrete example of a useful > link name with brackets in it. But then again, I am also not really sure > that no-one is ever going to need one. I have been reading "Extreme Programming Explained" and "Pragmatic Programmer," and both urge you to avoid adding things you think might be needed in the future... when there is a compelling reason to add it, we will; this includes "pure hack value" as well, so if I'm stuck home for a few days with a cold, it might get added ;-) sw ................................ooo0000ooo................................. Hear FM quality freeform radio through the Internet: http://wcsb.org/ home page: www.wcsb.org/~swain |
From: Jan H. <hi...@wi...> - 2000-12-06 13:39:13
|
On Tue, Dec 05, 2000 at 11:39:43PM -0500, Steve Wainstead wrote: > On Wed, 6 Dec 2000, Jan Hidders wrote: > > > > 2. Is [link name|PageName] considered not WikiWiki? > > It is now :-) Arno added this in the last few weeks, and if you try a > nightly build you'll see it works. I just tested it. Wonderfull! Thank you Arno, thank you Arno, thank you Arno :-). -- Jan Hidders |
From: Jan H. <hi...@wi...> - 2000-12-07 14:14:17
|
When browsing through Arno's code for interpreting the templates I came up with a new idea. What is now happening is that you are basically trying to reinvent your own HTML scripting language with "IF"s et cetera. But that is exactly how PHP started! So why not simply us PHP to do this in stead of trying to write your own script interpreter? All you would have to do in your code is define the PHP variables and function that can be used in the template, and then simply include the template at the end of the code. A template like browse.html could then look like this: ---- <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> <title><? echo $page; ?></title> </head> <body bgcolor=ivory text=black alink=red link=darkblue vlink=darkmagenta> <h1> <a href="<? echo $scripturl; ?>"> <img src="<? echo $logo; ?>"border=0 alt="[phpwiki]" align=middle width=50 height=50> </a> <a href="<? echo $scripturl; ?>?full=<? echo $pageurl; ?>"> <? echo $page; ?> </a> </h1> <? if ($admin) { ?> <FORM ACTION="<? echo $scripturl; ?>" METHOD=POST> <? if ($lock) { ?> [<a href="<? echo $scripturl; ?>?unlock=<? echo $pageurl; ?>">Unlock page</a>] <? } else { ?> [<a href="<? echo $scripturl; ?>?lock=<? echo $pageurl; ?>">Lock page</a>] <? } ?> - - [<a href="<? echo $scripturl; ?>?remove=<? echo $pageurl; ?>">Remove page</A>] <hr noshade> <? } ?> <P> <? echo $content; ?> <hr noshade> ... ---- Well, you get the point. Time for some pro's and con's: + phpwiki code gets simpeler + future extensions for templates will be far more easy to program (just define some new PHP variables and functions) + administrator can define very powerfull templates - the templates become less readable if you don't know any PHP - no backwards compatability So what do you guys think? If you think this is a good idea I would be quite willing to spend some time on this during the coming holidays. -- Jan Hidders |
From: Arno H. <aho...@in...> - 2000-12-07 16:49:36
|
On Thursday 07 December 2000 15:14, Jan Hidders wrote: > So why not simply use PHP [for templates] to do this > in stead of trying to write your own script interpreter? Because > - the templates become less readable if you don't know any PHP and: - you move back code into the templates - the exact opposite of what templates are for, no? - you can't use "echo" inside templates. You want the whole page returned as string, so that you can mangle it further, or do e.g. an HTML dump of the entire wiki. > + phpwiki code gets simpeler Not necessarily. Only some functionality of GeneratePage is moved to the template. Not much saving in complexity here. All you do is saving a few str_replace. Worth the hassle? > + future extensions for templates will be far more easy to program (just > define some new PHP variables and functions) This is exactly the same amount of work needed in its current form. Plus one str_replace per extension. Actually, I was very upset that I had to introduce ###IF### into the templates. But it looked like the only reasonable choice. Note that I didn't even bother to include an ###ELSE### directive. I have given the idea of using PHP inside templates some thought, before I implemented the current template form. For me it boils down to simplicity - meaning simplicity for the user and not for us programmers. And I think from the standpoint of simplicity the current form wins hands down against using PHP. (one may argue about ###IF###, I agree) Of course, if we ever needed more complex directives such as for, while, variables ... I would rethink my position again and go for PHP I think. But currently I don't see a need for it. We don't even have per-user customization or user accounts at all for that matter. Unless we introduce user accounts (and a right-managament system) I don't think there is need for a more sophisticated templating language. You may start to wonder if I am opposed to every and all idea you propose. But please understand that I'm just arguing my point of view. I may be wrong, and I don't have the final word. Try to convince me, come up with a killer example. You know, in your first email you wrote: > I have used phpwiki a little now and really like it, > especially its simplicity and accessability. That's what I'm trying to protect here. /Arno |
From: Jan H. <hi...@wi...> - 2000-12-07 18:02:09
|
On Thu, Dec 07, 2000 at 05:49:24PM +0100, Arno Hollosi wrote: > > On Thursday 07 December 2000 15:14, Jan Hidders wrote: > > So why not simply use PHP [for templates] to do this > > in stead of trying to write your own script interpreter? > > Because > > - the templates become less readable if you don't know any PHP Well, yes, I know, obviously. :-) But do you really think that the example that I gave is really so much harder to read that the original? Remember that the maintainer of a phpwiki-site is going to have to do some configuaration in PHP files anyway. > and: > - you move back code into the templates - the exact opposite of what > templates are for, no? But as you saw yourself, you are now forced to do this anyway. And I am very convinced that there is more to come. > - you can't use "echo" inside templates. You want the whole page > returned as string, so that you can mangle it further, or do e.g. an > HTML dump of the entire wiki. Ah, but that is the beauty of it all. All you have to do is say at the end of index.php --- include('templates/template.html'); ?> --- and that's it!! You don't even have to start the template with "<?" because the include takes care of that. Of course I am simplifying here because you have to decide which template to include et cetera, but you get the point. > > + phpwiki code gets simpeler > Not necessarily. Only some functionality of GeneratePage is moved to the > template. Not much saving in complexity here. All you do is saving a few > str_replace. Worth the hassle? Not right now. But as you will add more features this will happen. Regular expressions are going to break down if you get things like nested IF-blocks. Or are you going to introduce a different type of IF-block for every possible combination of flags? > We don't even have per-user customization or user accounts at all for that > matter. Unless we introduce user accounts (and a right-managament system) I > don't think there is need for a more sophisticated templating language. Don't you think that it is safe to say that these things *will* be added in the future? If phpwiki really takes off (and that is what I expect) then these things will be added sooner or later. And at that stage you would have a bigger problem because you would have many site-maintainers that would hate to give up their old templates when upgrading to the latest version. > You may start to wonder if I am opposed to every and all idea you propose. > But please understand that I'm just arguing my point of view. I may be > wrong, and I don't have the final word. Try to convince me, come up with a > killer example. The nested IF-blocks would probably be one. You need that if you want something inserted only if three flags are true. And you already said yourself that in the near future there will be more flags and the templates will become more complex. > You know, in your first email you wrote: > > I have used phpwiki a little now and really like it, > > especially its simplicity and accessability. > > That's what I'm trying to protect here. I know, and I respect that. It is not my intention to start a big longdrawn debate here, or anything. (But I cannot really promise that it won't. :-}) You have clearly listened to and thought about my proposal and that is all that I can expect. This is your project and I am just peeping around the corner. I only found one bug and this was mainly due to your excellent coding style. :-) Kind regards, -- Jan Hidders PS. Can I ask you to just send replies to the mailing list? Right now, I am getting two replies every time. Or does Kmail not have that option? |
From: Jan H. <hi...@wi...> - 2000-12-07 19:27:48
|
On Thu, Dec 07, 2000 at 07:02:05PM +0100, Jan Hidders wrote: > On Thu, Dec 07, 2000 at 05:49:24PM +0100, Arno Hollosi wrote: > > > > - you can't use "echo" inside templates. You want the whole page > > returned as string, so that you can mangle it further, or do e.g. an > > HTML dump of the entire wiki. > > Ah, but that is the beauty of it all. All you have to do is say at the end > of index.php *slap* Sorry, sorry. Then the result goes to the output and cannot be put in a string. I thought this could be easily solved with 'eval' but that only works in PHP4. I think I will just shut up now :-/. -- Jan Hidders |
From: Arno H. <aho...@in...> - 2000-12-07 19:20:30
|
> But as you saw yourself, you are now forced to do this anyway. And I am > very convinced that there is more to come. I'm not so convinced :o) > Ah, but that is the beauty of it all. All you have to do is say at the > end of index.php > include('templates/template.html'); Again: no it's not as easy as this. I want to have a string returned! (e.g. dump html files in a ZIP file) so it basically becomes some form of "eval('templates/template.html')" - and that means (among other things) no echo, print, printf (not that that would be a major problem). > Regular expressions are going to break down if you get things like nested > IF-blocks. Or are you going to introduce a different type of IF-block for > every possible combination of flags? Nested IF-blocks work already. The only thing you can't nest is twice the same condition, i.e. ###IF:ADMIN### .... ###IF:ADMIN### But I can't think of a case where such a construct is necessary. > [user accounts] > Don't you think that it is safe to say that these things *will* be added > in the future? No. They won't come in 1.3.x (and therefore in 1.4.x) And what is beyond that is pure imagination. For all I know, the internet might no longer exist at that point. > If phpwiki really takes off (and that is what I expect) > then these things will be added sooner or later. There are many other wiki-clones out there, so it's unlikely that phpwiki will achieve world-domination. E.g. tclwiki already has user identification, complete diff archive, and more goodies. You can find a wiki-clone for every problem you need - from basic ones to very sophisticated ones. phpwiki is somewhere in the middle. Offering nice features, but with a simple backend. And it's this simplicity of the backend that draws people to phpwiki. I don't know Steve's plans for phpwiki, but I guess 1.3.x will go into this direction: keeping the core as simple as possible and make phpwiki more modular (so that people can add their favourite extension easily without bloating the core). > The nested IF-blocks would probably be one. > You need that if you want > something inserted only if three flags are true. That works already. See browse.html for an example (IF LOCK inside IF ADMIN) > PS. Can I ask you to just send replies to the mailing list? Right now, I > am getting two replies every time. Or does Kmail not have that option? Odd - I thought the list-prog doesn't send emails to people listed in To/CC. At least it does not send me an email if my address is inside To/CC. /Arno |
From: Steve W. <sw...@wc...> - 2000-12-07 20:15:43
|
On Thu, 7 Dec 2000, Arno Hollosi wrote: > > Ah, but that is the beauty of it all. All you have to do is say at the > > end of index.php > > include('templates/template.html'); > > Again: no it's not as easy as this. I want to have a string returned! > (e.g. dump html files in a ZIP file) so it basically becomes some form > of "eval('templates/template.html')" - and that means (among other things) > no echo, print, printf (not that that would be a major problem). Right... at one point it became necessary to stop generating HTML on-the-fly, and build the page in a string. Then the page is returned to the user in a single "echo" statement. The irony has never been lost on me that we took PHP and separated the display and logic the way we did, undoing exactly what PHP was meant to do. But this is a common theme; the JSP crowd have struggled with the same problem in the last year++ and have come up with the idea of "template engines" ala Cocoon from apache.org. And then one comes right back to the problem of "display logic," and ###IF### creeps in, and then there is a call for ELSE, FOREACH, WHILE etc. and we've come full circle. The problem is not really mixing display and logic; it's a people problem. We have designers who know HTML and can't/won't deal with <?php echo "foo" ?> constructs... and programmers who love to write recursive descent parsers in XSSI if possible, but couldn't match colors to save their lives. So the call to separate display and logic goes on, and the desire to unite them pushes back. > I don't know Steve's plans for phpwiki, but I guess 1.3.x will go into this > direction: keeping the core as simple as possible and make phpwiki more > modular (so that people can add their favourite extension easily without > bloating the core). Right... like so many great tools do. My model would be Emacs: with four or five basic commands, anyone can edit text files in Emacs. Simple. Over time you can write expert systems and even Wikis in Emacs Lisp. Powerful, simple, accessible. > > PS. Can I ask you to just send replies to the mailing list? Right now, I > > am getting two replies every time. Or does Kmail not have that option? > > Odd - I thought the list-prog doesn't send emails to people listed in To/CC. > At least it does not send me an email if my address is inside To/CC. I will reconfigure phpwiki-talk to reply-to the list, not the sender. We'll try it for a while and see how it works. sw ...............................ooo0000ooo................................. Hear FM quality freeform radio through the Internet: http://wcsb.org/ home page: www.wcsb.org/~swain |
From: Jan H. <hi...@wi...> - 2000-12-07 21:32:11
|
>On Thu, Dec 07, 2000 at 03:14:38PM -0500, Steve Wainstead wrote: > > And then one comes right back to the problem of "display logic," and > ###IF### creeps in, and then there is a call for ELSE, FOREACH, WHILE etc. > and we've come full circle. I think I am beginning to catch on. But why then not be radical about it and say "no IFs" (and BUTs :-)). Can the problem not be solved by introducing two browsing templates; one for normal users and one for administrators? Moreover, you could simply offer something like ###EDITLINK### that shows up as either the link to the edit page or as a message "page locked" and ###COPYLINK### that shows up as either a link to the the copy or a message "no copy available". I think that would cover al the IFs that are used now in the templates. But something tells me that Arno has probably already thought about this. :-) -- Jan Hidders |
From: Jan H. <hi...@wi...> - 2000-12-07 20:57:18
|
On Thu, Dec 07, 2000 at 08:20:13PM +0100, Arno Hollosi wrote: > > > But as you saw yourself, you are now forced to do this anyway. And I am > > very convinced that there is more to come. > > I'm not so convinced :o) Only the future will tell. Anyway, I said I would shut up, so I will. :-) Just a few minor points: > > Regular expressions are going to break down if you get things like nested > > IF-blocks. Or are you going to introduce a different type of IF-block for > > every possible combination of flags? > > Nested IF-blocks work already. The only thing you can't nest is twice the > same condition, i.e. ###IF:ADMIN### .... ###IF:ADMIN### > But I can't think of a case where such a construct is necessary. When you also introduce blocks for ###IF:COPY### and ##IF:LOCK## then the problem will appear. > > The nested IF-blocks would probably be one. > > You need that if you want > > something inserted only if three flags are true. > > That works already. See browse.html for an example (IF LOCK inside IF ADMIN) I know, but thats just *two* flags. Three will be a problem. > > If phpwiki really takes off (and that is what I expect) > > then these [user accounts et cetera] things will be added sooner or later. > > There are many other wiki-clones out there, so it's unlikely that phpwiki > will achieve world-domination. Er, world domination is not what I had in mind. :-) > E.g. tclwiki already has user identification, complete diff archive, and > more goodies. I didn't see that one. Is it the same as WiKit? And does it have database support? Because I see that as very important. > > PS. Can I ask you to just send replies to the mailing list? Right now, I > > am getting two replies every time. Or does Kmail not have that option? > > Odd - I thought the list-prog doesn't send emails to people listed in To/CC. > At least it does not send me an email if my address is inside To/CC. Hm. I have seen this reply only once, and now that I think of it, the one before the previous one also just once. It was only the last one that I received twice. So, never mind. If it happens again, I will say so. |
From: Arno H. <aho...@in...> - 2000-12-07 23:47:43
|
> > Nested IF-blocks work already. The only thing you can't nest is twice > > the same condition, i.e. ###IF:ADMIN### .... ###IF:ADMIN### > > But I can't think of a case where such a construct is necessary. > > When you also introduce blocks for ###IF:COPY### and ##IF:LOCK## then the > problem will appear. Why do I get the feeling that you didn't read the manual? ;) a) these if-blocks already exist b) there is no problem mixing them (unless there is some bug), because if you look at the corresponding endif it says ###ENDIF:COPY###, ###ENDIF:LOCK### -- no problems with a simple straight-forward regexp. > I know, but thats just *two* flags. Three will be a problem. I cannot see a difference between the case of 2 or 3 or 100 flags. Could you give an example? > But why then not be radical about it and say "no IFs" (and BUTs :-)). You do have a point there. And maybe this would be the more logical way. Unfortunately, I didn't give this option much thought when I had to deal with the problem at hand and thus IF and later IF-blocks creeped in. I feel guilty and ashamed. I start to like this IF-less idea more and more. Maybe we should migrate? I don't know - it's not such an urgent problem. /Arno |
From: Jan H. <hi...@wi...> - 2000-12-08 00:46:17
|
On Fri, Dec 08, 2000 at 12:47:33AM +0100, Arno Hollosi wrote: > > > Nested IF-blocks work already. The only thing you can't nest is twice > > > the same condition, i.e. ###IF:ADMIN### .... ###IF:ADMIN### > > > But I can't think of a case where such a construct is necessary. > > > > When you also introduce blocks for ###IF:COPY### and ##IF:LOCK## then the > > problem will appear. > > Why do I get the feeling that you didn't read the manual? ;) I only did a grep "IF:". That's what happens if you try to be clever. :-} > a) these if-blocks already exist > b) there is no problem mixing them (unless there is some bug), because > if you look at the corresponding endif it says ###ENDIF:COPY###, > ###ENDIF:LOCK### -- no problems with a simple straight-forward regexp. Hm. Now I see that you are matching the blocks seperately, once for COPY, once for LOCK and once for ADMIN. And that *does* work correctly unless you are nesting a COPY block inside a COPY block, but that would be nonsense anyway. So, yes, you are right, there will not be any problems with that. > I start to like this IF-less idea more and more. Maybe we should migrate? > I don't know - it's not such an urgent problem. Once people start really using it, it will be very hard to get it out again. By the way, what *are* the urgent problems? Is the list on sourceforge correct? -- Jan Hidders |
From: Steve W. <sw...@wc...> - 2000-12-08 04:00:19
|
On Fri, 8 Dec 2000, Jan Hidders wrote: > Once people start really using it, it will be very hard to get it out again. > By the way, what *are* the urgent problems? Is the list on sourceforge > correct? Except for the lead issue, which is: 1. Steve stops being lazy :-) Other than that, we are almost good to go with 1.2, and then we can break backwards compatibility and move on. I think we should not support php3 in 1.3.x and onwards. Also, the database libraries issue: it occurred to me that this is the kind of problem virtual base classes were meant to solve. I don't suppose PHP supports this kind of OOP? I'll check the manual now... sw ...............................ooo0000ooo................................. Hear FM quality freeform radio through the Internet: http://wcsb.org/ home page: www.wcsb.org/~swain |