From: Blake D. <bla...@ch...> - 2001-03-24 04:07:04
|
I just wanted to mention that in my attempts to change the look of threads for comments, I ran into a problem. Currently, the slash code adds an indent constant to the beginning of every "linkComment" (which is a link to the threaded comment). I think this method is very non-templatized. In order to put threaded comments into table rows, I had to basically butcher the code in Slash::displayThread and some other functions. Is there something I'm missing? Or is this an oversight with the template development? Thanks, Blake Day |
From: Blake D. <bl...@ar...> - 2001-04-06 04:58:10
|
Hi, I need to know what determines the length of time a story remains in the table "newstories". Is it a variable in the "vars" table? Is it different for each section? Does slashd move the stories out of "newstories" and into "stories"? Why does "newstories" even exist? Thanks much, Blake Day CTO, SpunkNetwork bl...@sp... home: (770) 338-1589 mobile: (678) 485-0519 |
From: shane <sh...@lo...> - 2001-04-06 13:33:36
|
At 01:04 AM 4/6/2001 -0400, you wrote: >Hi, > >I need to know what determines the length of time a story remains in the >table "newstories". Is it a variable in the "vars" table? Is it different >for each section? Does slashd move the stories out of "newstories" and into >"stories"? Take a look at slashd. I think it does the 'moving' from newstories to stories. >Why does "newstories" even exist? I think it's to speed up the sql. If you've 2000 stories in the 'stories' table, and you've got the 10 latest stories in the 'newstories' table, then the db (for the majoriy of the hits to the system) only has to waid through those few in the newstories table, rather then polling the huge stories table. |
From: Alessio B. <al...@al...> - 2001-04-06 13:49:06
|
shane wrote: > Take a look at slashd. I think it does the 'moving' from > newstories to stories. The other way round, from stories to newstories when stories.writestatus = 1. -- Alessio F. Bragadini al...@al... APL Financial Services http://village.albourne.com Nicosia, Cyprus phone: +357-2-755750 "It is more complicated than you think" -- The Eighth Networking Truth from RFC 1925 |
From: Brian A. <br...@ta...> - 2001-04-06 16:36:55
|
shane wrote: > >Why does "newstories" even exist? > I think it's to speed up the sql. If you've 2000 stories in the > 'stories' table, and you've got the 10 latest stories in the > 'newstories' table, then the db (for the majoriy of the hits > to the system) only has to waid through those few in the > newstories table, rather then polling the huge stories table. That is exactly why it exists. We have a better solution for 2.2 though for this. There will be three tables where there was one. There will be a meta table holding all non blob information for the site and a blob table with the sid referenced to a blob. Finally there will be a heap table that is a copy of the meta table. Selects will be made against table. This is incredibly fast and uses very little memory. Neat aye? -Brian -- _______________________________________________________ Brian Aker, br...@ta... Slashdot Senior Developer Seattle, Washington http://tangent.org/~brian/ http://slashdot.org/ _______________________________________________________ You can't grep a dead tree. |
From: Blake D. <bl...@ar...> - 2001-04-08 00:46:55
|
For the newest solution, how are you keeping both tables replicated? Will slashd do this? Thanks Blake Day CTO, SpunkNetwork bl...@sp... <mailto:bl...@sp...> home: (770) 338-1589 mobile: (678) 485-0519 -----Original Message----- From: sla...@li... [mailto:sla...@li...]On Behalf Of Brian Aker Sent: Friday, April 06, 2001 1:32 AM To: sla...@li... Subject: Re: [Slashcode-development] (no subject) shane wrote: > >Why does "newstories" even exist? > I think it's to speed up the sql. If you've 2000 stories in the > 'stories' table, and you've got the 10 latest stories in the > 'newstories' table, then the db (for the majoriy of the hits > to the system) only has to waid through those few in the > newstories table, rather then polling the huge stories table. That is exactly why it exists. We have a better solution for 2.2 though for this. There will be three tables where there was one. There will be a meta table holding all non blob information for the site and a blob table with the sid referenced to a blob. Finally there will be a heap table that is a copy of the meta table. Selects will be made against table. This is incredibly fast and uses very little memory. Neat aye? -Brian -- _______________________________________________________ Brian Aker, br...@ta... Slashdot Senior Developer Seattle, Washington http://tangent.org/~brian/ http://slashdot.org/ _______________________________________________________ You can't grep a dead tree. _______________________________________________ Slashcode-development mailing list Sla...@li... http://lists.sourceforge.net/lists/listinfo/slashcode-development |
From: Blake D. <bla...@ch...> - 2001-05-06 18:49:11
|
Anybody have any idea how i could add some html to the end of every "set of threaded replies"? After all those one-line threads for a certain comment, i need to close a table, but since displayThread is recursive, im not quite sure where to put that. Blake Day home: (770) 338-1589 mobile: (678) 485-0519 |
From: John B. <ds...@zo...> - 2001-06-08 03:46:41
|
Hi all, I'm trying to coax slash into displaying story-related information that isn't stored in the stories table. I was hoping to be able to just change the query in getStory(), however, it seems that it's going through the query result cache, and I can't tell if there's any way that I can join the story table to something else without bypassing the story cache altogether. What I'm trying to do right now is display a submission comments field that we've added to the submissions table, but I will likely need to pull from other sources with more complex relationships than a simple "left join submissions using(subid)". Is this possible at all? If not, is there a way to do a query directly from the template system? It seems like that's possible, but there doesn't seem to be much in the way of documentation for the template syntax. Thanks, -John -- John Bafford ds...@zo... http://www.dshadow.com/ |
From: Nathan V. <na...@th...> - 2001-06-08 17:42:54
|
On Thu, 7 Jun 2001, John Bafford wrote: > Hi all, > > I'm trying to coax slash into displaying story-related information > that isn't stored in the stories table. I was hoping to be able to > Is this possible at all? If not, is there a way to do a query > directly from the template system? It seems like that's possible, but > there doesn't seem to be much in the way of documentation for the > template syntax. You might look into the patch on the sourceforge bugs page to fix extracols support, but it won't exactly do what you want. It might be useful to study, though, since it is doing something similar. There are very good docs for the template markup at http://www.template-toolkit.org/docs/default/index.html You can access any of the Slash::DB methods within the templates with the Slash.db object after you've USEd Slash. (a real working example): [% USE Slash; # args are: columns, tables, where, other sth = Slash.db.sqlSelectMany( 'guide.sid, title, section', 'stories, guide', "stories.sid = guide.sid AND guide_parent_sid = '$story.sid'", 'ORDER BY title' ); story.extras.child_links = []; WHILE (c = sth.fetchrow_hashref); story.extras.child_links.push( Slash.linkStory({ link => c.title, sid => c.sid, section => c.section, }) ); END; # end while c IF story.extras.child_links; SET story.extras.child_links_lis = story.extras.child_links.join("<li>"); SET story.relatedtext = "$story.relatedtext <li> $story.extras.child_links_lis"; END; %] Slash::DB has a mockery of documentation in it, you usually have to read the code in Slash::DB::MySQL to figure out what the methods do and how to call them. I would guess that there is a performance penalty for doing this sort of thing in the templates, but there may not be, since the templates are cached and compiled just like the perl. But it is certainly more awkward using the Template directives, I think (witness the goofy string concatenation in the last three lines of the example). The server error logs provide useful debugging output if you make syntax errors in your templates. Good luck, nathan -- Nathan Vonnahme na...@th... senior web developer third sector technologies http://enteuxis.org/nathan http://thethirdsector.com |
From: Brian A. <br...@ta...> - 2001-06-08 17:51:12
|
Nathan Vonnahme wrote: > You might look into the patch on the sourceforge bugs page to fix > extracols support, but it won't exactly do what you want. It might be > useful to study, though, since it is doing something similar. I wouldn't use extracols, it has been dropped in the development schema. I would make use of getStory() setStory() and let data fall into the param table. > [% > USE Slash; > > # args are: columns, tables, where, other > sth = Slash.db.sqlSelectMany( > 'guide.sid, title, section', > 'stories, guide', > "stories.sid = guide.sid AND guide_parent_sid = '$story.sid'", > 'ORDER BY title' > ); I have been wondering when it would cross someone's mind that they can do that. > Slash::DB has a mockery of documentation in it, you usually have to read > the code in Slash::DB::MySQL to figure out what the methods do and how to > call them. Yeah, I stubbed it out and never did more then a few pieces of it. Time :) > I would guess that there is a performance penalty for doing this sort of > thing in the templates, but there may not be, since the templates are Probably isn't, but there is another issue to not do it. If you ever want to move to another database you won't have the ability to use the abstraction layer to save you porting time. Plus if directly hit the DB, you may find that in the future your templates will break because we made some schema change. -Brian |
From: Nathan V. <na...@th...> - 2001-06-08 18:40:32
|
On Fri, 8 Jun 2001, Brian Aker wrote: > I wouldn't use extracols, it has been dropped in the development schema. > I would make use of getStory() setStory() and let data fall into the > param table. Where should I do that? And how are you going to make the slashdot books section work without the extracols stuff? It is, in theory at least, a good way to provide extensions to certain sections. What I'd really like to see is a Story module that I could subclass, making use of inheritance as much as possible. The Story module could know how to print its own edit form, short/full display, etc. That would be much cooler than the templates. > > I would guess that there is a performance penalty for doing this sort of > > thing in the templates, but there may not be, since the templates are > Probably isn't, but there is another issue to not do it. If you > ever want to move to another database you won't have the ability to > use the abstraction layer to save you porting time. Plus if directly > hit the DB, you may find that in the future your templates > will break because we made some schema change. Well, it does use the DB method sqlSelectMany... which is abstracted in theory. I can't see any way of getting around referring to certain fields and tables in the database, though. I was trying to do this in the templates to avoid having trouble managing changes to the perl modules or .pl files. Which brings up a big question that's been irritating me: how do the templates really help the customization situation? With slash 2 we can now make most of our changes in the templates, so the perl code is easy to upgrade because we haven't needed to mess with it. But the templates go through significant revisions too so we have to manage a similar amount of change to upgrade. It's actually more of a pain because I find writing perlish things in the templates awkward, and it would be easier to just edit the perl code and manage changes there anyway. I know that you have lots of other things on your mind than another big architecture shift, but what would be more useful and extensible, I think, is to use inheritance more. Somehow my theme or plugin should be able to inherit from the standard one -- that way changes to the distribution could often be inherited by custom themes and plugins. Like... I want a book reviews section and each story needs to have extra fields like ISBN nad stuff. So I subclass the Slash::Story object using this sort of thing: package Slash::Story::BookReview; push @ISA, 'Slash::Story'; sub display { # copy Slash::Story's display sub here and modify it } sub display_edit_form { $self->SUPER::display_edit_form; # print extra field edit stuff here... second form? } sub save { $self->SUPER::save(); # save extra fields here } sub display_submit_form { # same thing, etc. } But most of the story's subs would stay the same so we'd just inherit them automatically and not have to redefine them. -n |
From: Nathan V. <na...@th...> - 2001-06-13 18:47:46
|
I didn't get a response back about this, does anyone have any thoughts? I fixed extracols support in slash 2.0.0 in order to get something working for a client, and I'd like to know what the future plans are if extracols has been dropped so I can let him know what will be involved. The subclassing thoughts are beside that main point. Cheers, nathan On Fri, 8 Jun 2001, Nathan Vonnahme wrote: > > On Fri, 8 Jun 2001, Brian Aker wrote: > > > I wouldn't use extracols, it has been dropped in the development schema. > > I would make use of getStory() setStory() and let data fall into the > > param table. > > Where should I do that? And how are you going to make the slashdot books > section work without the extracols stuff? It is, in theory at least, a > good way to provide extensions to certain sections. > > What I'd really like to see is a Story module that I could subclass, > making use of inheritance as much as possible. The Story module could > know how to print its own edit form, short/full display, etc. That would > be much cooler than the templates. > > > > I would guess that there is a performance penalty for doing this sort of > > > thing in the templates, but there may not be, since the templates are > > Probably isn't, but there is another issue to not do it. If you > > ever want to move to another database you won't have the ability to > > use the abstraction layer to save you porting time. Plus if directly > > hit the DB, you may find that in the future your templates > > will break because we made some schema change. > > Well, it does use the DB method sqlSelectMany... which is abstracted in > theory. I can't see any way of getting around referring to certain fields > and tables in the database, though. I was trying to do this in the > templates to avoid having trouble managing changes to the perl modules or > .pl files. > > Which brings up a big question that's been irritating me: how do the > templates really help the customization situation? With slash 2 we can > now make most of our changes in the templates, so the perl code is easy to > upgrade because we haven't needed to mess with it. But the templates go > through significant revisions too so we have to manage a similar amount of > change to upgrade. It's actually more of a pain because I find writing > perlish things in the templates awkward, and it would be easier to just > edit the perl code and manage changes there anyway. > > I know that you have lots of other things on your mind than another big > architecture shift, but what would be more useful and extensible, I think, > is to use inheritance more. Somehow my theme or plugin should be able to > inherit from the standard one -- that way changes to the distribution > could often be inherited by custom themes and plugins. > > Like... I want a book reviews section and each story needs to have extra > fields like ISBN nad stuff. So I subclass the Slash::Story > object using this sort of thing: > > package Slash::Story::BookReview; > push @ISA, 'Slash::Story'; > sub display { > # copy Slash::Story's display sub here and modify it > } > sub display_edit_form { > $self->SUPER::display_edit_form; > # print extra field edit stuff here... second form? > } > sub save { > $self->SUPER::save(); > # save extra fields here > } > sub display_submit_form { > # same thing, etc. > } > > But most of the story's subs would stay the same so we'd just inherit them > automatically and not have to redefine them. > > -n > > > > _______________________________________________ > Slashcode-development mailing list > Sla...@li... > http://lists.sourceforge.net/lists/listinfo/slashcode-development > |
From: Brian A. <br...@ta...> - 2001-06-13 18:56:18
|
Nathan Vonnahme wrote: > > I didn't get a response back about this, does anyone have any thoughts? > > I fixed extracols support in slash 2.0.0 in order to get something working > for a client, and I'd like to know what the future plans are if extracols > has been dropped so I can let him know what will be involved. I added it back. It doesn't hurt us to have it there (since we just do a single lookup based on key on the column). It is now in the story_text table though (setUser() handles getting the right tables, and putting them together). So expect it to stick around. -Brian |
From: Nathan V. <na...@th...> - 2001-06-13 20:36:58
|
Cool, thanks a lot! Was my patch in the bugs section on sourceforge useful? It's the first time I've submitted one so I'm curious if I've done it right. What is the story_text table and how does it work? Should I just look at the schema and code in fry? -n On Wed, 13 Jun 2001, Brian Aker wrote: > Nathan Vonnahme wrote: > > > > I didn't get a response back about this, does anyone have any thoughts? > > > > I fixed extracols support in slash 2.0.0 in order to get something working > > for a client, and I'd like to know what the future plans are if extracols > > has been dropped so I can let him know what will be involved. > I added it back. It doesn't hurt us to have it there (since we just > do a single lookup based on key on the column). It is now > in the story_text table though (setUser() handles getting the right > tables, and putting them together). > > So expect it to stick around. > -Brian > > _______________________________________________ > Slashcode-development mailing list > Sla...@li... > http://lists.sourceforge.net/lists/listinfo/slashcode-development > |
From: <CAL...@ao...> - 2002-09-08 03:17:27
|
please remove us from your e-mail list. |
From: shane <sh...@lo...> - 2001-03-25 16:01:06
|
At 11:12 PM 3/23/2001 -0500, Blake Day wrote: >I just wanted to mention that in my attempts to change the look of threads >for comments, I ran into a problem. Currently, the slash code adds an >indent constant to the beginning of every "linkComment" (which is a link >to the threaded comment). I think this method is very >non-templatized. In order to put threaded comments into table rows, I had >to basically butcher the code in Slash::displayThread and some other >functions. Is there something I'm missing? Or is this an oversight with >the template development? > >Thanks, >Blake Day > Blake, What you could do for this - instead of hacking at slash, make your own module, copy Slash::displayThread and put that into your module. edit to suite. save, compile. (possibly install as a plugin). I ran into what you're talking about when I originally did those ubbish templates. I realized it'd take way too much time to do and moved on from it. Have you looked at the new comment system they're doing for slash 2.2? You might want to look at that, and start your 'ubb' look with that instead of the current comment system. You could key your ubblook to a story param. I say this because, from what I understand, bender 2.2 will have that new comment system fully functional. And since they're doing it because Slashdot needs it (again, that's my understanding) I'd guess it'll get coded quickly so they can move /. to bender asap. Shane |
From: Ask S. G. <cl...@sl...> - 2001-03-27 02:14:02
|
FYI, this might not be very intuitive, but the indent data is NOT hardcoded into Slash...it just looks that way. For those who don't know, there is a routine in Slash called getData() which one can use to get little "snippets" of HTML or other text. This data is obtained from one large template called: data;misc;default Note: like all other templates, you can override the default template for individual sections by creating and editing: data;misc;<section-name> It's recommended that you copy the default template to your new template and edit what you need, then load the new template into the database using template-tool. Now in terms of the threaded display, you will want to investigate the following data "snippets": indentbegin [Slashcode default: "<UL>"] indentend [Slashcode default: "</UL>"] You can therefore change these to taste with respect to how you want your indenting to look like without changing a single line of Slash. (Well, you SHOULD be able to do this, if the reality is different from the intended design, please do let us know). Be aware that you should also be able to edit these templates from the template editor in admin.pl [remember to restart your httpds if necessary]. - Cliff On Sun, 25 Mar 2001 11:07:00 -0500, shane said: > At 11:12 PM 3/23/2001 -0500, Blake Day wrote: > >I just wanted to mention that in my attempts to change the look of threads > >for comments, I ran into a problem. Currently, the slash code adds an > >indent constant to the beginning of every "linkComment" (which is a link > >to the threaded comment). I think this method is very > >non-templatized. In order to put threaded comments into table rows, I had > >to basically butcher the code in Slash::displayThread and some other > >functions. Is there something I'm missing? Or is this an oversight with > >the template development? > > > >Thanks, > >Blake Day > > > > Blake, > > What you could do for this - > > instead of hacking at slash, make your own module, > copy Slash::displayThread and put that into your module. > edit to suite. save, compile. (possibly install as a plugin). > > I ran into what you're talking about when I originally did those > ubbish templates. I realized it'd take way too much time to do > and moved on from it. > > Have you looked at the new comment system they're doing for slash 2.2? > You might want to look at that, and start your 'ubb' look with that > instead of the current comment system. You could key your ubblook > to a story param. I say this because, from what > I understand, bender 2.2 will have that new comment system fully > functional. And since they're doing it because Slashdot needs it > (again, that's my understanding) I'd guess it'll get coded quickly > so they can move /. to bender asap. > > Shane > > > _______________________________________________ > Slashcode-development mailing list > Sla...@li... > http://lists.sourceforge.net/lists/listinfo/slashcode-development > > > |
From: Blake D. <bl...@ar...> - 2001-03-27 02:23:29
|
Cliff, I needed to do something liek the following: Replies: Comment 1 username1 March 25, 2001 Re: Comment 1 username2 March 26, 2001 Comment 2 username3 March 25, 2001 I could not do that with the simple indent variable. I needed them in table rows. I personally think the display would be more extensible that way. Am I missing something? Btw, I have already gotten it tow ork by modifying code. I just wanted to let you guys know. Thanks, Blake Day -----Original Message----- From: sla...@li... [mailto:sla...@li...]On Behalf Of Ask Slashdot Guy Sent: Monday, March 26, 2001 9:15 PM To: sla...@li... Subject: Re: [Slashcode-development] change the look of threads forcomments FYI, this might not be very intuitive, but the indent data is NOT hardcoded into Slash...it just looks that way. For those who don't know, there is a routine in Slash called getData() which one can use to get little "snippets" of HTML or other text. This data is obtained from one large template called: data;misc;default Note: like all other templates, you can override the default template for individual sections by creating and editing: data;misc;<section-name> It's recommended that you copy the default template to your new template and edit what you need, then load the new template into the database using template-tool. Now in terms of the threaded display, you will want to investigate the following data "snippets": indentbegin [Slashcode default: "<UL>"] indentend [Slashcode default: "</UL>"] You can therefore change these to taste with respect to how you want your indenting to look like without changing a single line of Slash. (Well, you SHOULD be able to do this, if the reality is different from the intended design, please do let us know). Be aware that you should also be able to edit these templates from the template editor in admin.pl [remember to restart your httpds if necessary]. - Cliff On Sun, 25 Mar 2001 11:07:00 -0500, shane said: > At 11:12 PM 3/23/2001 -0500, Blake Day wrote: > >I just wanted to mention that in my attempts to change the look of threads > >for comments, I ran into a problem. Currently, the slash code adds an > >indent constant to the beginning of every "linkComment" (which is a link > >to the threaded comment). I think this method is very > >non-templatized. In order to put threaded comments into table rows, I had > >to basically butcher the code in Slash::displayThread and some other > >functions. Is there something I'm missing? Or is this an oversight with > >the template development? > > > >Thanks, > >Blake Day > > > > Blake, > > What you could do for this - > > instead of hacking at slash, make your own module, > copy Slash::displayThread and put that into your module. > edit to suite. save, compile. (possibly install as a plugin). > > I ran into what you're talking about when I originally did those > ubbish templates. I realized it'd take way too much time to do > and moved on from it. > > Have you looked at the new comment system they're doing for slash 2.2? > You might want to look at that, and start your 'ubb' look with that > instead of the current comment system. You could key your ubblook > to a story param. I say this because, from what > I understand, bender 2.2 will have that new comment system fully > functional. And since they're doing it because Slashdot needs it > (again, that's my understanding) I'd guess it'll get coded quickly > so they can move /. to bender asap. > > Shane > > > _______________________________________________ > Slashcode-development mailing list > Sla...@li... > http://lists.sourceforge.net/lists/listinfo/slashcode-development > > > _______________________________________________ Slashcode-development mailing list Sla...@li... http://lists.sourceforge.net/lists/listinfo/slashcode-development |
From: Chris N. <pu...@po...> - 2001-03-27 12:12:40
|
At 21:29 -0500 2001.03.26, Blake Day wrote: >Cliff, I needed to do something liek the following: > > >Replies: > > >Comment 1 username1 March 25, 2001 > Re: Comment 1 username2 March 26, 2001 >Comment 2 username3 March 25, 2001 > >I could not do that with the simple indent variable. I needed them in table >rows. > >I personally think the display would be more extensible that way. Am I >missing something? Yes. :) As already noted: 1. It is not easy to separate this logic from the display; it's easy to say "let us customize it however we want," but it is harder to actually do that, when these things are tied this closely together. 2. What you want to do is change the behavior of these things. The templates are note for changing behavior, but display. You can always change the code, or add new code (via a plugin, etc.). Even if we could allow what you want simply by changing templates, someone else would come along and want something we couldn't provide in the templates. 3. We are rewriting comments anyway; there was little point in putting a lot of work into code that was going to be replaced in 2.2. Yes, it would be nice to be able to easily customize it in any way you want to. But this is just a low priority, so we did what we could for the time being. Hopefully, it will be more easily customizable in 2.2. >Btw, I have already gotten it tow ork by modifying code. That's great. Thanks, -- Chris Nandor pu...@po... http://pudge.net/ Open Source Development Network pu...@os... http://osdn.com/ |
From: Blake D. <bl...@ar...> - 2001-03-28 00:44:58
|
Chris, Not a problem, I just wanted to let you guys know about something I realized. I'm a table-type of person, so I am somewhat partial towards making it "default" to use table rows. When will 2.2 be coming out (if you don't mind my pestering.. I'm sure you get plenty from everyone else)? Thanks, Blake Day CTO, SpunkNetwork bl...@sp... <mailto:bl...@sp...> home: (770) 338-1589 mobile: (678) 485-0519 -----Original Message----- From: sla...@li... [mailto:sla...@li...]On Behalf Of Chris Nandor Sent: Tuesday, March 27, 2001 7:12 AM To: sla...@li... Cc: sla...@li... Subject: RE: [Slashcode-development] change the look of threads forcomments At 21:29 -0500 2001.03.26, Blake Day wrote: >Cliff, I needed to do something liek the following: > > >Replies: > > >Comment 1 username1 March 25, 2001 > Re: Comment 1 username2 March 26, 2001 >Comment 2 username3 March 25, 2001 > >I could not do that with the simple indent variable. I needed them in table >rows. > >I personally think the display would be more extensible that way. Am I >missing something? Yes. :) As already noted: 1. It is not easy to separate this logic from the display; it's easy to say "let us customize it however we want," but it is harder to actually do that, when these things are tied this closely together. 2. What you want to do is change the behavior of these things. The templates are note for changing behavior, but display. You can always change the code, or add new code (via a plugin, etc.). Even if we could allow what you want simply by changing templates, someone else would come along and want something we couldn't provide in the templates. 3. We are rewriting comments anyway; there was little point in putting a lot of work into code that was going to be replaced in 2.2. Yes, it would be nice to be able to easily customize it in any way you want to. But this is just a low priority, so we did what we could for the time being. Hopefully, it will be more easily customizable in 2.2. >Btw, I have already gotten it tow ork by modifying code. That's great. Thanks, -- Chris Nandor pu...@po... http://pudge.net/ Open Source Development Network pu...@os... http://osdn.com/ _______________________________________________ Slashcode-development mailing list Sla...@li... http://lists.sourceforge.net/lists/listinfo/slashcode-development |
From: Chris N. <pu...@po...> - 2001-03-28 02:08:47
|
At 19:51 -0500 2001.03.27, Blake Day wrote: >making it "default" to use table rows. When will 2.2 be coming out (if you >don't mind my pestering.. I'm sure you get plenty from everyone else)? We don't know. We are in the planning phase now. We've got tasks to do, we're dividing them up, looking at what each will take to develop, etc. -- Chris Nandor pu...@po... http://pudge.net/ Open Source Development Network pu...@os... http://osdn.com/ |
From: Chris N. <pu...@po...> - 2001-03-26 19:18:35
|
At 23:12 -0500 2001.03.23, Blake Day wrote: ><x-html><!x-stuff-for-pete base="" src="" id="0" >charset="iso-8859-1"><!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 >Transitional//EN"> ><HTML><HEAD> ><META content="text/html; charset=iso-8859-1" http-equiv=Content-Type> ><META content="MSHTML 5.00.3211.1700" name=GENERATOR></HEAD> ><BODY> ><DIV><FONT face=Arial size=2><SPAN class=016041004-24032001>I just >wanted to >mention that in my attempts to change the look of threads for comments, >I ran >into a problem. Currently, the slash code adds an indent constant >to the >beginning of every "linkComment" (which is a link to the threaded >comment). I think this method is very non-templatized. In >order to >put threaded comments into table rows, I had to basically butcher the >code in >Slash::displayThread and some other functions. Is there something >I'm >missing? Or is this an oversight with the template >development?</SPAN></FONT></DIV> ><DIV><FONT face=Arial size=2><SPAN >class=016041004-24032001></SPAN></FONT> </DIV> ><DIV><FONT face=Arial size=2><SPAN >class=016041004-24032001>Thanks,</SPAN></FONT></DIV> ><DIV><FONT face=Arial size=1>Blake Day</FONT></DIV> ><DIV> </DIV></BODY></HTML> > ></x-html> Please don't send HTML mail to the list. Thanks. As to the constants, those are all in the data;misc;default template. Would changing those help you? Note that in the case of comments, behavior (logic) is tied very closely to display. If you want to significantly change the _behavior_ of comments, you'll want to use your own code, or change ours. Also note that we are rewriting comments as we speak, for Slash 2.2, and I imagine it will be easier to customize, but I have not been working on it much myself. -- Chris Nandor pu...@po... http://pudge.net/ Open Source Development Network pu...@os... http://osdn.com/ |