Menu
▾
▴
phpwiki-talk
|
From: Jeff D. <da...@da...> - 2001-09-14 22:36:11
|
> this is great! Thanks again, Adam. > any chance of making categories meta data which is > selected via drop box on the edit page? and maybe a similar thing for > sub-categories? i know it kinda breaks the wiki ideal but i think it's > going to become increasingly useful as wiki's increase in complexity. To me, that seems like a lot of work (and complication) for not much gain. (And also fairly non-wiki-like.) Note that, at this point, the LikePages plugin can be used to generate a list of Categories or Topics on the fly. (And, I'm working on the ability to embed plugins within the templates, as well --- this would allow one to do fancy things like put a category index in a side-bar.) > also are comments (ie. they show up in the edit box but not on the actual > wiki page) a possibility? This is an interesting idea. It would be easy enough to hack this into the transform code --- one just needs to settle on a good markup syntax for comments. What kinds of things would you use this for? Jeff |
|
From: Jeff D. <da...@da...> - 2001-09-20 18:28:14
|
> Parse error: parse error in... Thanks for the report. I think it's fixed now. |
|
From: Adam S. <ad...@pe...> - 2001-09-20 18:41:43
|
> Thanks for the report. I think it's fixed now. yep, it came up, went down and came up again. looks great now. thanks. adam. |
|
From: Jeff D. <da...@da...> - 2001-10-04 16:39:53
|
Hi There,
Sorry, I've been AWOL for awhile. I'm still not quite back, but
thought I'd check in.
WikiNames:
I think case insensitivity in page names is a bad idea. Mostly for the
reasons that Malcolm Ryan listed. Capitalization is the punctuation
of a wiki --- capitals in WikiWords (should) have clear semantics
attached to them, and one should ignore them by smashing the case. (I
also think page names like EquipMent are a bad idea. That's why
brackets were introduced... better yet: add a word to make the page
name a more descriptive title: EquipmentInventory.)
I agree that HowToEatASandwich should match $WikiNameRegexp.
Subpages/Subwikis:
I see two separate ideas here:
Subpages really are just syntactic sugar, and merely provide a
shorthand notation for related pages. Here's, sort of, how I see this
would work:
Within page SuperPage, a link starting with a period, [.SubPage], would
refer to SuperPage.SubPage. I'm still uncertain as to:
1. Whether there can be sub-sub-pages.
2. If there is a shorthand notation which a sub-page can use
to refer to a sister subpage.
Subwikis are true partitions of the wiki namespace (with separate
RecentChanges, etc...). Within the page 'SubWiki/PageName', normal
links, like [OtherPage], refer to 'SubWiki/OtherPage'. If you want to
link to a page that's not in your subwiki, you have to start with a
slash ([/TopLevelPage], or [/OtherSubWiki/OtherPage]).
Plugins:
I like Joe's IncludePage plugin, and agree that it looks to be a good
way to provide partial page locking, etc... If no one beats me to it
I'll try to get it merged into the CVS code next week sometime.
Ticket tracking / ctime in link table:
It's doable. The "right way" to do it (IMHO) is to add the ability to
attach arbitrary meta-data to links, not just ctime. To be brutally
honest, it's not high on my todo list right now though...
Half-links:
Could easily be kludged with a plugin.
Mostly as an aside, somewhere (UseMod?) I saw a suggestion of using a
Category: InterWiki prefix as a hack for this. Category:Example would
be converted, by the InterWiki linker, to a link to CategoryExample,
but it won't show up as a backlink...
Templates:
What exactly do y'all mean by "templates"? I'm guessing you mean the
ability to choose between various content skeletons when you're editing
a new page.
If so, then, no there's currently no support for it. Here's how I
would envision adding support for them:
Hack lib/editpage.php so that when one edits an non-existant/empty
page, instead of the regular editpage form, one gets a template-choice
form. This would allow one to set the initial contents of the page to
any one of a set of skeletons. The skeletons would taken from pages
matching a particular pattern, like Template*. Eg. TemplateHomePage
would be a skeleton for a home page, ...
Once the user selects a template (or none), he gets the regular
editpage form...
Jeff
|
|
From: Adam S. <ad...@pe...> - 2001-10-04 18:10:15
|
> Subpages really are just syntactic sugar, and merely provide a > shorthand notation for related pages. Here's, sort of, how I see this > would work: okay after reading through all this on meatball i finally understand the point of this. this would be really useful for some of the stuff that happens on my wiki all the time where people don't want everythign on one page for some reason so they create a billion pages, all with the same prefix. > Within page SuperPage, a link starting with a period, [.SubPage], would > refer to SuperPage.SubPage. I'm still uncertain as to: while starting it with a . makes sense from a tech point of view i'm not sure it's obvious enough to clue in new users that there's something different about that page. / makes it obvious that something's different about it but really confused me because that means "root" in filesystem terms and that really not what it is. what about +? also, do subpages show up in RecentChanges? > 1. Whether there can be sub-sub-pages. i think this is probably asking for trouble. > Subwikis are true partitions of the wiki namespace (with separate > RecentChanges, etc...). Within the page 'SubWiki/PageName', normal > links, like [OtherPage], refer to 'SubWiki/OtherPage'. If you want to > link to a page that's not in your subwiki, you have to start with a > slash ([/TopLevelPage], or [/OtherSubWiki/OtherPage]). i think this is very useful for two things. * having one wiki run multiple different wiki's. this is sort of what twiki does so that by default it ships with a main, knowledge base, twiki ... wiki's by default. * automated plugins which create a lot of pages (maybe calendar, or todo, or addressbook or photogallery etc). however having now played with NiKKi which does this i have to say that it's not nearly as nice as it sounds. it gets really complicated and unituitive until you understand what all the categories are supposed to be used for. > Mostly as an aside, somewhere (UseMod?) I saw a suggestion of using a > Category: InterWiki prefix as a hack for this. Category:Example would > be converted, by the InterWiki linker, to a link to CategoryExample, > but it won't show up as a backlink... this is a great idea! thanks. > Hack lib/editpage.php so that when one edits an non-existant/empty > page, instead of the regular editpage form, one gets a template-choice > form. This would allow one to set the initial contents of the page to > any one of a set of skeletons. The skeletons would taken from pages > matching a particular pattern, like Template*. Eg. TemplateHomePage > would be a skeleton for a home page, ... this is exactly how moinmoin does it and it works pretty well. the only annoying thing is people's tendancy to create really dumb (and far too many) templates. it would be good to have a TemplateDefault as well so you can edit what gets loaded if they don't choose a template (i use this to put a [CategoryUnknown] at the bottom so i can search for things in the unknown category and categorize them). adam. |
|
From: Adam S. <ad...@pe...> - 2001-09-14 23:11:47
|
> To me, that seems like a lot of work (and complication) for not much > gain. (And also fairly non-wiki-like.) Note that, at this point, the > LikePages plugin can be used to generate a list of Categories or > Topics on the fly. there are some good reasons and some fairly trivial reasons i want this: * it gives an easy way to track un-categorized pages (because by default they go into CategoryUncategorized or something). * it stops false positives if someone mentions a categories page without that page actually belonging to a category. * it stops people making typos when typing the category names. * it means that i can have a category keyword and put it elsewhere in the page where it's more visible/prettier etc. > (And, I'm working on the ability to embed plugins within the > templates, as well --- this would allow one to do fancy things like > put a category index in a side-bar.) oooh! cool! now how about recent changes as a side bar as well, and recent changes and category pages as rdf for syndication to remote weblogs and wiki sites? i think the easist way to do this (and i've mumbled about this before so excuse me if you're sick of it already :-) is to make a generic output mode for any wiki page which will output as rdf/rss and then a php rss/rdf parser to build side boxes for whatever from that. > This is an interesting idea. It would be easy enough to hack this > into the transform code --- one just needs to settle on a good markup > syntax for comments. What kinds of things would you use this for? i forget the exact thing i wanted it for, but mostly for notes to people who are editing the page. commets could also be an easy way to embed meta data. #category: documentation:hardware #redirect: http://www.spack.org/ #redirect: WirelessCommunitites and then comments would just be: # blah blah # please leave the below lines intact. adam. |
|
From: Jeff D. <da...@da...> - 2001-09-14 23:55:13
|
On Sep 14, 2001, Adam Shand said: > i think the easist way to do this (and i've mumbled about this before so > excuse me if you're sick of it already :-) is to make a generic output > mode for any wiki page which will output as rdf/rss and then a php rss/rdf > parser to build side boxes for whatever from that. Yes. That may be the way to go, at least for RecentChanges, and also perhaps various search outputs. RSS RecentChanges have been on my todo list for awhile. (I've already hacked the PhpWiki 1.2.0 code which runs HammondWiki to produce an RSS version of recent changes.) http://www.dairiki.org/hammondwiki.rdf My main interest in RSS was to get a UnifiedRecentChanges index going. I've got a prototype sort of working, but have stopped working on it while I'm working on jeffs-hacks. http://matthews.dairiki.org/urc.html http://www.usemod.com/cgi-bin/mb.pl?UnifiedRecentChanges http://www.usemod.com/cgi-bin/mb.pl?RssExtensionModuleForWikis When you say RDF/RSS output for _any_ wiki page, what exactly do you mean? Do you want just the page meta-data (page name, author, edit date) or do you want all the content, too? I've been thinking about that a bit. I'm no expert, but it seems that RDF is ideally suited for the meta-data, but not really meant for storing the content. (It seems some more general form of XML might be better suited for that.) The other problem with RDF, is that I suspect it's going to be awhile before a good full-blown RDF parser is available in PHP. (Parsing RSS is one thing, parsing generic RDF is quite a bit trickier.) > and then comments would just be: > > # blah blah > # please leave the below lines intact. Of course, that syntax is already used in PhpWiki for ordered lists. It would have to be something uglier like: // please steal this comment |
|
From: Adam S. <ad...@pe...> - 2001-09-15 01:50:34
|
> http://www.dairiki.org/hammondwiki.rdf for the archives try this instead: http://www.dairiki.org/rss1.0/hammondwiki.rdf > My main interest in RSS was to get a UnifiedRecentChanges index going. > I've got a prototype sort of working, but have stopped working on it > while I'm working on jeffs-hacks. ah crap, i can't believe i didn't find this. i've been wanting this forever, and here i thought i was the only one. doh. > http://matthews.dairiki.org/urc.html does meatball already support an rss feed of it's RecentChanges? if not are you manually parsing it? > When you say RDF/RSS output for _any_ wiki page, what exactly do you > mean? well my original thought had been that you'd do something like this (i'm using moin syntax here cause i'm more familiar with it but you get the idea): http://personaltelco.net/index.cgi/RecentChanges?action=rss&num=10 or something like that. so that you could specify how many of the last changes you wanted. i have to apologise that i'm not hugely familiar with rss/rdf/xml yet but i'm learning. however if you're going to do that you may as well have any page be capable of being exported this way. this would be useful for my end goal which is wiki/weblog integration. now a category page exported as an rss feed and become a slashbox. > Do you want just the page meta-data (page name, author, edit date) or > do you want all the content, too? I've been thinking about that a > bit. in all the instances i can think of actually wanting to use it i would want the content exported as well eg. RecentChanges, CategoryXxxxx > I'm no expert, but it seems that RDF is ideally suited for the > meta-data, but not really meant for storing the content. (It seems > some more general form of XML might be better suited for that.) right but then we loose the main advantage of being able to munge wiki's into rss feeds and slashboxes. as sunir suggested an extension to the rss spec to cater to wiki's might be do-able. > The other problem with RDF, is that I suspect it's going to be awhile > before a good full-blown RDF parser is available in PHP. (Parsing RSS > is one thing, parsing generic RDF is quite a bit trickier.) i think we really want to shoehorn this into rss because the main point of it is to leverage other software that's already out there. unfortunately i'm not entirely sure what the differences between rss and rdf are as i search around for software for freshmeat rss and rdf seem to be used interchangably. > Of course, that syntax is already used in PhpWiki for ordered lists. > It would have to be something uglier like: > > // please steal this comment that'll work. sorry for the moin-ism :) adam. |
|
From: Adam S. <ad...@pe...> - 2001-09-15 06:32:21
|
> When you say RDF/RSS output for _any_ wiki page, what exactly do you > mean? oh. i forgot to include this. one of my other thoughts for any page to be an rss source was to to be able to use a wiki page as a source for the new weblog story syndication standards which are evolving. it would be nice, i think, to be able to use a wike as an evolving story and have weblog style comments attached to it. adam. |
|
From: Jeff D. <da...@da...> - 2001-09-15 16:16:03
|
> for the archives try this instead: > > http://www.dairiki.org/rss1.0/hammondwiki.rdf Yup. Sorry. > does meatball already support an rss feed of it's RecentChanges? if not > are you manually parsing it? I've got a perl script which at this point can parse the RecentChanges from UseMod and PhpWiki wikis. Dave Jacoby has done this all before me, too, and has his own version... (If you actually want RSS feeds from UseMod, Meatball or PhpWiki, let me know, I can put them someplace public...) > http://personaltelco.net/index.cgi/RecentChanges?action=rss&num=10 That's what I'm thinking, too... Note that some RSS implementations can't deal with more than 15 entries, so that's sort of the default value... > in all the instances i can think of actually wanting to use it i would > want the content exported as well eg. RecentChanges, CategoryXxxxx Okay, then we're on the same page... > as sunir suggested an extension to the rss spec to cater to wiki's > might be do-able. Actually, I'm the one who started that page on MeatballWiki. You're the first one who's shown much interest in it. > it would be nice, i think, to be able to use a wike as an evolving story > and have weblog style comments attached to it. Yes. I think Steve (Wainstead) has expressed interest in this idea as well. I think the idea for how to hook this into the wiki is to introduce "page types" --- the type of a page determines how it gets displayed (and edited). Straightforward, I think, but I'm not going to work on it, at this point. As an alternative, maybe there's a way to extend the plugin idea so that the plugin can read/write page (meta-)data. Then one could implement a weblog plugin. Yeah, in fact, that's kind of a neat idea... Jeff |
|
From: Adam S. <ad...@pe...> - 2001-09-16 19:48:53
|
> I've got a perl script which at this point can parse the RecentChanges > from UseMod and PhpWiki wikis. Dave Jacoby has done this all before > me, too, and has his own version... (If you actually want RSS feeds > from UseMod, Meatball or PhpWiki, let me know, I can put them > someplace public...) nah, it's of no real use to me until i can get it to work for me. which at this point either means writing a parser for moinmoin or hopefully waiting for your changes to propagate into the main phpwiki src and migrate to that. updating all the wiki syntax is gonna suck. > That's what I'm thinking, too... Note that some RSS implementations > can't deal with more than 15 entries, so that's sort of the default > value... good point, but there might be a time when you only want 5 ... or something like that. > Actually, I'm the one who started that page on MeatballWiki. You're > the first one who's shown much interest in it. oh, cool. sorry i musta mis-read the page. yeah, i'm really interested in this stuff. > As an alternative, maybe there's a way to extend the plugin idea so > that the plugin can read/write page (meta-)data. Then one could > implement a weblog plugin. Yeah, in fact, that's kind of a neat > idea... this sounds cool, i think the plugin architecture will be very valuable for all sorts of things in the long run. i need to bust out my php book and get my hands dirty. unfortunely running personaltelco sucks up most of my spare time. :) anyone else wish they didn't have to sleep? :) adam. |
|
From: Steve W. <sw...@pa...> - 2001-09-17 03:27:28
|
On Sat, 15 Sep 2001, Jeff Dairiki wrote:
> > it would be nice, i think, to be able to use a wike as an evolving story
> > and have weblog style comments attached to it.
>
> Yes. I think Steve (Wainstead) has expressed interest in this idea as
> well.
> I think the idea for how to hook this into the wiki is to introduce
> "page types"
> --- the type of a page determines how it gets displayed (and edited).
> Straightforward, I think, but I'm not going to work on it, at this
> point.
That was my idea some time ago. Conceptually, you can keep a weblog in one
of two ways:
1) You hand edit the Wiki markup every time you enter a new item. This is
obviously the hard way, but one can start today with no code changes ;-)
2) You have a sort of "helper form" to aid you in the formatting. It would
just be a series of <input>s for title, time, category, author, summary.
At some point I thought about other "types" of pages, and why not make
this process generic?
This is a sort of counterpart to the display templates... or perhaps,
something to be hacked into the templates? Is there any reason why we
can't use templates to create edit forms?
Then the next issue was database structure. This is where it gets to the
point where you want the pages stored as XML so you can have different
page types which transmogrify into whatever output you want (RSS, XHTML,
plain text, png image files, binary gibberish... you get the idea) and now
we should simply incorporate and sell the damn thing. I mean, it sounds
like WORK! ;-) But it's also the Right Thing, and we get into "don't let
the best be the enemy of the good," and all that philosophy about coding
and design.
Ahem. My preference for "Worse Is Better" would say, hack in a new form
for a WikiLog, or WikiWikiWebLog, or whatever you want to call it; later
someone will merge it into the template engine, and later someone will
generalize it so you can have multiple input forms for multiple page
types...
sorry for the ramble, but the escape from recent events is good.
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
http://pgp.document_type.org:11371/pks/lookup?op=get&search=0xF7323BAC
|
|
From: Jeff D. <da...@da...> - 2001-09-17 17:19:17
|
> That was my idea some time ago. Conceptually, you can keep a weblog in one
> of two ways:
>
> 1) You hand edit the Wiki markup every time you enter a new item. This is
> obviously the hard way, but one can start today with no code changes ;-)
>
> 2) You have a sort of "helper form" to aid you in the formatting. ....
The other thing you might want from a wiki-weblog is enforced
append-only
semantics.
This all ties in with the desire to write-protect portions of a page.
I think it was Reini who, some time ago, suggested a couple of ideas:
1. Append-only pages.
2. Partially locked pages --- only the part after the first <hr>
("--------" )
can be edited. (Except by the page owner, of course.)
Both seem like clean solutions to the partial locking problem. (Of
course
they are of limited use until user authentication is implemented more
completely.)
Which brings us to user authentication.
I recently had an idea: require every registered user to have a
WikiHomepage.
The user's userid would be the same as the pagename of their homepage.
This accomplishes several things:
1. Each user has a homepage (which would be linked to from
RecentChanges, etc..)
My guess is that most on wikis with authenticated users, each of
the
authenticated users would have a WikiHomepage with personal
thoughts,
contact information, etc. in any case.
2. We could store the users meta-data (password, e-mail, etc...) as
part of
their homepages meta-data. This eliminates the need for a
separate
user database.
Disadvantages: Somewhat kludgy, perhaps. Somewhat restrictive: if a
pagename
already exists, one must somehow usurp it (perhaps with admin
assistance ?)
to use it as a userid.
Is this a crackpot idea or a stroke of genious?
Jeff
|
|
From: Steve W. <sw...@pa...> - 2001-09-17 17:28:43
|
On Mon, 17 Sep 2001, Jeff Dairiki wrote:
> I think it was Reini who, some time ago, suggested a couple of ideas:
> 1. Append-only pages.
> 2. Partially locked pages --- only the part after the first <hr>
> ("--------" )
> can be edited. (Except by the page owner, of course.)
> Both seem like clean solutions to the partial locking problem. (Of
> course
> they are of limited use until user authentication is implemented more
> completely.)
I think it's inevitable that we have append-only mode. It will have many
uses.
> Which brings us to user authentication.
>
> I recently had an idea: require every registered user to have a
> WikiHomepage.
> The user's userid would be the same as the pagename of their homepage.
> This accomplishes several things:
> 1. Each user has a homepage (which would be linked to from
> RecentChanges, etc..)
> My guess is that most on wikis with authenticated users, each of
> the
> authenticated users would have a WikiHomepage with personal
> thoughts,
> contact information, etc. in any case.
> 2. We could store the users meta-data (password, e-mail, etc...) as
> part of
> their homepages meta-data. This eliminates the need for a
> separate
> user database.
Hmm. As a serialized string? You might want to expand on this. I think the
idea of them having a home page on the wiki is a natural.
> Disadvantages: Somewhat kludgy, perhaps. Somewhat restrictive: if a
> pagename
> already exists, one must somehow usurp it (perhaps with admin
> assistance ?)
> to use it as a userid.
>
> Is this a crackpot idea or a stroke of genious?
Like I said, it just seems like a natural. I would use SteveWainstead or
just 'wainstead' as an ID and would want my name to hyperlink to a page
about me.
What I would really like to see added is user registration, where users
must have a valid email address to register with the Wiki. This would be
useful for a public wiki that only allows members to edit pages, and
guests can only browse. In corporate intranets this would be essential.
~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
http://pgp.document_type.org:11371/pks/lookup?op=get&search=0xF7323BAC
|
|
From: Gary B. <ga...@in...> - 2001-09-17 17:33:02
|
On Mon, 17 Sep 2001, Steve Wainstead wrote: > What I would really like to see added is user registration, where users > must have a valid email address to register with the Wiki. This would be > useful for a public wiki that only allows members to edit pages, and > guests can only browse. In corporate intranets this would be essential. And then you could make it mangle email addresses if you weren't logged in -- instant spam filtering! Gary [ ga...@in... ][ GnuPG 85A8F78B ][ http://inauspicious.org/ ] |
|
From: Pablo R. <pr...@cl...> - 2001-09-18 02:44:14
|
> de Steve Wainstead > Enviado el: lunes, 17 de septiembre de 2001 19:29 > What I would really like to see added is user registration, > where users must have a valid email address to register with > the Wiki. This would be useful for a public wiki that only > allows members to edit pages, and guests can only browse. In > corporate intranets this would be essential. Yes, totally agreed. Time ago I did a hack in the phpwiki 1.2 for auth into PHPNuke 4.4, you can test at: http://www.opengate-team.org/phpwiki.php If you are not a registered member you can't edit pages, and also the user name is registered after a change. And only the admins are allowed to edit locked pages. I'm just thinking in implementing a better auth system, but I don't know if doing this in the 1.2 stable or wait till 1.3 this will depend on the timeline for having 1.3 released. The better way at all, would be having a funtion is_user() or similar, that any intranet or portal developer, can change for having is own authetification. Saludos, Pablo Roca |
|
From: Steve W. <sw...@pa...> - 2001-09-18 04:09:13
|
On Tue, 18 Sep 2001, Pablo Roca wrote:
> I'm just thinking in implementing a better auth system, but I don't know
> if doing this in the 1.2 stable or wait till 1.3 this will depend on the
> timeline for having 1.3 released.
Don't make any major changes to a 1.2 version, please... I would rather
stick to minor bug fixes or small changes for 1.2 and put the new features
into 1.3.
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
http://pgp.document_type.org:11371/pks/lookup?op=get&search=0xF7323BAC
|
|
From: Adam S. <ad...@pe...> - 2001-09-17 21:09:31
|
> Both seem like clean solutions to the partial locking problem. (Of > course they are of limited use until user authentication is > implemented more completely.) another feature that might be nice would be if a page could have multiple owners or maybe a group owner (and people can belong to a group). this all starts to get more complex but could be really useful. i've had thoughts about tying this into a weblogs karma system, so that any user with positive karma can edit the wiki pages. this provides a way for the community to deal with wiki spammers, and also makes it harder for someone brand new to the page to trash stuff, they have to hang around a little and contribute a bit to get privledges. > Disadvantages: Somewhat kludgy, perhaps. Somewhat restrictive: if a > pagename already exists, one must somehow usurp it (perhaps with admin > assistance ?) to use it as a userid. i don't see that as a problem, it just means that that username is unavailable, which could hapen anyway if there are two AdamShand's on the wiki. if the page name is taken you need to choose a new username. > Is this a crackpot idea or a stroke of genious? i think this is a good idea. adam. |
|
From: Pablo R. <pr...@cl...> - 2001-09-18 02:53:56
|
> de Adam Shand > Enviado el: lunes, 17 de septiembre de 2001 23:09 > another feature that might be nice would be if a page could > have multiple owners or maybe a group owner (and people can > belong to a group). this all starts to get more complex but > could be really useful. Yes this can be done but using two tables: user & groups, is more complex but more flexible, sure. A small intro is done here: http://www.opengate-team.org/phpwiki.php?OpenGate%20authorisation And here: http://postnuke.omaja.com/wiki/?UserAuthSystem Saludos, Pablo Roca |
|
From: Pablo R. <pr...@cl...> - 2001-09-18 02:25:17
|
> de Jeff Dairiki > Enviado el: lunes, 17 de septiembre de 2001 19:19 > I recently had an idea: require every registered user to have a > WikiHomepage. Hum ... Sorry for saying this Jeff, I'm totally disagree with this. Think that many users (err. Well for one of my webs, dont have a Wiki, don't know how to set a Pablo Roca |
|
From: Pablo R. <pr...@cl...> - 2001-09-18 02:30:52
|
> de Jeff Dairiki > Enviado el: lunes, 17 de septiembre de 2001 19:19 > I recently had an idea: require every registered user to have a > WikiHomepage. Hum .. Jeff .. Not a bad idea at all, but I rather prefer to have a user table, cause some users are very lazy for putting the needed info. Or putting an invalid email ..., and this will increase the wikidb for the pages. And ... How will you store the passwords there? Pablo Roca |
|
From: Reini U. <ru...@x-...> - 2001-09-18 11:00:14
|
Jeff Dairiki schrieb: > I recently had an idea: require every registered user to have a > WikiHomepage. The user's userid would be the same as the pagename > of their homepage. > Is this a crackpot idea or a stroke of genious? More the latter. But a user table is still needed for the password, email and page change notifications. I wouldn't store this in the homepage as metadata. Or do you have an idea to protect it for other users? (not viewable metadata, but editable for the owner...) -- Reini Urban |
|
From: Adam S. <ad...@pe...> - 2001-09-18 15:57:52
|
> > But a user table is still needed for the password, email and > page change notifications. > I wouldn't store this in the homepage as metadata. > Or do you have an idea to protect it for other users? > (not viewable metadata, but editable for the owner...) yep, it would be in a comment/metadata field in the page source. it would be viewable when edited but would not display in a browser (or even be in the html source). at least that was the lines i was thinking down. adam. |
|
From: Reini U. <ru...@x-...> - 2001-09-18 16:34:46
|
Adam Shand schrieb: > > But a user table is still needed for the password, email and > > page change notifications. > > I wouldn't store this in the homepage as metadata. > > > Or do you have an idea to protect it for other users? > > (not viewable metadata, but editable for the owner...) > > yep, it would be in a comment/metadata field in the page source. it would > be viewable when edited but would not display in a browser (or even be in > the html source). > > at least that was the lines i was thinking down. Seems to be simple and cool. for page change notifications everybody can just add his email as comment in a special meta tag. very cool! no need for a checkbox and database gyrations. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ |
|
From: Jeff D. <da...@da...> - 2001-09-18 16:43:42
|
On Sep 18, 2001, Reini Urban said: > for page change notifications everybody can just add his email > as comment in a special meta tag. very cool! > no need for a checkbox and database gyrations. To avoid becoming an instrument of spammage, we probably don't want to allow just anyone to sign arbitrary users (or e-mails) up for page change notifications. Or do we? |
×
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