From: Brian A. <br...@ta...> - 2001-02-22 18:10:07
|
So this is what is floating around in my head for changes to topics. These are the needs I see: * Stories need to be able to belong to multiple topics * We still need a single topic for display * This still has to be fast * We need section topics * The topic list is to long in admin for large sites * Keyword support for RSS and such would be nice To pull this off, the following changes are made: * Stories get a sequence (need this for other stuff too..) * Topics get a sequence and an optional section * Table is created that puts a story sequence with the topic sequence. We can either assign all topics to sections, or topics without sections are global. Stories are still displayed with the topic used in the story table. We can use the use the multiple topics for places where we need keyword support today. This about a days worth of work and this would be for 2.2 (which should add the support newsforge needs). -Brian |
From: Eric D. <eri...@ja...> - 2001-02-22 18:19:01
|
Multiple topics would be good. How about a story can have one main topic, but have many related subtopics? That would make more sense. Brian Aker wrote: > So this is what is floating around in my head for > changes to topics. These are the needs I see: > * Stories need to be able to belong to multiple > topics > * We still need a single topic for display > * This still has to be fast > * We need section topics > * The topic list is to long in admin for large > sites > * Keyword support for RSS and such would be nice > > To pull this off, the following changes are made: > * Stories get a sequence (need this for other stuff too..) > * Topics get a sequence and an optional section > * Table is created that puts a story sequence with the > topic sequence. > Yeah, but aren't the sid's or whatever is used to identify them already unique? Then you really don't need to create a sequence do you? The table could just have the unique fields from the topics table and the stories table. > > We can either assign all topics to sections, or > topics without sections are global. > > Stories are still displayed with the topic used in > the story table. We can use the use the multiple topics > for places where we need keyword support today. > > This about a days worth of work and this would be > for 2.2 (which should add the support newsforge needs). > > -Brian |
From: Brian A. <br...@ta...> - 2001-02-22 18:28:32
|
Eric Dannewitz wrote: > Multiple topics would be good. How about a story can have one main > topic, but have many related subtopics? That would make more sense. That is what this would do for you. > Yeah, but aren't the sid's or whatever is used to identify them already > unique? Then you really don't need to create a sequence do you? The > table could just have the unique fields from the topics table and the > stories table. I knew someone was going to ask this :) This is the issue. A select on an int is very fast and the table doesn't take up much space. Now, think about this over a long period. Say you attach 5 additional topics to a story so that you get enough keywords for what you want. Now say you run 50 stories a day (newsforge style). Start doing the math for over a year, for over 5 years. This could easily become a huge table. To make sure this will work over time we would want it to be as fast as possible. getDescriptions() with a cachable hash reference to topic sequence to name keeps this from being either a join, or a large hit to the DB. The nice things about sid's over sequences is that for display purpose (or I should say fetch purpose) a user can not see stories before they are being meant to be seen. Aka right now you need to be pretty bored to do this with article.pl (even though this is enforceable with basic business logic in article.pl). -Brian |
From: Eric D. <eri...@ja...> - 2001-02-22 18:36:16
|
Well, you could KEEP the sid and have a sequence that links stories and topics together. Then you'd have the nice SID thing alive still, and then deal with the space issue. Or you could maybe have two tables that assign a sequence to a SID (story and topic) and then those sequences are added to another table that links multiple stories and topics together..... Just a thought Brian Aker wrote: > Eric Dannewitz wrote: > > Multiple topics would be good. How about a story can have one main > > topic, but have many related subtopics? That would make more sense. > That is what this would do for you. > > > Yeah, but aren't the sid's or whatever is used to identify them already > > unique? Then you really don't need to create a sequence do you? The > > table could just have the unique fields from the topics table and the > > stories table. > I knew someone was going to ask this :) > > This is the issue. A select on an int is very fast and the table > doesn't take up much space. Now, think about this over a long > period. Say you attach 5 additional topics to a story so that > you get enough keywords for what you want. > Now say you run 50 stories a day (newsforge style). Start > doing the math for over a year, for over 5 years. > > This could easily become a huge table. To make sure this will > work over time we would want it to be as fast as possible. > > getDescriptions() with a cachable hash reference to > topic sequence to name keeps this from being either > a join, or a large hit to the DB. > > The nice things about sid's over sequences is that for > display purpose (or I should say fetch purpose) a user > can not see stories before they are being meant to be > seen. Aka right now you need to be pretty bored to > do this with article.pl (even though this is > enforceable with basic business logic in article.pl). > > -Brian > > _______________________________________________ > Slashcode-development mailing list > Sla...@li... > http://lists.sourceforge.net/lists/listinfo/slashcode-development -- Back up my hard disk? I can't find the reverse switch! Eric Dannewitz - Adventurer, saxophonist, good-timer (crook? quite possibly), clarinetist, manic self-publicist, part-time flautist(flutist?), macintosher, and often thought to be completely out to lunch. http://www.jazz-sax.com |
From: Brian A. <br...@ta...> - 2001-02-22 18:43:14
|
Eric Dannewitz wrote: > Well, you could KEEP the sid and have a sequence that links stories and > topics together. Then you'd have the nice SID thing alive still, and then > deal with the space issue. SID will still be around. There will just be an additional sequence. Think of it as a candidate key. > Or you could maybe have two tables that assign a sequence to a SID (story and > topic) and then those sequences are added to another table that links > multiple stories and topics together..... The only reason to do header tables like that (and the next version of comments is like this) is if you need to worry about relating multiple items to topics (classic many to many relationship). This shows up in comments, where we have a header table and use sequences from it to create parents in comments (we need this so that stories, polls, journals, ladybug... other unwritten bits of code) can use the comments table. -Brian |
From: Rob 'C. M. <ma...@sl...> - 2001-02-22 19:23:28
|
> * This still has to be fast This is the reason I never implemented it. I decided that the performance hit of having to do an extra lookup was just not worth it. I can be done reasonably fast (like storing the first one in the stories table to save the lookup) but it just was never worth the work (for slashdot anyway. For newsforge or whatever, that may be different). Sectionally specific topics however please me greatly. The second issue is that of user interface. One long list is a pain in the ass, but when you start needing to select multiple topics, it gets even harder. Probably its not that difficult: if you and have the topic defined, and additional dropdown list can appear and a topic can be selected. This is a little clunky, but relatively unobtrusive since the bulk of stories will only have 1 or 2 topics anyway. -- Rob "CmdrTaco" Malda | ma...@sl... | http://CmdrTaco.net 'Sometimes when I pick up the guitar, I'm stunned at how well I play. But I'm equally good at lots of other things.' -- Townshend |
From: Nathan V. <na...@th...> - 2001-02-22 19:44:58
|
On 22 Feb 2001, Rob 'CmdrTaco' Malda wrote: > The second issue is that of user interface. One long list is a pain > in the ass, but when you start needing to select multiple topics, it > gets even harder. Probably its not that difficult: if you and have the > topic defined, and additional dropdown list can appear and a topic can > be selected. This is a little clunky, but relatively unobtrusive since the > bulk of stories will only have 1 or 2 topics anyway. You can have a selection menu that allows multiple selections... it would probably make sense to have a single list for the primary topic and a multiple selection menu for the secondary topics. To do section-based topics it would work best, I think, to have javascript dynamically populate the topic selection menus based on which section is selected. A lower-tech solution would be to have all the section:topic pairs in the topic selection menus. More javascript in the admin area would be great in general (especially in the variable and template areas; why not preload all the variables in javascript so they display instantly instead of submitting the form). -n |
From: CertIndex.com W. <web...@ce...> - 2001-02-22 21:17:14
|
Not exactly sure how the conversation I started on section hierarchy got off into topics, so I'll bring 'er on home. What are your guys' thoughts on making sections hierarchial? Personally this is something I would *really* like to see, it's almost a show stopper. So if there are no plans to make this, and you guys would like to see it, give some recommendations about the best way to go about architecting this and we'll make the feature patch ourselves. (Would you integrate it into the main base btw? Would be nice to have it in there.) regards ----- Original Message ----- From: "Nathan Vonnahme" <na...@th...> To: <sla...@li...> Sent: Thursday, February 22, 2001 11:39 AM Subject: Re: [Slashcode-development] Re: Topics > > On 22 Feb 2001, Rob 'CmdrTaco' Malda wrote: > > > The second issue is that of user interface. One long list is a pain > > in the ass, but when you start needing to select multiple topics, it > > gets even harder. Probably its not that difficult: if you and have the > > topic defined, and additional dropdown list can appear and a topic can > > be selected. This is a little clunky, but relatively unobtrusive since the > > bulk of stories will only have 1 or 2 topics anyway. > > You can have a selection menu that allows multiple selections... it would > probably make sense to have a single list for the primary topic and a > multiple selection menu for the secondary topics. > > To do section-based topics it would work best, I think, to have javascript > dynamically populate the topic selection menus based on which section is > selected. A lower-tech solution would be to have all the section:topic > pairs in the topic selection menus. > > More javascript in the admin area would be great in general (especially in > the variable and template areas; why not preload all the variables in > javascript so they display instantly instead of submitting the form). > > -n > > > _______________________________________________ > Slashcode-development mailing list > Sla...@li... > http://lists.sourceforge.net/lists/listinfo/slashcode-development > |
From: Chris N. <pu...@po...> - 2001-02-23 14:05:55
|
At 10:39 -0900 2001.02.22, Nathan Vonnahme wrote: >On 22 Feb 2001, Rob 'CmdrTaco' Malda wrote: > >> The second issue is that of user interface. One long list is a pain >> in the ass, but when you start needing to select multiple topics, it >> gets even harder. Probably its not that difficult: if you and have the >> topic defined, and additional dropdown list can appear and a topic can >> be selected. This is a little clunky, but relatively unobtrusive since the >> bulk of stories will only have 1 or 2 topics anyway. > >You can have a selection menu that allows multiple selections... it would >probably make sense to have a single list for the primary topic and a >multiple selection menu for the secondary topics. > >To do section-based topics it would work best, I think, to have javascript >dynamically populate the topic selection menus based on which section is >selected. A lower-tech solution would be to have all the section:topic >pairs in the topic selection menus. > >More javascript in the admin area would be great in general (especially in >the variable and template areas; why not preload all the variables in >javascript so they display instantly instead of submitting the form). I just want to add what is obvious to some but perhaps not to everyone: I don't think any of the Slash team is generally opposed to JavaScript used in this way; however, it must work without the JavaScript, too. It's no big deal to get it to work like that, I'm just clarifying the point in case someone cares. :) -- Chris Nandor pu...@po... http://pudge.net/ Open Source Development Network pu...@os... http://osdn.com/ |
From: Brian A. <br...@ta...> - 2001-02-23 17:52:31
|
Chris Nandor wrote: > I just want to add what is obvious to some but perhaps not to everyone: I > don't think any of the Slash team is generally opposed to JavaScript used > in this way; however, it must work without the JavaScript, too. It's no > big deal to get it to work like that, I'm just clarifying the point in case > someone cares. :) The other caveat is that it must work with the majority of browsers and especially Linux/netscape 4.7. And I do think it would be a good thing in a few cases. -Brian |
From: Nathan V. <na...@th...> - 2001-02-23 18:28:03
|
The form parts of javascript work with Netscape and IE 3+ on all platforms. I avoid javascript for most public stuff but for things like the admin interface I think it's okay to get a little more daring. It is a good idea to keep it functional without javascript, though, just in case you want to configure slash or post a story from your cell phone :) On Fri, 23 Feb 2001, Brian Aker wrote: > Chris Nandor wrote: > > I just want to add what is obvious to some but perhaps not to everyone: I > > don't think any of the Slash team is generally opposed to JavaScript used > > in this way; however, it must work without the JavaScript, too. It's no > > big deal to get it to work like that, I'm just clarifying the point in case > > someone cares. :) > The other caveat is that it must work with the majority of browsers > and especially Linux/netscape 4.7. And I do think it would be a good > thing in a few cases. > -Brian > > _______________________________________________ > Slashcode-development mailing list > Sla...@li... > http://lists.sourceforge.net/lists/listinfo/slashcode-development > |
From: Chris N. <pu...@po...> - 2001-02-23 19:30:09
|
At 09:22 -0900 2001.02.23, Nathan Vonnahme wrote: >The form parts of javascript work with Netscape and IE 3+ on all >platforms. I avoid javascript for most public stuff but for things like >the admin interface I think it's okay to get a little more daring. It is >a good idea to keep it functional without javascript, though, just in case >you want to configure slash or post a story from your cell phone :) Yes, absolutely. Or use a browser without JavaScript available or active. This is a Must. -- Chris Nandor pu...@po... http://pudge.net/ Open Source Development Network pu...@os... http://osdn.com/ |