Menu
▾
▴
phpwiki-talk
|
From: Steve W. <sw...@pa...> - 2001-09-17 04:31:06
|
This gentleman volunteers to add a ticket tracking system. I dunno. Thoughts? ~swain On Sat, 8 Sep 2001, Joe Edelman wrote: > Hello. I'm a new person interested in hacking on phpWiki. > > I have a bit of an agenda, though: I want to use it as an intranet for a > non-profit I'm putting together, so I want to add some business/intranet > features. > > The only thing I want to add that's not already on your 1.3 to-do list is a > ticket tracking system. I'd like to be able to embed tickets in wiki pages, > using a syntax like "((finance:approve))", and then have them visible from a > ticket tracking system. This could be seen as an extension of what you're > already doing with search and "CategoryCategory" tags: a new mechanism for > letting people list and sort pages by certain criteria. > > I'm also interested in and willing to help with user authentication and the > weblog/templating facility you describe. > > It seems like I can do these tickets using this new plugin system that Jeff > has made, although it needs to be extended in a small way. > > I'm not quite sure how to proceed: can I assume that Jeff's changes will > probably become the HEAD? Should I write a proposal about how I might > implement these tickets, then, and post it to the mailing list fpr review? > > Thanks, and thanks for putting this project and this software together-- > it's something to be proud of. > > Joe Edelman > Varanasi / Boston / San Francisco > <http://orbis-tertius.net/joe/> > --- 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: Reini U. <ru...@x-...> - 2001-09-17 09:45:24
|
Steve Wainstead schrieb: > This gentleman volunteers to add a ticket tracking system. I dunno. > Thoughts? I'm not really familiar with the term "ticket tracking". I'm currently implementing a big B2B E-Commerce site with session tracking and user-auth, so I probably know the problem and implementation. To me "ticket tracking" seems to be an identification/authentification method for asynchronous communication, mostly by e-mail. A unique tag bound to a user or session. Joe, could you please elaborate what this system should do in more detail? Do you want to add a parsable tag in the HTML code to be able to grep and filter it? Or a page column in the DB? something like: "list all pages where finance == approved", "search in all pages where finance != approved" html: <!-- tag: finance:approve --> or something visible. ticket plugin: filter all multipage queries (search, list, ...) by a user-defined filter. > On Sat, 8 Sep 2001, Joe Edelman wrote: > > Hello. I'm a new person interested in hacking on phpWiki. > > > > I have a bit of an agenda, though: I want to use it as an intranet for a > > non-profit I'm putting together, so I want to add some business/intranet > > features. > > > > The only thing I want to add that's not already on your 1.3 to-do list is a > > ticket tracking system. I'd like to be able to embed tickets in wiki pages, > > using a syntax like "((finance:approve))", and then have them visible from a > > ticket tracking system. This could be seen as an extension of what you're > > already doing with search and "CategoryCategory" tags: a new mechanism for > > letting people list and sort pages by certain criteria. > > > > I'm also interested in and willing to help with user authentication and the > > weblog/templating facility you describe. > > > > It seems like I can do these tickets using this new plugin system that Jeff > > has made, although it needs to be extended in a small way. > > > > I'm not quite sure how to proceed: can I assume that Jeff's changes will > > probably become the HEAD? Should I write a proposal about how I might > > implement these tickets, then, and post it to the mailing list fpr review? -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ |
|
From: Pablo R. <pr...@cl...> - 2001-09-18 02:20:27
|
Reini wrote: > I'm not really familiar with the term "ticket tracking". Agreed Reini. I also don't understand what Joe is trying to do. Maybe I'm not english spoken ... Pablo Roca |
|
From: <jo...@or...> - 2001-09-19 23:53:29
|
Hello everyone.
"Ticket tracking" is like a to-do list for a group of people, or for many
groups of people. The phpwiki to-do list on sourceforge is a kind of
ticket tracker, as are bug trackers like the ones on sourceforge or
"Bugzilla". Help desks and call centers often use ticket tracking systems
to keep track of who they've helped and who else needs help.
Generally a ticket corresponds to some task that needs doing or something
that needs attention-- a disk that needs to be backed up, or a customer who
needs to be called back, or a report that needs to be looked over and
signed by a manager. Tickets begin their lives "open", and when the task is
completed, they are "closed". Generally tickets contain some more state
than just that: they may know what kind of skills are necessary for their
completion, and they have a log of who has done work towards that ticket
and any comments they left. Anyone can log in to the ticket tracking
system and see, with one search, which "open" (not-yet-completed) tickets
(tasks) there are for people with their expertise.
What I'm proposing is to add some new syntax to phpWiki pages that
integrate them into a ticket tracking system, so that if someone writes
text like "((finance:approve))" in their wiki page-- which means that they
want someone from the finance department to approve what they've written on
the page-- then a new ticket will be created which says just that. If ever
someone from finance edits the page and removes that text
("((finance:approve))"), the ticket is closed.
Other tickets might look like:
((sales:rewrite))
((CEO:approve))
((george:explain))
Or, if you're a small company or just a single person, you can use this
system for reminders for yourself about where in your phpwiki you would
like some additional information, or what you would like to rewrite, using
the shorter form:
((rewrite))
((check))
((fixme))
And then from one page, the ticket tracking page, you get links to every
wiki page that needs some work, and you can search or sort through these
wiki pages based on what kind of expertise they need (sales/CEO/george) or
what needs to be done (rewrite/approve/explain/check), or when they were
last worked on, or who entered the request, etc.
NOTES AS TO IMPLEMENTATION
1. It's clear that this feature wouldn't be of use to everyone, and the
phpwiki syntax-space is already getting kind of cluttered. It would be
nice, and fairly easy, to be able to turn syntax elements, including
ticket recognition ("(())"), on and off. So maybe a global ("define()")
in the index.php file would turn this whole system on and off, and it
would be off by default.
2. The logical time to create/open/close tickets is when the page
containing them (or from which they have been deleted) is first saved.
Right now the only parsing of page text on save is for converting tabs.
This is in savepage.php. I would have to add something, either there or
in WikiDB_PageRevision::createRevision(), that checks for occurrences of
the syntax and called out to the ticket functions is they are found.
3. Seth Cohn writes that phpGroupWare has a nice ticket tracking system.
It does. But phpGroupWare is *big* and one of the nicest things about
phpWiki is that it's still pretty simple and small. So here's what I
will do: I will create a small, one page ticket tracker that can be
distributed with phpWiki and that uses its own database table, but I
will also include glue so that phpWiki can optionally call out to the
PHPGW API instead, so that if you already happen to be using PHPGW,
phpWiki will register tickets in it. I've looked at the API, and this
shouldn't be too hard.
I'm not, however, going to do the work to "embed" phpWiki into a PHPGW
module. I have little interest in forcing the wiki into an even smaller
box on my browser window, surrounded by even more buttons and menus.
That's all for now. There are a lot of design decisions I haven't made yet.
I'll post a summary asking the groups opinion on a number of possibilities
in the next day or so.
Thanks,
Joe
http://orbis-tertius.net/joe/
|
|
From: Steve W. <sw...@pa...> - 2001-09-20 15:37:32
|
Hi Joe, thanks so much for outlining the whole idea! I have a question. Are you familiar with the "Category" and "Topic" conventions used on some Wikis? I think this might work for you. Let me outline it. A set of pages in a Wiki that are of a particular category will get a link placed at the bottom of the page: CategoryStarTrek When you go to CategoryStarTrek, the page will describe that category; by clicking on the page title you will see a list of all pages belonging to that Category. We use this on SourceForge: http://phpwiki.sourceforge.net/phpwiki/index.php?CategoryNextWiki For a ticket tracking system, you could just create a page for a problem (TicketCallBob, TicketFinanceApprove) and put CategoryTicket at the bottom (or better yet, CategoryTicketOpen, which could become CategoryTicketClosed when done). This is simplistic but places all the responsibility for organizing the data on the users. (Which is the Wiki Way, apparently). For a very small organization this might be suitable. Your approach makes the machine do much more of the work. ~swain On Wed, 19 Sep 2001, Joe Edelman wrote: > Hello everyone. > > "Ticket tracking" is like a to-do list for a group of people, or for many > groups of people. The phpwiki to-do list on sourceforge is a kind of > ticket tracker, as are bug trackers like the ones on sourceforge or > "Bugzilla". Help desks and call centers often use ticket tracking systems > to keep track of who they've helped and who else needs help. > > Generally a ticket corresponds to some task that needs doing or something > that needs attention-- a disk that needs to be backed up, or a customer who > needs to be called back, or a report that needs to be looked over and > signed by a manager. Tickets begin their lives "open", and when the task is > completed, they are "closed". Generally tickets contain some more state > than just that: they may know what kind of skills are necessary for their > completion, and they have a log of who has done work towards that ticket > and any comments they left. Anyone can log in to the ticket tracking > system and see, with one search, which "open" (not-yet-completed) tickets > (tasks) there are for people with their expertise. > > What I'm proposing is to add some new syntax to phpWiki pages that > integrate them into a ticket tracking system, so that if someone writes > text like "((finance:approve))" in their wiki page-- which means that they > want someone from the finance department to approve what they've written on > the page-- then a new ticket will be created which says just that. If ever > someone from finance edits the page and removes that text > ("((finance:approve))"), the ticket is closed. > > Other tickets might look like: > > ((sales:rewrite)) > ((CEO:approve)) > ((george:explain)) > > Or, if you're a small company or just a single person, you can use this > system for reminders for yourself about where in your phpwiki you would > like some additional information, or what you would like to rewrite, using > the shorter form: > > ((rewrite)) > ((check)) > ((fixme)) > > And then from one page, the ticket tracking page, you get links to every > wiki page that needs some work, and you can search or sort through these > wiki pages based on what kind of expertise they need (sales/CEO/george) or > what needs to be done (rewrite/approve/explain/check), or when they were > last worked on, or who entered the request, etc. > > > NOTES AS TO IMPLEMENTATION > > 1. It's clear that this feature wouldn't be of use to everyone, and the > phpwiki syntax-space is already getting kind of cluttered. It would be > nice, and fairly easy, to be able to turn syntax elements, including > ticket recognition ("(())"), on and off. So maybe a global ("define()") > in the index.php file would turn this whole system on and off, and it > would be off by default. > > 2. The logical time to create/open/close tickets is when the page > containing them (or from which they have been deleted) is first saved. > Right now the only parsing of page text on save is for converting tabs. > This is in savepage.php. I would have to add something, either there or > in WikiDB_PageRevision::createRevision(), that checks for occurrences of > the syntax and called out to the ticket functions is they are found. > > 3. Seth Cohn writes that phpGroupWare has a nice ticket tracking system. > It does. But phpGroupWare is *big* and one of the nicest things about > phpWiki is that it's still pretty simple and small. So here's what I > will do: I will create a small, one page ticket tracker that can be > distributed with phpWiki and that uses its own database table, but I > will also include glue so that phpWiki can optionally call out to the > PHPGW API instead, so that if you already happen to be using PHPGW, > phpWiki will register tickets in it. I've looked at the API, and this > shouldn't be too hard. > > I'm not, however, going to do the work to "embed" phpWiki into a PHPGW > module. I have little interest in forcing the wiki into an even smaller > box on my browser window, surrounded by even more buttons and menus. > > That's all for now. There are a lot of design decisions I haven't made yet. > I'll post a summary asking the groups opinion on a number of possibilities > in the next day or so. > > Thanks, > > Joe > http://orbis-tertius.net/joe/ > > _______________________________________________ > 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 http://pgp.document_type.org:11371/pks/lookup?op=get&search=0xF7323BAC |
|
From: <jo...@or...> - 2001-09-26 23:59:41
|
Steve Wainstead <sw...@pa...> wrote:
> I have a question. Are you familiar with the "Category" and "Topic"
> conventions used on some Wikis?
You're right. I can do it with Categories. I've spent the last few days
playing around and trying to think the Wiki Way. As a result, my to-do
list has changed considerably. Tops now is email notification (which would
have been an aspect of the ticket tracking system) and templates (which
will help keep things from getting too cluttered). Notification will have
to be triggerable not just from changes to a page, but also from new links
to that page. It would also be nice if there were a
<?plugin include OtherPage> and if that include plugin could bring in more
email notification requests from OtherPage. That way when someone makes a
new page which "NeedsFinanceAssessment", and NeedsFinanceAssessment
includes FinancePeople, it will all work out.
I have a few questions:
* Is there a proposal on board for templates as in the 1.3 task list? Is
there some other wiki which does it right I should go look at?
* Is there a reason to prefer [notify:JoeEdelman] for email alerts to
"* JoeEdelman - joe at orbis-tertius.net" as per TWiki?
* The /SubPages like on UseMod would be really easy to implement. Should
they be?
* Does anyone anywhere support "half-links" that don't show up in
BackLinks? It seems one problem with categories is that even pages
which just mention them or point to them as part of documentations are
categorized. I suppose this could be fixed with a plugin. It seems
like an un-wiki thing to do, but on the other hand, I don't want my
users to have to read through noise.
* Is there a good reason IsAProject is not a WikiWord?
* I'm also interested in making a general search tool plugin that shows
some meta data about every document it pulls up, or that pulls data
from the page (<?plugin searchTable "*Person" age?> might look for
lines beginning "Age: " and list what follows as a column in the
results). Any thoughts?
* I really want my searches to be able to tell me when a Category was
added to a page, even if that page has been modified several times
since then. Would it be possible to add a "ctime" to the link table?
Thanks,
Joe
|
|
From: Adam S. <ad...@pe...> - 2001-09-27 00:33:58
|
> * Is there a proposal on board for templates as in the 1.3 task list? Is > there some other wiki which does it right I should go look at? i believe that the current alpha one supports templates but i'm not sure. > * The /SubPages like on UseMod would be really easy to implement. Should > they be? i've never heard an arugment against subpages but i've never really heard a good argument *for* them either. > * Does anyone anywhere support "half-links" that don't show up in > BackLinks? It seems one problem with categories is that even pages > which just mention them or point to them as part of documentations are > categorized. I suppose this could be fixed with a plugin. It seems > like an un-wiki thing to do, but on the other hand, I don't want my > users to have to read through noise. the way i tried to do this in moinmoin was to list my categories list this: [CategoryDocumentation] and then i could search for that which shouldn't appear unless it's a category tag. it didn't work cause i couldn't make moinmoins search plugin excape the []'s and never got around to fixing it, but something similar to that should work fine. i still like the idea of categories / topics becoming metadata and there being drop down boxes to select them on the edit page (with the defautl being CategoryUnknown and TopicUnknown). > * Is there a good reason IsAProject is not a WikiWord? i don't think so. this annoys me as well, i think the main reason is to cut down on accidental wiki words. > * I'm also interested in making a general search tool plugin that shows > some meta data about every document it pulls up, or that pulls data > from the page (<?plugin searchTable "*Person" age?> might look for > lines beginning "Age: " and list what follows as a column in the > results). Any thoughts? this would work well with the metadata stuff. > * I really want my searches to be able to tell me when a Category was > added to a page, even if that page has been modified several times > since then. Would it be possible to add a "ctime" to the link table? i believe the alpha version has full diffs so you should be able to find that information that way. adam. |
|
From: Reini U. <ru...@x-...> - 2001-09-28 14:04:28
|
Joe Edelman schrieb: > * I really want my searches to be able to tell me when a Category was > added to a page, even if that page has been modified several times > since then. Would it be possible to add a "ctime" to the link table? I have this and more in my list.php which is used for all listed output. (search, backlinks, AllPages, ...) see the acadwiki sources. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ |
|
From: Steve W. <sw...@pa...> - 2001-10-01 23:45:24
|
On Wed, 26 Sep 2001, Joe Edelman wrote: > * Is there a proposal on board for templates as in the 1.3 task list? Is > there some other wiki which does it right I should go look at? Jeff Dairiki has rewritten the template engine, but I haven't looked at it yet. You might want to check out a nightly build and play with it. > > * Is there a reason to prefer [notify:JoeEdelman] for email alerts to > "* JoeEdelman - joe at orbis-tertius.net" as per TWiki? Well, I would argue for consistency in syntax... and to that end, we have two forms of syntax, with brackets and without, so I am in contradiction! ;-) I personally favor [notify:SteveWainstead] as syntax; I also like the idea of just adding your name to the page source to do this, because it is WikiLike, but there are many problems with it for other people, especially if it's a public wiki. For an intranet it's fine. > * The /SubPages like on UseMod would be really easy to implement. Should > they be? It's just "syntactic sugar," isn't it? That is, allowing slashes in page names? > * Does anyone anywhere support "half-links" that don't show up in > BackLinks? It seems one problem with categories is that even pages > which just mention them or point to them as part of documentations are > categorized. I suppose this could be fixed with a plugin. It seems > like an un-wiki thing to do, but on the other hand, I don't want my > users to have to read through noise. I think I see what you mean... you want to link to CategoryWiki without the page it appears in to show in a listing of all pages linking to CategoryWiki. Never even thought of it, but it seems like a pretty pathological case. > * Is there a good reason IsAProject is not a WikiWord? We've always stuck with the convention of true Wiki names for BumpyText, and if you want IsAProject to be a link use [IsAProject]. I'm wondering at the moment if we shouldn't just make the implementation of page names case insensitive. > * I'm also interested in making a general search tool plugin that shows > some meta data about every document it pulls up, or that pulls data > from the page (<?plugin searchTable "*Person" age?> might look for > lines beginning "Age: " and list what follows as a column in the > results). Any thoughts? Intruiging. I still have to look at the plugin architecture too! > * I really want my searches to be able to tell me when a Category was > added to a page, even if that page has been modified several times > since then. Would it be possible to add a "ctime" to the link table? > I think this won't work because every time a page is edited/saved, we first delete all frompage entries in the link table, parse the page for links, and reinsert them. It would be a nightmare to try to do this the other way (select all links from the table; parse the page; compare the two sets; delete the ones not in set 1, insert the ones only in set 2.) My idea has been to keep a log of all transactions in the database, or maybe a flat file, and you could trace edits that way. Otherwise you have to resort to looking at diffs. An internal log of edits would provide an audit trail. ~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 |
|
From: Adam S. <ad...@pe...> - 2001-10-02 00:02:48
|
> I personally favor [notify:SteveWainstead] as syntax; I also like the > idea of just adding your name to the page source to do this, because > it is WikiLike, but there are many problems with it for other people, > especially if it's a public wiki. For an intranet it's fine. now that i think about it, i also like [notify:AdamShand] better because it ties notification to a wiki user rather then to an arbitrary email address. long term users of a single wiki could have multiple email address in user and that could be a pain to track down. > It's just "syntactic sugar," isn't it? That is, allowing slashes in > page names? it could be a quite useful method for keeping wiki name space uncluttered. for example if multiple users can have their own calendar each day/month has a seperate wiki page it might be nice to have a sub-wiki for AdamShand's calendar so others don't have to see everytime i add an appointment in the main RecentChanges. however each sub-wiki can still have it's own TitleIndex, MostPopular, RecentChanges etc. > We've always stuck with the convention of true Wiki names for > BumpyText, and if you want IsAProject to be a link use [IsAProject]. > I'm wondering at the moment if we shouldn't just make the > implementation of page names case insensitive. i'm very in favor of case insenstive page names. i think case sensitive page names are unintuitve, especially when people insist on doing single word page links like EquipMent, exactly which letters are capitalized is kind of arbitrary, and i see no reason for them to link to different pages. adam. |
|
From: Steve W. <sw...@pa...> - 2001-10-02 19:37:57
|
On Mon, 1 Oct 2001, Adam Shand wrote:
> i'm very in favor of case insenstive page names. i think case sensitive
> page names are unintuitve, especially when people insist on doing single
> word page links like EquipMent, exactly which letters are capitalized is
> kind of arbitrary, and i see no reason for them to link to different
> pages.
Well, I meant in the implementation, we store the page name in lowercase.
The user would see EquipMent and [equipment] as links to the same page.
This would avoid the problem of EquipMent and [equipment] being different
pages... users could link them in whichever manner they see fit.
~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
|
|
From: Adam S. <ad...@pe...> - 2001-10-02 21:25:19
|
> Well, I meant in the implementation, we store the page name in > lowercase. The user would see EquipMent and [equipment] as links to > the same page. This would avoid the problem of EquipMent and > [equipment] being different pages... users could link them in > whichever manner they see fit. i *thought* that's what i said. regardless, what you said above? that's what i meant. :) adam. |
|
From: Malcolm R. <mal...@cs...> - 2001-10-03 02:09:28
|
On Tue, Oct 02, 2001 at 03:37:54PM -0400, Steve Wainstead wrote: > On Mon, 1 Oct 2001, Adam Shand wrote: > > > i'm very in favor of case insenstive page names. i think case sensitive > > page names are unintuitve, especially when people insist on doing single > > word page links like EquipMent, exactly which letters are capitalized is > > kind of arbitrary, and i see no reason for them to link to different > > pages. > > Well, I meant in the implementation, we store the page name in lowercase. > The user would see EquipMent and [equipment] as links to the same page. > This would avoid the problem of EquipMent and [equipment] being different > pages... users could link them in whichever manner they see fit. But the current 1.3 release splits WikiWords in the page titles, so that FrontPage is shown as "Front Page". If you are going to make EquipMent the same as [equipment] then should it also be the same as [Equip Ment]? Malcolm -- Malcolm Ryan - mal...@cs... - http://www.cse.unsw.edu.au/~malcolmr/ AI Dept, CSE, UNSW, Australia, Phone: +61 2 9385-6906 Fax: +61 2 9385-4936 "He causes his sun to rise on the evil and the good, and sends rain on the righteous and the unrighteous." - Matt 5:45 |
|
From: Reini U. <ru...@x-...> - 2001-10-03 08:39:13
|
Malcolm Ryan schrieb: > On Tue, Oct 02, 2001 at 03:37:54PM -0400, Steve Wainstead wrote: > > On Mon, 1 Oct 2001, Adam Shand wrote: > > > > > i'm very in favor of case insenstive page names. i think case sensitive > > > page names are unintuitve, especially when people insist on doing single > > > word page links like EquipMent, exactly which letters are capitalized is > > > kind of arbitrary, and i see no reason for them to link to different > > > pages. > > > > Well, I meant in the implementation, we store the page name in lowercase. > > The user would see EquipMent and [equipment] as links to the same page. > > This would avoid the problem of EquipMent and [equipment] being different > > pages... users could link them in whichever manner they see fit. > > But the current 1.3 release splits WikiWords in the page titles, so that > FrontPage is shown as "Front Page". If you are going to make EquipMent > the same as [equipment] then should it also be the same as [Equip Ment]? no, SplitPageInTitle is only for output in the header and the title, but not for anything else. (linking and other WikiWord magic) this is mainly for being search engine friendly. |
|
From: Malcolm R. <mal...@cs...> - 2001-10-04 05:04:42
|
On Wed, Oct 03, 2001 at 09:39:02AM +0100, Reini Urban wrote: > > > > But the current 1.3 release splits WikiWords in the page titles, so that > > FrontPage is shown as "Front Page". If you are going to make EquipMent > > the same as [equipment] then should it also be the same as [Equip Ment]? > > no, SplitPageInTitle is only for output in the header and the title, > but not for anything else. (linking and other WikiWord magic) > > this is mainly for being search engine friendly. Still, it is indicative of an underlying assumption that BumpyCaps is being using to indicate word boundaries, whereas ignoring case indicates the opposite. I think we need to get it clear in our minds which way want want to go. Consider this. If I add a link FooBarBaz to a wiki page, and then click the question mark I will get to edit a page, and the title of that page will be shown as "Foo Bar Baz". If I create a link to [foobarbaz] I will edit a page with title "foobarbaz". If we are to ignore capitalisation, both of these links will refer to the same page. What title will we give that page? Will it depend on the name it was given when it was created? Or the referring name? Or what? If there are to be any equivalences, I personally think that FooBarBaz should be equivalent to [foo bar baz], which is also three words, but not [foobarbaz] which is presumably one word. This would mean that "RunningTogether" would be distinguishable from "RunningToGetHer". Malcolm -- Malcolm Ryan - mal...@cs... - http://www.cse.unsw.edu.au/~malcolmr/ AI Dept, CSE, UNSW, Australia, Phone: +61 2 9385-6906 Fax: +61 2 9385-4936 "He causes his sun to rise on the evil and the good, and sends rain on the righteous and the unrighteous." - Matt 5:45 |
|
From: Adam S. <ad...@pe...> - 2001-10-04 16:42:22
|
> What title will we give that page? Will it depend on the name it was > given when it was created? that makes sense to me. if it was created with thte wrong name then it's a job for the editor of the wiki to fix just like if they created a page called RunnningTogether or any other of the mistakes which happen on an active wiki. > If there are to be any equivalences, I personally think that FooBarBaz > should be equivalent to [foo bar baz], which is also three words, but > not [foobarbaz] which is presumably one word. This would mean that > "RunningTogether" would be distinguishable from "RunningToGetHer". i think that this is a rare enough case that the number of times this will be a problem are outweighed by the convenience of people being able to link to the same page in slightly different ways. adam. |
|
From: Steve W. <sw...@pa...> - 2001-10-04 02:42:04
|
On Wed, 3 Oct 2001, Malcolm Ryan wrote:
> > Well, I meant in the implementation, we store the page name in lowercase.
> > The user would see EquipMent and [equipment] as links to the same page.
> > This would avoid the problem of EquipMent and [equipment] being different
> > pages... users could link them in whichever manner they see fit.
>
> But the current 1.3 release splits WikiWords in the page titles, so that
> FrontPage is shown as "Front Page". If you are going to make EquipMent
> the same as [equipment] then should it also be the same as [Equip Ment]?
[Equip Ment] would be a different page from [equipment] and EquipMent
because of the space. Making FrontPage into "Front Page" for display
purposes... well.. it seemed like a good idea at the time! :-)
~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
|
|
From: Adam S. <ad...@pe...> - 2001-10-04 05:00:56
|
> [Equip Ment] would be a different page from [equipment] and EquipMent > because of the space. Making FrontPage into "Front Page" for display > purposes... well.. it seemed like a good idea at the time! :-) I think it still is a good idea. most wiki words are MultipleWords and spliting them for the <title> and page title means search engines will index the pages properly. adam. |
|
From: Malcolm R. <mal...@cs...> - 2001-10-02 01:01:30
|
> > > * The /SubPages like on UseMod would be really easy to implement. Should > > they be? > > It's just "syntactic sugar," isn't it? That is, allowing slashes in page > names? It should also be possible to refer to a "local" subpage without naming the parent page. Eg: The "MalcolmRyan" page should be able to refer to "MalcolmRyan/AnnoyingHabits" as just "/AnnoyingHabits". [Personally, I would prefer '.' over '/']. Malcolm -- Malcolm Ryan - mal...@cs... - http://www.cse.unsw.edu.au/~malcolmr/ AI Dept, CSE, UNSW, Australia, Phone: +61 2 9385-6906 Fax: +61 2 9385-4936 "He causes his sun to rise on the evil and the good, and sends rain on the righteous and the unrighteous." - Matt 5:45 |
|
From: Adam S. <ad...@pe...> - 2001-10-02 01:52:29
|
> It should also be possible to refer to a "local" subpage without > naming the parent page. Eg: The "MalcolmRyan" page should be able to > refer to "MalcolmRyan/AnnoyingHabits" as just "/AnnoyingHabits". > > [Personally, I would prefer '.' over '/']. won't there need to be some way to differentiate between relative and absolute wiki paths? and can you have sub-sub-wiki's? and can the parents have a page as well as children or are the just the equivelent of directories? hrm, i'll shutup now and go play with usemod some more, i'm not sure i understand what sub-wiki's are actually for. adam. |
|
From: Jeff D. <da...@da...> - 2001-09-20 16:16:02
|
Just to ramble some more on the topic: The ticket idea is, I think, closer to the concept of WikiBadges than Categories. See http://c2.com/cgi/wiki?WikiBadge. Of course, on a traditional wiki, the implementation of WikiBadges is identical to that of Categories... In the latest PhpWiki, plugins can be used to generate in-line lists of Badges/Categories/Tickets. <?plugin BackLinks page=TicketApprove?> will generate a list of all pages which link to TicketApprove. You can use this to write a ticket index page which will list all ticketed pages (or certain subsets of them). (If you wanted, you could write a custom plugin to perform specialized smart ticket searches...) This gives you most of the functionality you want without any new code. I guess the main thing you don't get is any sort of per ticket history: ticket creator/author, creation time, closed tickets (though you could use something like TicketApproveClosed (or TicketApproved ?) to keep track of closed tickets)... A few more comments: > ((rewrite)) ((check)) ((fixme)) These correspond pretty much exactly to traditional WikiBadges.... > NOTES AS TO IMPLEMENTATION > > 2. The logical time to create/open/close tickets is when the page > containing them (or from which they have been deleted) is first saved. > Right now the only parsing of page text on save is for converting tabs. > This is in savepage.php. When a new page is saved, it gets parsed for WikiLinks. (This is necessary to properly update the link table which is used to find BackLinks, etc...) Currently this is done using ExtractWikiPageLinks(), but I think we should eliminate that function and just use the transform code to find the links --- it eliminate duplicated code, and eliminates the opportunities for inconsistency regarding what is a link and what's not.) The tab conversion stuff is obsolete, and should probably be deleted at this point. (I have already taken the checkbox off the editpage template, so without some hackage, the tab conversion code never gets invoked.) Jeff |
|
From: Adam S. <ad...@pe...> - 2001-09-20 17:13:40
|
thanks to the pointer to wiki badges, i hadn't foudn that yet on c2. > This gives you most of the functionality you want without any new > code. I guess the main thing you don't get is any sort of per ticket > history: ticket creator/author, creation time, closed tickets (though > you could use something like TicketApproveClosed (or TicketApproved ?) > to keep track of closed tickets)... this could almost be done with the same mechanism as a weblog. both want a mechanism for a tag to create sub pages. for the weblog you want the story blurb to create a story page. here you want the ticket to create the ticket history. my main complaint with this idea is that having all these pages automatically created seems like ti would clutter the wiki name space a lot so maybe isolating them in a sub-wiki (or something) would help? ---- side note, i got this from twiki today and the main new features in the big new release is plugins. i thought this was a perfect opportunity to steal some ideas :-) ALL-NEW PLUG-INS FEATURE Check out the initial set of Plugins, like SessionPlugin, SmiliesPlugin, SpreadSheetPlugin, TOCPlugin and more, at http://twiki.org/cgi-bin/view/Plugins/WebHome. The new Plugins web is already quite filled out, and building up steadily. Stay tuned. Developers, you're encouraged to write your own Plugins and contribute back to the TWiki community. Our goal is to establish Plugins as the foundation of a powerful, versatile collaboration platform. adam. |
|
From: Adam S. <ad...@pe...> - 2001-09-20 17:18:58
|
http://phpwiki.sourceforge.net/alpha/ Parse error: parse error in /home/groups/p/ph/phpwiki/htdocs/alpha/lib/WikiDB/backend/PearDB.php on line 4 Fatal error: Class wikidb_backend_mysql: Cannot inherit from undefined class wikidb_backend_peardb in /home/groups/p/ph/phpwiki/htdocs/alpha/lib/WikiDB/backend/mysql.php on line 7 |
|
From: Reini U. <ru...@x-...> - 2001-09-21 13:37:29
|
Jeff Dairiki schrieb: > Currently this is done using ExtractWikiPageLinks(), but I think we > should eliminate that function and just use the transform code to find > the links --- it eliminate duplicated code, and eliminates the > opportunities for inconsistency regarding what is a link and what's > not.) Yes. ExtractWikiPageLinks() falsely stores external Interwiki links (the part before the ':' and the part after the ':') as pages. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ |
×
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