phpwiki-talk

Re: [Phpwiki-talk] linking scheme and markup

[Gary B. <ga...@in...>]

On Thu, 8 Nov 2001, Adam Shand wrote:

>
> > Hmm. You remind me of an optimization I've thought about in the past:
> > when a page is saved after editing, convert it to xhtml and store it.
> > When pages are served, there's no transformation to do.

Almost right. If someone creates or deletes pages which are linked to from
a cached page then the cached page will be stale. You'd have to rebuild
them then as well.

> > When a page is pulled for editing, you have to convert it to wiki
> > markup again. The downside, of course, is twice as much code
> > (converting between the two formats).

Or you could just store the HTML and the wiki-markup in the DB, with the
wiki-version being the authoritative version.

> the really good thing about this though is that you get the static page
> cache.  for busy wiki sites having a static page cache becomes a necissity
> pretty quickly if you want to survive a slashdotting. :-(

If you are running your PhpWiki on your own webserver then you can put a
reverse-proxy in front of it. This is what /. does if I remember
correctly -- all pages have a five minute expiry time or something.

Gary

[ ga...@in... ][ GnuPG 85A8F78B ][ http://inauspicious.org/ ]

[Phpwiki-talk] review: Phortify

[Steve W. <sw...@pa...>]

I posted a list of auth libraries last night; one was Phortify, and by
chance there is an article about its creation:

http://www.phpbuilder.com/columns/tim20000505.php3

While this has all the features I want, it's written for mysql only. I
realized none of the libraries I've looked at support DB.php.

Another, azAuth, never released any files. Too many SF projects like that.
They should release a statistic of all projects that have actually
released something.

~swain

---
                  http://www.panix.com/~swain/
"Without music to decorate it, time is just a bunch of boring
production deadlines or dates by which bills must be paid."
                     -- Frank Zappa

Re: [Phpwiki-talk] wysiwyg

[Steve W. <sw...@pa...>]

Yes, just yesterday I started on a "classicweb.css" style sheet. That was
when I discovered I couldn't get a copy out of CVS on my laptop (OS X).

It will have a beautiful gray background and everything else will be user
defaults. To the extent possible.

~swain


On Thu, 8 Nov 2001, Sergio A. Kessler wrote:

> again :)
> this time with javascript... (and you can download the code)
> http://www.aspalliance.com/Yusuf/Article10a.asp
> (it will not work with mozilla, sorry, but maybe someone
> can hack it)
>
> and a question: is there any plan to clean up the visual
> design of phpWiki ?
> after seeing wikis like http://openwiki.com/ phpWiki look
> dirty and baroque...
>
> /sergio
>
> _______________________________________________
> Phpwiki-talk mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpwiki-talk
>

---
                  http://www.panix.com/~swain/
"Without music to decorate it, time is just a bunch of boring
production deadlines or dates by which bills must be paid."
                     -- Frank Zappa

[Phpwiki-talk] wysiwyg

[Sergio A. K. <ser...@ho...>]

again :)
this time with javascript... (and you can download the code)
http://www.aspalliance.com/Yusuf/Article10a.asp
(it will not work with mozilla, sorry, but maybe someone
can hack it)

and a question: is there any plan to clean up the visual 
design of phpWiki ?
after seeing wikis like http://openwiki.com/ phpWiki look
dirty and baroque...

/sergio

Re: [Phpwiki-talk] linking scheme and markup

[Adam S. <ad...@pe...>]

> Hmm. You remind me of an optimization I've thought about in the past:
> when a page is saved after editing, convert it to xhtml and store it.
> When pages are served, there's no transformation to do. When a page is
> pulled for editing, you have to convert it to wiki markup again. The
> downside, of course, is twice as much code (converting between the two
> formats).

the really good thing about this though is that you get the static page
cache.  for busy wiki sites having a static page cache becomes a necissity
pretty quickly if you want to survive a slashdotting. :-(

adam.

Re: [Phpwiki-talk] Re: phpwiki 1.3.1

[Geoffrey T. D. <da...@da...>]

(Resend: I botched one of the e-mail addresses in the last send.
I apologize in advance in case you get this twice.)

> On Thu, 8 Nov 2001, Keith wrote:
> 
> > I keep getting errors such as:
> > Fatal error: Cannot instantiate non-existent class:
> > wikidb_mysql://hubil:hub@phpwiki131 in e:\phpwiki-1.3.1
> > \lib\WikiDB.php on line 76

My guess is that you've slightly botched the config file.
It looks like $DBParams['dbtype'] is set to 'mysql://hubil...'.

$DBParams['dbtype'] should be set to 'SQL', $DBParams['dsn'] should
be set to 'mysql:://hubil:hub@localhost/phpwiki131' (or similar).

If you're still stuck, send me a copy of your index.php...

[Phpwiki-talk] xml, xhtml

[Tara S. <te...@cl...>]

Have any of you guys taken a look at OpenWiki?
http://openwiki.com/ow.asp?OpenWiki

they output xml and xhtml. Might be of inspiration?

Tara
--=20
Je r=E9ponds au mieux de mes connaissances
Climb to the Stars! - http://climbtothestars.org/
no tables: http://climbtothestars.org/coding/tableless/
Pompeurs Associ=E9s - http://pompage.net/

[Phpwiki-talk] Re: phpwiki 1.3.1

[Steve W. <sw...@pa...>]

My guess initially is that you don't have the latest PEAR stuff.... though
the error seems to suggest otherwise. Have you upgraded PEAR/know how to
upgrade PEAR?

~swain

On Thu, 8 Nov 2001, Keith wrote:

> I have installed and run phpwiki versions 1.2.0 and 1.2.1
> with no problems.  Great program.
>
> I have tried to install and run both the CVS and download
> versions of phpwiki 1.3.1 with no success.  I have edited
> the index.php to reflect my settings with no success.
>
> I keep getting errors such as:
> Fatal error: Cannot instantiate non-existent class:
> wikidb_mysql://hubil:hub@phpwiki131 in e:\phpwiki-1.3.1
> \lib\WikiDB.php on line 76
>
> Any suggestions on how or what needs to be done to
> configure phpwiki 1.3.1 to run on my sustem?
>
> I am running phpwiki on the following system:
> Pentium III 550 mhz with 256 mb
> 62 gb disk space
> Windows 2000 professional sp2 with all updates
> Apache 1.3.22
> MySQL 3.23.41-nt
> PHP 4.06
>
> Thanks in advance.
> Regards,
> Keith Senkoe
> hu...@vs...
>

---
                  http://www.panix.com/~swain/
"Without music to decorate it, time is just a bunch of boring
production deadlines or dates by which bills must be paid."
                     -- Frank Zappa

Re: [Phpwiki-talk] linking scheme and markup

[Reini U. <ru...@x-...>]

Jeff Dairiki schrieb:
> 
> On Wed, 07 Nov 2001 13:19:24 +0000
> "Reini Urban" <ru...@x-...> wrote:
> 
> > mysql 3.22.30 is too old. we are at 3.23.x
> > remove USING(id) as Jeff sent you.
> 
> Though I don't think there's any fundamental reason we can't or
> shouldn't support mysql 3.22.30.
> 
> Tara/Steph: if you figure out anything, do let me know...
> 
> My current hunch is that the older mysql has a problem
> specifically with the INNER JOIN ... USING(...) syntax
> and that "LEFT JOIN ... USING(...)" would work fine.
> I'd like some confirmation of that, though, before I act
> on it.

mysql 3.22.25:

[ok] SELECT topage, count(*) AS nlinks FROM wikilinks LEFT JOIN wiki AS dest
ON topage=dest.pagename WHERE dest.pagename IS NULL GROUP BY topage ORDER BY
nlinks DESC;

[ok] select distinct pagename from wiki left join wikilinks on pagename=topage
where topage is NULL order by pagename;
(but aching slow! 13 sec on 500/3200 pages/links)

[ok] select w.pagename,s.score from wiki as w left join wikiscore s on
w.pagename=s.pagename;

[ok] select w.pagename,s.score from wiki as w left join wikiscore s using
(pagename);

fail:
mysql> SELECT topage, count(*) AS nlinks FROM wikilinks inner JOIN wiki AS
dest ON topage=dest.pagename WHERE dest.pagename IS NULL GROUP BY topage ORDER
BY nlinks DESC;
ERROR 1064: You have an error in your SQL syntax near 'ON topage=dest.pagename
WHERE dest.pagename IS NULL GROUP BY topage ORDER BY nli' at line 1

mysql> select w.pagename,s.score from wiki as w inner join wikiscore s using
(pagename);
ERROR 1064: You have an error in your SQL syntax near 'inner join wikiscore s
using (pagename)' at line 1

mysql> select w.pagename,s.score from wiki as w join wikiscore s using
(pagename);
ERROR 1064: You have an error in your SQL syntax near 'using (pagename)' at
line 1

mysql> select w.pagename,s.score from wiki as w outer join wikiscore s using
(pagename);
ERROR 1064: You have an error in your SQL syntax near 'outer join wikiscore s
using (pagename)' at line 1

I see no advantage in JOIN ... USING, besides shorter strings. 
but left join ... using is okay.
 
> Perhaps, for maximum portability, we/I should convert all
> the joins to plain cross joins.  Instead of
>   SELECT FROM x INNER JOIN y USING(id) WHERE ...
> use the archaic:
>   SELECT FROM x,y WHERE x.id=y.id AND ...

Agreed. There's no speed improvement in USING, but a portability problem.
In another big php project of mine which still supports php3, we use 
           SELECT FROM x,y WHERE x.id=y.id ...
and better SELECT FROM x LEFT JOIN y ON x.id = y.id WHERE ...
http://www.theexchangeproject.org
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] linking scheme and markup

[Steve W. <sw...@pa...>]

On Wed, 7 Nov 2001, Adam Shand wrote:

> > I've wanted to do XHTML output for a while. That might be a good
> > middle step for now.
>
> i like the idea of xml file storage.  this might make sense for the text
> file backend as well.  convert wiki markup to xml and then xml to html.

Hmm. You remind me of an optimization I've thought about in the past: when
a page is saved after editing, convert it to xhtml and store it. When
pages are served, there's no transformation to do. When a page is pulled
for editing, you have to convert it to wiki markup again. The downside, of
course, is twice as much code (converting between the two formats).

~swain

---
                  http://www.panix.com/~swain/
"Without music to decorate it, time is just a bunch of boring
production deadlines or dates by which bills must be paid."
                     -- Frank Zappa

Re: [Phpwiki-talk] linking scheme and markup

[Adam S. <ad...@pe...>]

> What I want to avoid is making the end user rebuild PHP in order to use
> PhpWiki. It would never get used in that case.

i like this decision, i get really frustrated with projects that spend all
their time rewriting the backend to be better when it doesn't have any (or
minimal) tangible benifit to the end user (me! :-).

> I have never used Galeon for this very reason: it wants all the latest
> Gnome stuff and I have no patience to install it all.

see?  you need debian ...

# apt-get install galeon

i just swapped over about a month ago and am very happy with it.  it's
faster then mozilla, has more features then mozilla and actually has some
cool new stuff (smart bookmarks are great).

> I've wanted to do XHTML output for a while. That might be a good
> middle step for now.

i like the idea of xml file storage.  this might make sense for the text
file backend as well.  convert wiki markup to xml and then xml to html.

adam.

Re: [Phpwiki-talk] bug in zip loading?

[Jeff D. <da...@da...>]

On Wed, 7 Nov 2001 17:25:56 -0500 (EST)
"Steve Wainstead" <sw...@pa...> wrote:

> *sound of face slapping forehead*

Perhaps we should alter the Virgin Wiki Detection System (VWDS).
Maybe only load initial page source if the page database is
truly empty (i.e. zero pages)?  Or is a reason we're doing it
the current way (looking for FrontPage/HomePage.)

Also someone will need to go through and update most of the pages
which are in phpwiki-1.3.1/pgsrc/*, since you need up-to-date
versions of many of these for things to work okay.

(E.g. I just fixed RecentChanges...)

I think perhaps a better upgrade path is:
 0. Make zip-dump of old wiki.
 1. Start new wiki with virgin/wiped database, so that it
    loads the default (distributed) pgsrc.
 2. Manually (via PhpWikiAdministration) load the zip
    you made of the old wiki.  This overwrites the distributed
    pgsrc, so, e.g. PhpWikiAdministration will be broken after
    this step.
 3. Go back and manually edit the broken magic pages.  Now this
    job is easier since the working/distributed versions are
    archived...

Any ideas on things we can do to make this easier?

(If we had subwikis, we could have a subwiki which contains
most of the distributed pgsrc, and just replace that with the new
versions on every upgrade.)

[Phpwiki-talk] new site is up

[Steve W. <sw...@pa...>]

Ok, I've ported all the pages over to the new site:

http://phpwiki.sf.net/phpwiki-1.3/

This will become the main site after a shakedown. It seems locking one
page locks them all.

~swain

---
                  http://www.panix.com/~swain/
"Without music to decorate it, time is just a bunch of boring
production deadlines or dates by which bills must be paid."
                     -- Frank Zappa

Re: [Phpwiki-talk] bug in zip loading?

[Steve W. <sw...@pa...>]

*sound of face slapping forehead*

There was no HomePage in the current site. All I had to do was look at the
code. I'll put a note in UPGRADING.

~swain

On Wed, 7 Nov 2001, Steve Wainstead wrote:

>
> Hi Jeff,
>
> I got a zip dump of the site, checked out the latest source into
> phpwiki-1.3, put the zip file in there, edited index.php... the first time
> I went to the site
>
> http://phpwiki.sf.net/phpwiki-1.3/
>
> it loaded the zip file. When I followed the link HomePage, it loaded it
> again... and then again... every time I try to load it. However I'm able
> to read RecentChanges just fine.
>
> ~swain
>
> ---
>                   http://www.panix.com/~swain/
> "Without music to decorate it, time is just a bunch of boring
> production deadlines or dates by which bills must be paid."
>                      -- Frank Zappa
>
>
> _______________________________________________
> Phpwiki-talk mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpwiki-talk
>

---
                  http://www.panix.com/~swain/
"Without music to decorate it, time is just a bunch of boring
production deadlines or dates by which bills must be paid."
                     -- Frank Zappa

[Phpwiki-talk] bug in zip loading?

[Steve W. <sw...@pa...>]

Hi Jeff,

I got a zip dump of the site, checked out the latest source into
phpwiki-1.3, put the zip file in there, edited index.php... the first time
I went to the site

http://phpwiki.sf.net/phpwiki-1.3/

it loaded the zip file. When I followed the link HomePage, it loaded it
again... and then again... every time I try to load it. However I'm able
to read RecentChanges just fine.

~swain

---
                  http://www.panix.com/~swain/
"Without music to decorate it, time is just a bunch of boring
production deadlines or dates by which bills must be paid."
                     -- Frank Zappa

[Phpwiki-talk] a few auth libraries

[Steve W. <sw...@pa...>]

I haven't really looked at these, just spent the time tracking them down.
I found them all via Freshmeat or Sourceforge. There were a *lot* of
supposed PHP auth packages on SF that had no web site and had no files
released. The best laid plans of mice and men... Or should I say, the road
to hell is paved with good intentions...

Horde Application Framework:
http://freshmeat.net/projects/horde/

Lib2 PHP:
http://ziet.zhitomir.ua/~fonin/code/

A set of classes from some developer:
http://www.arcabama.com/framesets/freeware.html

Of course, PHPLib:
http://sourceforge.net/projects/phplib/

phpMember:
http://freshmeat.net/projects/phpmember/

phpSecurePages:
http://freshmeat.net/projects/phpsecurepages/

Phortify. The description on this one makes me hopeful:
http://sourceforge.net/projects/phortify/

Prolly overkill: phpShop
http://sourceforge.net/projects/phpshop/

azAuth also sounds too promising to be true:
http://sourceforge.net/projects/azauth/

~swain

---
                  http://www.panix.com/~swain/
"Without music to decorate it, time is just a bunch of boring
production deadlines or dates by which bills must be paid."
                     -- Frank Zappa

[Phpwiki-talk] Re: user auth/email notification (fwd)

[Steve W. <sw...@pa...>]

---
                  http://www.panix.com/~swain/
"Without music to decorate it, time is just a bunch of boring
production deadlines or dates by which bills must be paid."
                     -- Frank Zappa
---------- Forwarded message ----------
Date: Wed, 7 Nov 2001 17:42:20 +0000 (GMT)
From: Gary Benson <ga...@in...>
To: Jeff Dairiki <da...@da...>
Cc: Steve Wainstead <sw...@pa...>, Pablo Roca <pr...@cl...>
Subject: Re: user auth/email notification


This chat should really be happening on the list...
G

On Wed, 7 Nov 2001, Jeff Dairiki wrote:

> On Wed, 7 Nov 2001 11:30:01 -0500 (EST)
> "Steve Wainstead" <sw...@pa...> wrote:
>
> > Here's how I'd like to see this work:
> [...many good ideas deleted...]
>
> > (Perhaps later we can expand that to include ACLs, and there will be
> pages
> > that can/cannot be edited depending on the user. We can just copy the
> way
> > Unix does stuff. I would think that would be enough control.)
>
> I say we should plan the ACL mechanism in from the beginning, since we
> know we want it.  Unix-style access controls are, I think, sufficient,
> provided we include the group access mechanisms (each user can be a
> member of an arbitrary number of groups; each object can control access
> to three types of users: the owner (a user), the owning group, everybody
> else.)  On the other hand, why not real ACLs (where one can specify access
> for multiple users/groups)?
>
>
> Also, and this has been talked about before, with no real resolution, it
> would sure be nice to find an already written library to handle this stuff
> for us.  I keep meaning to look into the PHPNuke, etc... thingies, but
> haven't gotten around to it yet.
>
>

[ ga...@in... ][ GnuPG 85A8F78B ][ http://inauspicious.org/ ]

[Phpwiki-talk] Re: user auth/email notification (fwd)

[Steve W. <sw...@pa...>]

dunno why this wasn't on the list...

---
                  http://www.panix.com/~swain/
"Without music to decorate it, time is just a bunch of boring
production deadlines or dates by which bills must be paid."
                     -- Frank Zappa
---------- Forwarded message ----------
Date: Wed, 7 Nov 2001 09:38:39 -0800
From: Jeff Dairiki <da...@da...>
To: Steve Wainstead <sw...@pa...>
Cc: Gary Benson <ga...@in...>, Pablo Roca <pr...@cl...>
Subject: Re: user auth/email notification

On Wed, 7 Nov 2001 11:30:01 -0500 (EST)
"Steve Wainstead" <sw...@pa...> wrote:

> Here's how I'd like to see this work:
[...many good ideas deleted...]

> (Perhaps later we can expand that to include ACLs, and there will be
pages
> that can/cannot be edited depending on the user. We can just copy the
way
> Unix does stuff. I would think that would be enough control.)

I say we should plan the ACL mechanism in from the beginning, since we
know we want it.  Unix-style access controls are, I think, sufficient,
provided we include the group access mechanisms (each user can be a
member of an arbitrary number of groups; each object can control access
to three types of users: the owner (a user), the owning group, everybody
else.)  On the other hand, why not real ACLs (where one can specify access
for multiple users/groups)?


Also, and this has been talked about before, with no real resolution, it
would sure be nice to find an already written library to handle this stuff
for us.  I keep meaning to look into the PHPNuke, etc... thingies, but
haven't gotten around to it yet.

Re: [Phpwiki-talk] linking scheme and markup

[Jeff D. <da...@da...>]

On Wed, 07 Nov 2001 13:19:24 +0000
"Reini Urban" <ru...@x-...> wrote:

> mysql 3.22.30 is too old. we are at 3.23.x
> remove USING(id) as Jeff sent you.

Though I don't think there's any fundamental reason we can't or 
shouldn't support mysql 3.22.30.

Tara/Steph: if you figure out anything, do let me know...

My current hunch is that the older mysql has a problem
specifically with the INNER JOIN ... USING(...) syntax
and that "LEFT JOIN ... USING(...)" would work fine.
I'd like some confirmation of that, though, before I act
on it.

Perhaps, for maximum portability, we/I should convert all
the joins to plain cross joins.  Instead of
  SELECT FROM x INNER JOIN y USING(id) WHERE ...
use the archaic:
  SELECT FROM x,y WHERE x.id=y.id AND ...

?

Re: [Phpwiki-talk] web site clean up.

[Jeff D. <da...@da...>]

On Tue, 6 Nov 2001 21:44:04 -0800 (PST)
"Adam Shand" <ad...@pe...> wrote:

> okay well i've deleted all (unless i missed some) of the cruft that is
> shown in the RecentChanges pages.  i'll start in on the older stuff
soon.

Excellent!  I don't think it's necessary to make a complete clean
sweep of everything.

> ..the things that would be really useful for this process... 
>  * a page which lists all the pages
>  * an orphaned pages implementation
>  * a wanted pages implementation
>  * phpwiki 1.3 plugins :-) to help with dynamically generating category
>    pages

Yes, I think we've agreed to upgrade (soon) the main wiki to 1.3.x.
When that happens the rest will follow.

>  * allowing the right hand side of interwiki maps to not be WikiWords
(for
>    the cool interwiki category hack).

I think this is already allowed?

> there is a page showing up in RecentChanges called www.idanetwork.org
but
> when you go to it you get the FrontPage...

Yes, I stumbled across this bug yesterday (synchronicity at work).
You can get around it by url-encoding the periods in the page name:

  http://phpwiki.sourceforge.net/phpwiki/?www%2eidanetwork%2eorg

(The bug is fixed in CVS.) 

Thank you for the use of your delete key!

Re: [Phpwiki-talk] linking scheme and markup

[Jeff D. <da...@da...>]

On Wed, 7 Nov 2001 02:06:24 -0500 (EST)
"Steve Wainstead" <sw...@pa...> wrote:

> I've wanted to do XHTML output for a while. That might be a good middle
> step for now.

I don't know much about XHTML, so fill me in.
Steve, Tara, those who know: If we move to XHTML what are the
implications for those who use older browsers?  What exactly
are the practicalities involved in converting to XHTML?
Is it really much of a new paradigm (if so, I don't see it
yet) or is it just syntactical cleanup?

It would be nice to clean up the output (HTML) generation
some.  As Tara has discovered the HTML is scattered, 
mostly between the templates, lib/transform.php, various
functions in lib/stdlib.php, with the remainder everywhere
else.

But I agree with Steve, that until/unless there's a widespread,
easily accessible XSLT converter available for PHP it's too early
to move completely in that direction.

> I've also wanted an XML dump feature for PhpWiki; that is,
> all the pages can be dumped as one huge XML file.

(Or indididual XML files.)

> But Jeff's zip dumps work so well there's been no need.

Since i dooed it, I can say it: the use of MIME for storing metadata
in the zip files was/is somewhat poorly concieved.

I'm all for moving to XML for page dumpage.  The only drawback,
is that (for awhile, at least) we'd have to support three methods
of undumping (zip, serialized pages, XML).  (The other drawback,
of course, is that someone would have to write the code.)

Re: [Phpwiki-talk] linking scheme and markup

[Reini U. <ru...@x-...>]

Tara Star schrieb:
> seems I'm getting my mail now, at least. Otherwise, st...@po...
> works : ) (though I'm sure I've lost loads of mail during these last
> days, but that's another story)
> 
> http://tara.scdi.org/phpinfo.php will give you my version of mysql. I'll
> try running the query manually (I've found someone to walk me through
> it!) and I'll let you know if it works or not.

mysql 3.22.30 is too old. we are at 3.23.x
remove USING(id) as Jeff sent you.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] linking scheme and markup

[Steve W. <sw...@pa...>]

On Wed, 7 Nov 2001, Tara Star wrote:

> In the present case, I can't obtain the desired result just by modifying
> the css files - I need to go in the templates, and in transform.php too
> (and GodKnowsWhereElse).
>
> See what I mean?

Yes, CSS is not enough. I know, I've worked on content management systems
for five years now. :-) I'll continue to think about it. It depends on
what we get with a "typical" PHP install. My goal has always been to make
PhpWiki as accessible as possible: to admins, to programmers, and to end
users.

Your problem is an admin problem: you can't tailor the output at the low
level you want to. When XSLT is shipped with PHP and comes in a default
installation, it would make sense to go this route.

What I want to avoid is making the end user rebuild PHP in order to use
PhpWiki. It would never get used in that case. I have never used Galeon
for this very reason: it wants all the latest Gnome stuff and I have no
patience to install it all.

I've wanted to do XHTML output for a while. That might be a good middle
step for now.

cheers
~swain

---
                  http://www.panix.com/~swain/
"Without music to decorate it, time is just a bunch of boring
production deadlines or dates by which bills must be paid."
                     -- Frank Zappa

Re: [Phpwiki-talk] linking scheme and markup

[Tara S. <te...@cl...>]

Steve Wainstead wrote:


> I didn't mean to imply that XML is only for WAP and PDAs. I've also wan=
ted
> an XML dump feature for PhpWiki; that is, all the pages can be dumped a=
s
> one huge XML file. But Jeff's zip dumps work so well there's been no ne=
ed.


I think the suggestion here was more to make xml the "natural output=20
markup" for the wiki - instead of html4.1 trans as it is now. For=20
example, I'm going to have to hack through all the markup production to=20
tailor the wiki's looks to my liking - whereas if the production was=20
xml, I could do it simply by modifying the stylesheet.

In the present case, I can't obtain the desired result just by modifying=20
the css files - I need to go in the templates, and in transform.php too=20
(and GodKnowsWhereElse).

See what I mean?

Tara


--=20
Je r=E9ponds au mieux de mes connaissances
Climb to the Stars! - http://climbtothestars.org/
no tables: http://climbtothestars.org/coding/tableless/
Pompeurs Associ=E9s - http://pompage.net/

Re: [Phpwiki-talk] linking scheme and markup

[Steve W. <sw...@pa...>]

On Wed, 7 Nov 2001, Tara Star wrote:

> Steve Wainstead wrote:
>
> > However, I don't think anyone will be wanting to edit Wiki pages on their
> > WAP phones or Palm Pilots anytime soon. Who knows? At the moment it sounds
> > to me like gold plating, which we developers love to do ;-)
>
> Producing output in xml isn't just for WAP and PalmPilot users. It makes
> life much simpler for webmasters - see for example http://whump.com
> which runs on XML (there are countless other sites that do too).
>
> As for Palm... when I talked about wikis at work, one of the first
> questions I was asked was "can you access it and edit it with a Palm?"

Figures! :-)

I didn't mean to imply that XML is only for WAP and PDAs. I've also wanted
an XML dump feature for PhpWiki; that is, all the pages can be dumped as
one huge XML file. But Jeff's zip dumps work so well there's been no need.

~swain

---
                  http://www.panix.com/~swain/
"Without music to decorate it, time is just a bunch of boring
production deadlines or dates by which bills must be paid."
                     -- Frank Zappa