slashcode-development — This list is for development of slashcode, no install questions please.

Followup: Re: [Slashcode-development] Re: Question about section behavior with regard to Sections

[Shane <sh...@lo...>]

FYI: For all of you that were interested in this thread, it was 
discussed a bit on IRC. As it stands, the sections code is due for an 
entire revamp w/in the next 3 months.

So I'm going to hold off on my questions regarding sections until 
either the new stuff is committed, or someone from OSDN brings the 
topic up.

No specifics at all were mentioned, btw.

Hopefully, they'll bring back the isolated sections functionality :)

Thanks,
  Shane

P.S. Thanks to Cliff for taking so much time to reply to all the 
related questions :)

Re: [Slashcode-development] Re: Question about section behavior with regard to Sections

[Cliff W. <cl...@sl...>]

Shane wrote:

> ok, an example then, if you don't mind :)

Uhhh... uh oh... ;)

> 
> site has:
>  sections:
>                type           issitedefault
>   ---------------------------------------------
>    index       collection     no
>    articles    contained      yes
>    features    contained      no
>    cars        collection     no
>  a plugin, called plugin.pl. it's data objects can have a section/topic 
> associated with each.
> 
> So when someone hits /plugin.pl, they are actually section=='index', and

No. I would not assume this, since if someone invokes plugin.pl like so:

	http://your.site/plugin.pl?section=features

Then the section is *features*, not index.

> the code should do:
> 
>     # This handles section.url's defining the section in Slash::Apache I 
> think
>     my $section = $reader->getSection($form->{section});
>     # If it wasn't set in the URL passed to us to get us here, then 
> we'll set it with
>     # the section that's coming found from Apache, or, use the 
> user_currentSection
>     $form->{section}        ||= $section->{section} ||  
> $user->{currentSection} || '';
>     # And lastly, a double check, since 'index' is a pseudo-section
>     $form->{section} = '' if $form->{section} eq 'index';

I don't really think you need that last check, since 'index' is no 
longer "pseudo", since it is now in the sections table.

I think the code SHOULD do the right thing even if $form->{section} is
index, so I don't know if you need that last check there, however recent 
code changes may prove me wrong.

> At that point, the plugin should list any data which has the following 
> association:
>  data that has:
>   a. no section assigned or
>   b. *any* section that is *not* a contained section
> 
> Do you agree?

No.

NEVER assume A!

Always assume that a data object has a section. Every data object SHOULD 
have a section. If no section is specified, then the object should be 
written to the database with the DEFAULT section as specified in the 
sections table (in your example, the default section is "articles").

B: That should be "any section that is not a *collected*" section.

Collected sections are pseudo sections that are unions of each 
"contained" section it is associated with. Data objects should never 
reference a collected section, they should only reference *contained* 
sections. I'm sorry if that was unclear.

> Now, section features is contained. It has a URL of features.tld.com. So 
> if someone hits
>  http://features.tdl.com/plugin.pl
> 
>  the plugin should only grab data that is section=='features', and 
> absolutely no other section.

Yes.

> And finally, section 'cars' is a collection of sections. It has a URL of 
> cars.tld.com. So if someone hits
>  http://cars.tdl.com/plugin.pl
> 
> the plugin should only grab data that is section=='cars', and 
> absolutely no other section.

No. You are missing a table in your example: sections_contained.

I'm ASSUMING, since I haven't had a chance to look at the 
implementation, that "collected" sections (aside from 'index') have 
entries in this table that represents which sections will be "collected" 
by your section "cars".

Let's update your example.

 >                type           issitedefault
 >   ---------------------------------------------
 >    index       collection     no
 >    articles    contained      yes
 >    features    contained      no
 >    cars        collection     no
]    sports      contained	no
]    economy     contained	no
]    concept     contained	no
]    hotrods     contained	no

Then your sections_contained table, for the cars section, will look like so:

         container	section
     ------------------------------
	cars		sports
	cars		economy
	cars		concept
	cars		hotrods

And your plugin will pull up all objects

	WHERE section IN ('sports', 'economy', 'concept', 'hotrods')

> If you don't agree, how do you define what sections are in the index 
> section's 'collection'? Or are they all, no matter what???

The only thing "pseudo" about index, these days, is its contents. 
There's nothing in the sections_contained table for the "index" section 
since it's defined as "all contained sections that are not isolated", 
and the code can determine this on its own.

> It would seem I understand the that you're saying if a section is a 
> collection, then you grab everything underneath it. And if it's 
> contained, then it can not be part of a collection.

No. It's exactly what I stated, before.

A contained selection is a collection of data objects (stories, 
galleries, pictures, etc).

A collected section is a *collection of contained sections*.

> However, index doesn't seem to follow that rule for most sites then. 
> Things like articles, and features, should be subsections of index. 
> Because inorder for you to be in section=='index', index is a collection 
> and should never show a contained section's (ie articles, or features) 
> data.

I'm not quite sure what the hell "subsections", are. I think they are 
there if you want to establish some kind of hierarchy to your sections 
(children, parent sort of thing). This is independent of the "collected" 
and "contained" paradigm, and can, in fact, be used in conjunction with it.

If you don't get that last sentence...don't worry about it. ;)

> If I haven't lost you - *this* is where I am looking to define the 
> default behavior.
> 
> Because it would seem that a plugin should give you the list of it's 
> data, and then a pulldown to let you filter that list by 
> section/topic/whatever. Example:
> 
> http://www.lottadot.com/galleria.pl
> 
> The thing is - to pick on the section pulldown - should that pulldown 
> actually *not* have the 'mtb' section in it, because that 'mtb' section 
> is contained?

That depends entirely on you. If you want your plugin to deal with 
"collected" sections, then yes. It does, however, mean extra work.

If you only want your plugin to deal with "contained" sections, then no.

> And then following that logic - if you hit
> 
> http://mtb.lottadot.com/galleria.pl
> 
> that's section=='mtb'. It's a contained section. So, if it had 
> subsections, then it should show a section pulldown. Otherwise, it 
> should not, because it's contained, a contained section limits to that 
> in and of itself, and ignores all other sections?

Again. I wouldn't worry about the subsections, and this particular piece 
of behavior is up to you.

If you want users to be able to override the subdomain given in the host 
name, then keep the sections pulldown. If you wish your plugins to 
consider "contained" sections as a leaf, then if a section is given, you 
don't have to display a section pulldown. If your site has a section 
hierarchy and the given section has children, then display a pulldown.

It's a tough question, and I can't give specific answers.

To adress the simplest case I can think of (no subsections, no 
"collected" sections aside from index) then, using your example,
you would not need a pulldown at all because a section has already been 
selected: mtb -- just display a topic pulldown (and if you want to 
display something, display all objects contained in the "mtb" section).

> Part of what I'm getting at (I'll bring this in, to make things more 
> confusing), is the idea of the isolated sections (parts of which are 
> still in the code). It used to be that you could create a section, mark 
> it isolated, and *nothing* would link/reference that section. Hence, 
> it's hidden, unless you are specifically told about it. At first I 
> thought the 'contained' section was the direct replacement for the 
> isolated section, but now I'm not so sure.

CRUD! OK. Massive correction to the above after checking a local schema:

	THERE IS NO ISOLATION.

Which makes sense, for just about everything except the "index" section.

The only thing I can think of (and current Slashteam members may want to 
step in, here) is that if there is no reference to the "index" section 
in sections_contained, then the "index" section collects ALL of your 
contained sections. If you want an "isolated" section, you'll have to 
specify the "index" sections, just like you would any other "collected" 
section. -- This is the only thing that makes sense to me. If this is 
the case, then everything I've already said above, is true, with these 
recent considerations.

Augh! No isolation. And I forgot to look. How embarassing! :)

> Thanks,
>  Shane
> 
> PS: One question: if a section is not the index, and it is marked as 
> type 'collection', then is it not actually a collection of subsections?

No. Not necessarily.

It CAN be, if you use a section hierarchy, but it doesn't NEED to be. 
You can have a "grouping" of sections without the need to establish any 
kind of order.

*whew* -- Excuse me while I try and untie the knots in my brain after 
all of that.

- Cliff

Re: [Slashcode-development] Re: Question about section behavior with regard to Sections

[Shane <sh...@lo...>]

On Feb 2, 2004, at 2:34 PM, Cliff Wood wrote:

> Speaking as a Generic-Slash-Developer
>
> As near as I can tell, there are two types of sections: "contained" 
> and "collected".
>
> If you have a "contained" section, you limit the objects in question 
> to only those of that specific section.
>
> If you have a "collected" section, you limit the objects in question to
> ALL sections that are "collected" in the section referenced.
>
> The "index" section is a "collected" section, so I'd say that you'd 
> display only the objects (in your case galleries) that are collected 
> by the "index" section. Likewise if you had a "collected" section 
> called "shane-mtb", you'd display all of the galleries collected in 
> the "shane" and the "mtb" section.
>
> My point here is that I think you are mistaking the intent of the 
> "index" section, and that is why you are confused. Stick with the 
> general rules of section types and I think you'll most likely match 
> the "generally expected section behavior".

ok, an example then, if you don't mind :)

site has:
  sections:
                type           issitedefault
   ---------------------------------------------
    index       collection     no
    articles    contained      yes
    features    contained      no
    cars        collection     no
  a plugin, called plugin.pl. it's data objects can have a section/topic 
associated with each.

So when someone hits /plugin.pl, they are actually section=='index', 
and the code should do:

     # This handles section.url's defining the section in Slash::Apache 
I think
     my $section = $reader->getSection($form->{section});
     # If it wasn't set in the URL passed to us to get us here, then 
we'll set it with
     # the section that's coming found from Apache, or, use the 
user_currentSection
     $form->{section}        ||= $section->{section} ||  
$user->{currentSection} || '';
     # And lastly, a double check, since 'index' is a pseudo-section
     $form->{section} = '' if $form->{section} eq 'index';

At that point, the plugin should list any data which has the following 
association:
  data that has:
   a. no section assigned or
   b. *any* section that is *not* a contained section

Do you agree?

Now, section features is contained. It has a URL of features.tld.com. 
So if someone hits
  http://features.tdl.com/plugin.pl

  the plugin should only grab data that is section=='features', and 
absolutely no other
  section.

And finally, section 'cars' is a collection of sections. It has a URL 
of cars.tld.com. So if someone hits
  http://cars.tdl.com/plugin.pl

  the plugin should only grab data that is section=='cars', and 
absolutely no other
  section.

Do you agree?

If you don't agree, how do you define what sections are in the index 
section's 'collection'? Or are they all, no matter what???

It would seem I understand the that you're saying if a section is a 
collection, then you grab everything underneath it. And if it's 
contained, then it can not be part of a collection.

However, index doesn't seem to follow that rule for most sites then. 
Things like articles, and features, should be subsections of index. 
Because inorder for you to be in section=='index', index is a 
collection and should never show a contained section's (ie articles, or 
features) data.

If I haven't lost you - *this* is where I am looking to define the 
default behavior.

Because it would seem that a plugin should give you the list of it's 
data, and then a pulldown to let you filter that list by 
section/topic/whatever. Example:

http://www.lottadot.com/galleria.pl

The thing is - to pick on the section pulldown - should that pulldown 
actually *not* have the 'mtb' section in it, because that 'mtb' section 
is contained?

And then following that logic - if you hit

http://mtb.lottadot.com/galleria.pl

that's section=='mtb'. It's a contained section. So, if it had 
subsections, then it should show a section pulldown. Otherwise, it 
should not, because it's contained, a contained section limits to that 
in and of itself, and ignores all other sections?

Part of what I'm getting at (I'll bring this in, to make things more 
confusing), is the idea of the isolated sections (parts of which are 
still in the code). It used to be that you could create a section, mark 
it isolated, and *nothing* would link/reference that section. Hence, 
it's hidden, unless you are specifically told about it. At first I 
thought the 'contained' section was the direct replacement for the 
isolated section, but now I'm not so sure.

Thanks,
  Shane

PS: One question: if a section is not the index, and it is marked as 
type 'collection', then is it not actually a collection of subsections?

Re: [Slashcode-development] Re: Question about section behavior with regard to Sections

[Cliff W. <cl...@sl...>]

Speaking as a Generic-Slash-Developer

As near as I can tell, there are two types of sections: "contained" and 
"collected".

If you have a "contained" section, you limit the objects in question to 
only those of that specific section.

If you have a "collected" section, you limit the objects in question to
ALL sections that are "collected" in the section referenced.

The "index" section is a "collected" section, so I'd say that you'd 
display only the objects (in your case galleries) that are collected by 
the "index" section. Likewise if you had a "collected" section called 
"shane-mtb", you'd display all of the galleries collected in the "shane" 
and the "mtb" section.

My point here is that I think you are mistaking the intent of the 
"index" section, and that is why you are confused. Stick with the 
general rules of section types and I think you'll most likely match the 
"generally expected section behavior".

Users won't necessarily get this, initially. However if your site is 
consistent, they *should* eventually get it. If not, a simple 
explanation of how the sections work, should kick in the lightbulb over 
their heads, so I wouldn't worry about it.

The Slash Team can correct any misconceptions in what I've said above, 
when they have the time.

- Cliff
Generic Slash Developer

Shane wrote:

> Hey guys, I realize everyone's busy and all, but I would appreciate some 
> replies on this one.
> 
> I *know* I'm not the only one who's in the quagmire of "how should a 
> plugin's behavior work". I've had people email me asking the same thing 
> a few times.
> 
> I'm not trying to be an ass, but for me, it's questions like this that 
> make it hard to code for Slash. I would rather code things with 
> consistency, so that the plugins work *with* Slash, and it's 
> organization and look and feel. And I'd rather code it right the first 
> time, then have to go back and re-tool.
> 
> We (the confused/misguided/whatever) need some direction here.
> 
>  Shane
> 
> On Jan 14, 2004, at 7:35 AM, Shane wrote:
> 
>> This question is about how our plugins should behave in regard for 
>> sections.
>>
>> I'm not sure even what I'm asking, so reading this may be an exercise 
>> for patience. I'll show what I'm asking about by example, first, then 
>> try to elaborate a bit more at the end about it.
>>
>> I have a photogallery plugin. Each user can have up to XX galleries. 
>> Each gallery can be associated with a section and a topic.
>>
>> If someone hits the gallery plugin, from 'section==index', as in 
>> http://www.lottadot.com/galleria.pl , then I have it set so that
>>
>> a) it shows only galleries marked with section 'index'
>> b) it shows a pulldown that will let you change the section and topic.
>>
>> Now, goto a section that's marked as 'contained':
>>
>> http://shane.lottadot.com/galleria.pl
>>
>> Since you're hitting a section that's contained, it automatically only 
>> shows galleries that are section = 'shane'.
>>
>> Is this the *expected* behavior that plugins should handle data 
>> display with regard to sections such that if the current hit's section 
>> ne 'index' then limit data to that current_section only?
>>
>> Now, I updated Slash::Apache::User a bit, adding some /my/ options as 
>> such:
>>
>> http://www.lottadot.com/~shane/galleries
>>
>> lists user "shane"'s galleries that are only in section 'index'.
>>
>> and http://shane.lottadot.com/~shane/galleries
>>
>> lists user "shane"'s galleries that are only in section 'shane'.
>>
>> as well as http://mtb.lottadot.com/~shane/galleries
>>
>> only lists my galleries in section 'mtb'.
>>
>> That's supposed to mimick the "standard slash behavior".
>>
>> Now, given that I've spent a little bit of time toying with the 
>> Slashcode over the past couple of years, if this is expected behavior, 
>> I understand it.
>>
>> However, I wonder if *users* don't?
>>
>> And if they don't, how are you developing your plugins such that they 
>> *do* understand the section/topic/relationship.
>>
>> For the adventurous, if you'd like to comment about what should happen 
>> when a section is 'a collection of sections', or, possibly, when it's 
>> 'isolated', I'd love to see discussion about that as well.
>>
>> Thanks,
>>  Shane
>>
>>
> -- 
> One gadget to catch them all, and in digital darkness bind them.
> 
> 
> 
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> Slashcode-development mailing list
> Sla...@li...
> https://lists.sourceforge.net/lists/listinfo/slashcode-development

[Slashcode-development] Re: Question about section behavior with regard to Sections

[Shane <sh...@lo...>]

Hey guys, I realize everyone's busy and all, but I would appreciate 
some replies on this one.

I *know* I'm not the only one who's in the quagmire of "how should a 
plugin's behavior work". I've had people email me asking the same thing 
a few times.

I'm not trying to be an ass, but for me, it's questions like this that 
make it hard to code for Slash. I would rather code things with 
consistency, so that the plugins work *with* Slash, and it's 
organization and look and feel. And I'd rather code it right the first 
time, then have to go back and re-tool.

We (the confused/misguided/whatever) need some direction here.

  Shane

On Jan 14, 2004, at 7:35 AM, Shane wrote:

> This question is about how our plugins should behave in regard for 
> sections.
>
> I'm not sure even what I'm asking, so reading this may be an exercise 
> for patience. I'll show what I'm asking about by example, first, then 
> try to elaborate a bit more at the end about it.
>
> I have a photogallery plugin. Each user can have up to XX galleries. 
> Each gallery can be associated with a section and a topic.
>
> If someone hits the gallery plugin, from 'section==index', as in 
> http://www.lottadot.com/galleria.pl , then I have it set so that
>
> a) it shows only galleries marked with section 'index'
> b) it shows a pulldown that will let you change the section and topic.
>
> Now, goto a section that's marked as 'contained':
>
> http://shane.lottadot.com/galleria.pl
>
> Since you're hitting a section that's contained, it automatically only 
> shows galleries that are section = 'shane'.
>
> Is this the *expected* behavior that plugins should handle data 
> display with regard to sections such that if the current hit's section 
> ne 'index' then limit data to that current_section only?
>
> Now, I updated Slash::Apache::User a bit, adding some /my/ options as 
> such:
>
> http://www.lottadot.com/~shane/galleries
>
> lists user "shane"'s galleries that are only in section 'index'.
>
> and http://shane.lottadot.com/~shane/galleries
>
> lists user "shane"'s galleries that are only in section 'shane'.
>
> as well as http://mtb.lottadot.com/~shane/galleries
>
> only lists my galleries in section 'mtb'.
>
> That's supposed to mimick the "standard slash behavior".
>
> Now, given that I've spent a little bit of time toying with the 
> Slashcode over the past couple of years, if this is expected behavior, 
> I understand it.
>
> However, I wonder if *users* don't?
>
> And if they don't, how are you developing your plugins such that they 
> *do* understand the section/topic/relationship.
>
> For the adventurous, if you'd like to comment about what should happen 
> when a section is 'a collection of sections', or, possibly, when it's 
> 'isolated', I'd love to see discussion about that as well.
>
> Thanks,
>  Shane
>
>
--
One gadget to catch them all, and in digital darkness bind them.

Re: [Slashcode-development] Optimizing slash site

[Shane <sh...@lo...>]

On Jan 16, 2004, at 2:45 PM, Christopher Winn wrote:

> Hey everyone,
>
> Here are three facts that will lead up to a question.
>
> 1) When someone hits my slash site, they end up at /index.pl
>
> 2) /homepage/index.shtml exists
>
> 3) A cookie tracks if they're signed in or not (when anonymous, the 
> cookie is user=nobody)
>
>
> Here's what I'm wondering. How can I create something simple that...
>
>
> 1) Checks for a cookie.
>
> 2) If cookie does not exist, or equals nobody, redirect to 
> /homepage/index.shtml
>
> 3) Otherwise, hit index.pl
>
>
> This would really take some load off of dynamic perl, thus helping 
> performance and stability.
> Has anyone done this?
>

There's a var in your site's config:vars that'll turn this behavior on. 
there's another var that'll let you set what filename you want it to 
redirect to.
I think they are index_handler_noanon and index_noanon.

I'm not sure what version of slash you'd need to be running to get this 
behavior built in, probably CVS. If you're not running CVS, there's an 
older apache handler built specifically for this, grab it at 
http://www.lottadot.com/

  Shane

[Slashcode-development] Optimizing slash site

[Christopher W. <cw...@jo...>]

Hey everyone,

Here are three facts that will lead up to a question.

1) When someone hits my slash site, they end up at /index.pl

2) /homepage/index.shtml exists

3) A cookie tracks if they're signed in or not (when anonymous, the 
cookie is user=nobody)


Here's what I'm wondering. How can I create something simple that...


1) Checks for a cookie.

2) If cookie does not exist, or equals nobody, redirect to 
/homepage/index.shtml

3) Otherwise, hit index.pl


This would really take some load off of dynamic perl, thus helping 
performance and stability.
Has anyone done this?



Thanks,
Chris

[Slashcode-development] new feature idea - Post Poll

[<da...@pa...>]

hi all,

i just made a post to slashdot that said:

 "please mod parent up"

i occasionally do this (like many others) in an 
attempt to get the moderators to notice a post 
(admittedly quite a lame attempt since the moderator 
would usually have already seen the parent post just 
prior to viewing the moderation request).

well this was the first time i'd ever done this twice 
in the same thread and as you know i received this 
message in reply:

"This exact comment has already been posted. Try to be 
more original..."

that made me wonder about adding a feature to 
slashcode that would allow folks without mod points to 
indicate that a particular post deserves moderating.

this could potentially make it easier for moderators 
to find a post that was languishing (unnoticed by 
moderators but noticed by the more numerous folks 
without mod points) in the backwater of some thread.

maybe each post could have the equivalent of a mini 
poll attached to it.

something like:

  Post Poll
    ( ) Mod Up
    ( ) Mod Down

again, the purpose of this would be to alert 
moderators to posts they were unaware of.

once aware they would moderate as they see fit. 

other possible names that exemplify the raison d'etre 
of this feature might be Post Meta-Poll or just Meta-
Poll (although these names have the potential to be 
confusing due to the existence of the term meta-
moderation).

has this been suggested before?

anyhoo, just brainstorming.


david
--
da...@pa...

[Slashcode-development] Question about section behavior with regard to Sections

[Shane <sh...@lo...>]

This question is about how our plugins should behave in regard for 
sections.

I'm not sure even what I'm asking, so reading this may be an exercise 
for patience. I'll show what I'm asking about by example, first, then 
try to elaborate a bit more at the end about it.

I have a photogallery plugin. Each user can have up to XX galleries. 
Each gallery can be associated with a section and a topic.

If someone hits the gallery plugin, from 'section==index', as in 
http://www.lottadot.com/galleria.pl , then I have it set so that

a) it shows only galleries marked with section 'index'
b) it shows a pulldown that will let you change the section and topic.

Now, goto a section that's marked as 'contained':

http://shane.lottadot.com/galleria.pl

Since you're hitting a section that's contained, it automatically only 
shows galleries that are section = 'shane'.

Is this the *expected* behavior that plugins should handle data display 
with regard to sections such that if the current hit's section ne 
'index' then limit data to that current_section only?

Now, I updated Slash::Apache::User a bit, adding some /my/ options as 
such:

http://www.lottadot.com/~shane/galleries

lists user "shane"'s galleries that are only in section 'index'.

and http://shane.lottadot.com/~shane/galleries

lists user "shane"'s galleries that are only in section 'shane'.

as well as http://mtb.lottadot.com/~shane/galleries

only lists my galleries in section 'mtb'.

That's supposed to mimick the "standard slash behavior".

Now, given that I've spent a little bit of time toying with the 
Slashcode over the past couple of years, if this is expected behavior, 
I understand it.

However, I wonder if *users* don't?

And if they don't, how are you developing your plugins such that they 
*do* understand the section/topic/relationship.

For the adventurous, if you'd like to comment about what should happen 
when a section is 'a collection of sections', or, possibly, when it's 
'isolated', I'd love to see discussion about that as well.

Thanks,
  Shane

[Slashcode-development] cvs.slashcode.com down ?

[Oliver M. B. <ol...@fa...>]

Hi!

I'm running a Slash site, currently with 2.2.6 hacked up here and there.
Having had another hacking session over new year, I was thinking to
upgrade to the 2.3 branch before further modifying stuff. Unfortunately
cvs.slashcode.com seems to be down for the last week or so. Can anybody
say when it's planned to be up again ? Or better yet, maybe somebody
has a tarball of a recent snapshot around ?

Thanks a lot.

-- 
	Oliver M. Bolzer

GPG (PGP) Fingerprint = 621B 52F6 2AC1 36DB 8761  018F 8786 87AD EF50 D1FF

Re: [Slashcode-development] Creating a new op for the admin page

[Shane <sh...@lo...>]

Just a suggestion - rather then edit admin.pl, create a plugin for your 
new functionality. Your plugin can add a menu item to the admin menu, 
which would call your perl script in your plugin. And when that script 
runs, it can call the admin menu when it runs, so users won't know the 
difference that the new functionality isn't in admin.pl. So if the 
admin plugin's code ever changes, you don't have to worry about it 
because everything you did is in a plugin.

For an example of how this can be done, look at this plugin:

http://dev.lottadot.com/cgi-bin/cvsweb.cgi/lastlogins/

  Shane


On Dec 23, 2003, at 9:02 AM, Blake Carver wrote:

> Hi All,
> I'm working on making a new op for the admin page to edit stuff for 
> users and I'm getting stuck early on.
> Here's what I have. I'm not sure where I've gone wrong, I'm getting no 
> errors back, just a blank page. I'm not sure I'm calling 
> getDescriptions correctly.
> I'm calling my op list_users, so "my $ops" I added:
>               list_users              => {
>                       function        => \&listPeeps,
>                       seclev          => 500,
>                       adminmenu       => 'Users',
>                       tab_selected    => 'users',
>               },
> This calls the sub listPeeps, which is also in admin.pl:
>   my($form, $slashdb, $user, $constants) = @_;
>   my $nickname;
>   my $peeps = $slashdb->getDescriptions('peeps', '', 1);
>   slashDisplay('listPeeps', {
>               nickname  => $nickname
>   });
>
> MySQL.pm is in MySQL.pm, to which I added peeps to %descriptions:
>       'peeps'
>    => sub { $_[0]->sqlSelectMany('seclev, nickname, uid', 'users') },
>
> And all of this needs a new template, listPeeps, which is simply:
> <FORM ACTION="[% env.script_name %]" METHOD="POST">
> <INPUT TYPE="HIDDEN" NAME="op" VALUE="vars">
> <TABLE>
> 	<TR>
> 		<TD>Name</TD><TD>[% $nickname %]
> 	</TR>
> </TABLE>
> </FORM>
> The HTML does show up on the admin page, just not the list of 
> nicknames.
>
> Thanks!
> -Blake
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign up for 
> IBM's
> Free Linux Tutorials.  Learn everything from the bash shell to sys 
> admin.
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> _______________________________________________
> Slashcode-development mailing list
> Sla...@li...
> https://lists.sourceforge.net/lists/listinfo/slashcode-development
>

[Slashcode-development] Creating a new op for the admin page

[Blake C. <li...@li...>]

Hi All,
I'm working on making a new op for the admin page to edit stuff for users 
and I'm getting stuck early on.
Here's what I have. I'm not sure where I've gone wrong, I'm getting no 
errors back, just a blank page. I'm not sure I'm calling getDescriptions 
correctly. 

I'm calling my op list_users, so "my $ops" I added:
               list_users              => {
                       function        => \&listPeeps,
                       seclev          => 500,
                       adminmenu       => 'Users',
                       tab_selected    => 'users',
               }, 

This calls the sub listPeeps, which is also in admin.pl: 

   my($form, $slashdb, $user, $constants) = @_;
   my $nickname;
   my $peeps = $slashdb->getDescriptions('peeps', '', 1);
   slashDisplay('listPeeps', {
               nickname  => $nickname
   }); 


MySQL.pm is in MySQL.pm, to which I added peeps to %descriptions:
       'peeps'
    => sub { $_[0]->sqlSelectMany('seclev, nickname, uid', 'users') }, 


And all of this needs a new template, listPeeps, which is simply:
<FORM ACTION="[% env.script_name %]" METHOD="POST">
<INPUT TYPE="HIDDEN" NAME="op" VALUE="vars">
<TABLE>
	<TR>
		<TD>Name</TD><TD>[% $nickname %]
	</TR>
</TABLE>
</FORM> 

The HTML does show up on the admin page, just not the list of nicknames. 


Thanks! 

 -Blake 

Re: [Slashcode-development] Re: Slashcode-development digest, Vol 1 #306

[Cliff <cl...@sl...>]

On Thursday 18 December 2003 13:22, James Marca wrote:
> At approximately Wed, Dec 17, 2003 at 04:06:04PM -0500, Clifton 
Wood wrote:
> > Oooh! Then may I suggest this attached plugin? ;)
>
> ...
>
> >  bugs you might find. I hope you are running from CVS, as that's
> >  what this code is based on.
>
> I am running the stable release, but am perfectly willing to run
> CVS. which tag should I fetch?

Try it with the stable release and see if it works or not. In the
interest in getting this used, I probably *should* grab a copy
of stable 2.2.6 and do a backport.

- Cliff

Re: [Slashcode-development] Re: Slashcode-development digest, Vol 1 #306

[Clifton W. <cl...@sl...>]

On Tuesday 16 December 2003 13:27, James Marca wrote:
> > From: Clifton Wood <cl...@sl...>...
> >
> > > First, I can only seem to access the menu entries in the
> > > menus...
> >
> > No, this is in the API, you can either do it through Perl:
> >
> > 	perl -MSlash::Test=virtualuser -le \
> > 		'print Dumper($slashdb->getMenuItems(<menuname>))'
>
> ...
>
> > 	[% menus = Slash.db.getMenuItems("admin") %]
>
> I'm sorry, I wasn't clear.  I can't see any way to *edit* the menu
> items from within the admin interface.  Of course I can fetch the
> data programmatically as you suggest, but I can't change the
> entries from within a running slash site.  I have to either write
> a sql script or run mysql console.

Oooh! Then may I suggest this attached plugin? ;)

(Unzip in your /usr/local/slash/plugins directory and then install
 it using /usr/local/slash/bin/install-plugin) -- Ping me on any
 bugs you might find. I hope you are running from CVS, as that's
 what this code is based on.

- Cliff

[Slashcode-development] Re: Slashcode-development digest, Vol 1 #306

[James M. <jm...@tr...>]

> From: Clifton Wood <cl...@sl...>...
> 
> > First, I can only seem to access the menu entries in the menus...
> 
> No, this is in the API, you can either do it through Perl:
> 
> 	perl -MSlash::Test=virtualuser -le \ 
> 		'print Dumper($slashdb->getMenuItems(<menuname>))'
...
> 	[% menus = Slash.db.getMenuItems("admin") %]
> 

I'm sorry, I wasn't clear.  I can't see any way to *edit* the menu
items from within the admin interface.  Of course I can fetch the data
programmatically as you suggest, but I can't change the entries from
within a running slash site.  I have to either write a sql script or
run mysql console.

> > Second, the menus table could use another hook ...
> Another (and non-normalized) way to do this would be to 
> create another table:
...
> [and access it] via template:
> 
> 	[% 
> 		styleinfo = Slash.db.sqlSelect(
> 			'styleid, stylecss',
> 			'menu_styles',
> 			'id=' . Slash.db.sqlQuote(menu_id)
> 		);
> 	%]
> 
> This gives you the advantage of compatibility with the Slash 
> libraries, and flexibility to add whatever you need to 
> the menu_styles table, at the expense of maintaining your

Good idea, thanks.  I have been trying to stick with "stock" slashcode
calls for generating headers and footers of a page, modifying only the
template.  This looks like a decent recipe for fetching the style data
from within a modified template.

> 
> > Third, [static vs dynamic  css style sheet]
> > [ ... ]
> 
> You don't mention what types of style sheets need the dynamic
> treatment, nor where you are generating them in the overall scheme
> of Slash.
...
> If you have a specific set of CSS styles that need to be regenerated
> over the course of the day, you could make a task to update these
> dynamically (the file is served static, but dynamically generated
> ever <x> minutes or <y> hours).

Right I forgot about that capability.  This would work well for stuff
like inserting menu items---the new menu items need their own id tags
to be defined in the stylesheet.  That changes slowly, and can be
handled with a periodic (daily or slower) job.

Other CSS dynamicism (?) I can think of mirrors Slash's ability to set
colors, etc.  For example, the following snippet from header;misc;default

<BODY BGCOLOR="[% user.bg.0 %]" 
      TEXT="[% user.fg.1 %]" 
      LINK="[% user.bg.3 %]" 
      VLINK="[% user.fg.1 %]">

could also be accomplished with a  markup CSS "file" which is generated
in the header template, something like (not having tested it):

.user_scheme0 {
      background-color: [% user.bg.0 %];
      color: [% user.fg.1 %];
}
.user_scheme0 a:link {
      color: [% user.bg.3 %];
}
.user_scheme0 a:visited {
      color: [% user.fg.1 %];
}
.user_scheme0 a:hover {
      color: [% user.fg.1 %];
}

.user_scheme1 {
...
}

then the tag markup becomes, for example,

<BODY class='user_scheme0' id='[% selected_menu_item %]'>


I'll continue to hack on this over the holidays, and post at a later
date what I end up doing in practice.

cheers,
James

ps. I don't want to bore anyone with my litany of projects using
slashcode.  If anything ever gets stable and useful, I'll publish them
somehow.  But right now I'm more or less driving nails with an iPod.  

Re: [Slashcode-development] some of my thoughts/requests for slashcode devel

[Clifton W. <cl...@sl...>]

On Monday 15 December 2003 12:34, James Marca wrote:

> Couple of thoughts on this (having not looked at CVS code, btw).
> First, I can only seem to access the menu entries in the menus
> table by a mysql console, not the admin interface. 

No, this is in the API, you can either do it through Perl:

	perl -MSlash::Test=virtualuser -le \ 
		'print Dumper($slashdb->getMenuItems(<menuname>))'

So if you wanted to get all the menus for the admin pages, for 
example:

	perl -MSlash::Test=<virtualuser> -le \
		'print Dumper($slashdb->getMenuItems("admin"))'

Note, the call to Dumper() is just there to show you what the data
structure looks like, feel free to set the value used to a scalar
and use as you see fit.

If you want to use this exclusively in a template, you can do:

	[% menus = Slash.db.getMenuItems("admin") %]

> Second, the menus table could use another hook
> or two for style sheets, to avoid my ugly text parsing hack. 
> Something like
>
> styleid varchar (20) NOT NULL,
> styleclass varchar(20) NOT NULL default "menuitem",
>
> would probably do it.  I would do that, but the code that renders
> the menu would need to be changed, thus breaking my compatibility
> with the slash libraries. (Hmm, I just thought that maybe it is
> possible to subclass something like the Environment module to
> override that function???)

Another (and non-normalized) way to do this would be to 
create another table:

	create table menu_styles (
		id		mediumint(5) unsigned NOT NULL,
		styleid 	varchar(20) NOT NULL,
		stylecss	varchar(20) NOT NULL default "menuitem",
		UNIQUE KEY (id)
	);

Any menuitem you retrieve using getMenuItem() will have a unique
ID associated with it, you can then use your own SQL call to 
get the style:

	($style_id, $style_css) = $slashdb->sqlSelect(
		'styleid, stylecss',
		'menu_styles',
		'id=' . $slashdb->sqlQuote($menuitem->{id})
	);

Or via template:

	[% 
		styleinfo = Slash.db.sqlSelect(
			'styleid, stylecss',
			'menu_styles',
			'id=' . Slash.db.sqlQuote(menu_id)
		);
	%]

This gives you the advantage of compatibility with the Slash 
libraries, and flexibility to add whatever you need to 
the menu_styles table, at the expense of maintaining your
own code. If you don't need to do anything more complex
than this, this should suit you just fine.

This is only just one solution, of course. I just thought I should
share. =)

> Third, I am not sure whether it is
> appropriate to put the css style sheet in a separate, static file,
> or render it with a template.  
> [ ... ]
> Any thoughts on static versus dynamic css?  I think the bandwidth
> savings quoted by the "recoding slashdot" article depend upon a
> cached css file.  Perhaps if the css file is dynamically rendered,
> then the savings go poof.  An alternative is to have a mix; some
> css static, other stuff dynamic, as files static_layout.css,
> static_markup.css, and then any dynamic styles pushed into the
> header after the stylesheet include commands.
>
> But I think the attraction of slashcode to me is dynamically
> generating and rendering content.  Philosophically, should the the
> css be considered decoration that can be static, like the various
> icons and borders, or dynamic, like the content?  I think it
> should be dynamic, since it opens up more possibilities (such as
> the extensible menu styles above), and it puts the code in the db
> where it can be manipulated through temlate toolkit.

You don't mention what types of style sheets need the dynamic
treatment, nor where you are generating them in the overall scheme
of Slash. I can only make a general suggestion here that may or
may not be appropriate for what you are doing, I'd need more 
information before would be able to suggest something that
isn't a shot in the dark. I can suggest one thing, however.

If you have a specific set of CSS styles that need to be regenerated
over the course of the day, you could make a task to update these
dynamically (the file is served static, but dynamically generated
ever <x> minutes or <y> hours).

Take a look at some of the code in:

	/usr/local/slash/site/<yoursite>/tasks

For some examples of what I mean. You create whatever code 
snippet you need inside the task structure and let slashd handle
the execution at the times you specify (slashd uses cron timespecs 
to schedule code execution).

Hope these suggestions help. If you'd like to go into more detail
with such things, please drop us another line. 

- C

[Slashcode-development] some of my thoughts/requests for slashcode devel

[James M. <jm...@tr...>]

Hi all,

To the fine folks who develop slashcode regularly, thanks for your
work. 

What I am most concerned with at the moment is migrating my website
style from tables to CSS.  

(By way of background, I use slashcode more as a library than as a
readymade website.  I use the login and authentication stuff without
ever looking at the code, I use the DB interface, and I use the
template toolkit display calls.  And of course, I use the admin
interface to edit templates. )

Over the weekend I finally had a look at that write up on A List Apart
mentioned a few weeks ago in slashdot.  Now I've got one site
rendering in xhtml strict, with a css style sheet, and not a table tag
in site.  But to do so I push in lots of stuff for the CSS template
through a hashref when I call the make header routine, and most
egregiously, I hacked the menu system, overloading the "value" entries
to also set the id tag for each list item, as in:

 <ul>[% FOR i = items %]
  [%- myvalue = i.value -%]
  [%- matches = myvalue.match('(op).(\w+)\"') %]
  <li id="nav-[%- matches.1 -%]"><a [% i.value %]>[% i.label %]</a></li>
 [% END %]</ul>


Couple of thoughts on this (having not looked at CVS code, btw).
First, I can only seem to access the menu entries in the menus table
by a mysql console, not the admin interface.  Is this a feature or a
bug?  Second, the menus table could use another hook or two for style
sheets, to avoid my ugly text parsing hack.  Something like 

styleid varchar (20) NOT NULL, 
styleclass varchar(20) NOT NULL default "menuitem",

would probably do it.  I would do that, but the code that renders the
menu would need to be changed, thus breaking my compatibility with the
slash libraries. (Hmm, I just thought that maybe it is possible to
subclass something like the Environment module to override that
function???)  Third, I am not sure whether it is appropriate to put
the css style sheet in a separate, static file, or render it with a
template.  I do the latter right now, since my usage sets the names of
style ids on the fly based on passed arguments, so that I can add to
the menu with minimal fuss, as in:

... perl to get an arraref to my menu values (parsing op="text"
entries), passed as navids to template ...

[% FOREACH nid = navids %] #[%- nid %] #nav-[%- nid %][%- ', ' UNLESS loop.last -%]
 [% END %]  {
    background-position:0 -150px;
    border-width:0;
}

[% FOREACH nid = navids %] #[%- nid %] #nav-[%- nid %] a[%- ', ' UNLESS loop.last -%]
 [% END %]  {
    background-position:100% -150px;
    padding-bottom:5px;
    color:#333;
}

(which copies shamelessly a technique from another article in A List
Apart)

Any thoughts on static versus dynamic css?  I think the bandwidth
savings quoted by the "recoding slashdot" article depend upon a cached
css file.  Perhaps if the css file is dynamically rendered, then the
savings go poof.  An alternative is to have a mix; some css static,
other stuff dynamic, as files static_layout.css, static_markup.css,
and then any dynamic styles pushed into the header after the
stylesheet include commands.

But I think the attraction of slashcode to me is dynamically
generating and rendering content.  Philosophically, should the the css
be considered decoration that can be static, like the various icons
and borders, or dynamic, like the content?  I think it should be
dynamic, since it opens up more possibilities (such as the extensible
menu styles above), and it puts the code in the db where it can be
manipulated through temlate toolkit.

hoping this long post is appropriate for this list,
James

Re: [Slashcode-development] Using Zoo

[Chris N. <pu...@po...>]

At 4:30 PM -0500 12/13/03, Christopher Winn wrote:
>1) What version of Slash does it require to run?

zoo.pl says in it that 2.3.x is required; I have no idea how much of 2.3.x
is required.  But the bottom line is that you should never use a plugin
distributed in one version of Slash with another version of Slash.  We
often make changes in Slash -- in the modules or even schema --
specifically needed for the plugins, and you can't know easily what parts
of Slash are required.


>2) Is Zoo what I need to implement "Friends of Friends" functionality?

Yes.


>3) The version of Journal that I have, according to journal.pl, is
>1.2.2.60.
>$Id: journal.pl,v 1.2.2.60 2001/10/29 17:19:21 pudge Exp $
>
>Do I need to also update my Journal plugin?

What I'd recommend is using Slash from CVS, either the current Slash, or a
recent one.  Jamie might have more to say than I do about CVS tags, but the
last time we tagged with R_ we considered that essentially release-quality,
and I believe we will be doing another R_ tag soon.

-- 
Chris Nandor                      pu...@po...    http://pudge.net/
Open Source Development Network    pu...@os...     http://osdn.com/

Re: [Slashcode-development] Using Zoo

[Christopher W. <cw...@jo...>]

Sorry, let me expand now that I'm thinking about it more:

1) What version of Slash does it require to run?

2) Is Zoo what I need to implement "Friends of Friends" functionality?

3) The version of Journal that I have, according to journal.pl, is 
1.2.2.60.
$Id: journal.pl,v 1.2.2.60 2001/10/29 17:19:21 pudge Exp $

Do I need to also update my Journal plugin?

Thanks so much,
cw

On Dec 13, 2003, at 4:25 PM, Chris Nandor wrote:

> At 2:56 PM -0500 12/13/03, Christopher Winn wrote:
>> Has anyone worked with the Zoo plugin?  I want to install the "friends
>> of friends" functionality into my Slash site to extend the Friends
>> functionality through the Journal plugin. Anyone have experience
>> installing it and using it?
>
> Yes.  Did you have a question in there?  :)
>
> -- 
> Chris Nandor                      pu...@po...    http://pudge.net/
> Open Source Development Network    pu...@os...     http://osdn.com/

Re: [Slashcode-development] Using Zoo

[Chris N. <pu...@po...>]

At 2:56 PM -0500 12/13/03, Christopher Winn wrote:
>Has anyone worked with the Zoo plugin?  I want to install the "friends
>of friends" functionality into my Slash site to extend the Friends
>functionality through the Journal plugin. Anyone have experience
>installing it and using it?

Yes.  Did you have a question in there?  :)

-- 
Chris Nandor                      pu...@po...    http://pudge.net/
Open Source Development Network    pu...@os...     http://osdn.com/

[Slashcode-development] Using Zoo

[Christopher W. <cw...@jo...>]

Has anyone worked with the Zoo plugin?  I want to install the "friends 
of friends" functionality into my Slash site to extend the Friends 
functionality through the Journal plugin. Anyone have experience 
installing it and using it?
Thanks

[Slashcode-development] Color Assistance for Slashcode Derivative Themes...

[Clifton W. <cl...@sl...>]

Have you ever messed with the "Slashcode" theme and were 
kinda miffed because you changed the colors on your 
site and the corners of your fancyboxes stopped matching
up?

Well, fret no more. If you have perl, a working gimp installation, 
and the gimp-perl interface kit, found at:

	http://www.goof.com/pcg/marc/gimp.html

Then you can end this nuisance forever and create matching
graphics for your boxes with a simple command.

Simply place the attached files in a directory of their own, 
cd to that directory and run the following:

	./color_slash_images -w . -c \#<hex_triplet>

	(Note, some shells require that "#" is quoted...)

If you have bugs to report, please drop me a line. If someone
has some place they wouldn't mind putting this puppy, please
let me know.

- Cliff

[Slashcode-development] Slash Wiki *does* do versioning...

[Bill S. <wsk...@sp...>]

Gerry,

>Like I said, I don't think it does the versioning.


You are mistaken, chromatic's Slash Wiki plugin most definitely does 
versioning.  You can look at any version of the page in the past, see 
who made what change.  Each time a user saves his page, he has the 
option of entering a comment that indicates what he did, and this list 
of changes (with links to all past versions) is available from that page 
as "previous versions" or something of that nature.

>Wikis have their proponents who think they are the greatest, but there 
>is a learning curve.  It doesn't have the critical mass to make the 
>case for it easily.


This is most definitely true. They're not for everything. But on the 
Slash site that I've set up, there is a lot of little things that people 
want to share with the group, but one sentence doesn't really make for a 
whole story.  Add up a lot of one-sentence pieces, and you've got a nice 
document on whatever topic.

I just thought of another idea -- Wiki pages related to the Topics. Each 
Topic would have it's own standalone Wiki "chalkboard" that people could 
use to post whatever small-but-important info that they wanted. Hm.

Sounds like you've hacked something beyond the Slash wiki functionality, 
but still it might be worth a look again, as it seems it wasn't complete 
when you last tried it.

Best regards,

--Bill

Re: [Slashcode-development] Slash Wiki plugin... Needs a home.

[Gerry G. <ge...@ge...>]

On 2003.12.08 13:24 Bill Skellenger wrote:
> Hi Gerry,
> 
> Gerry Gleason wrote:
> 
>> When I'm not thinking completely straight, I want to adapt this tool 
>> for use with Slashcode.  The idea would be a versioned content 
>> management systems for testing and development, then you would 
>> upload the content to the database as a complete release.  
>> Basically, I want the versioned content management system for the 
>> "authored" parts of the content, but I still want the comment system 
>> and fast database implementation of Slashcode.
> 
> 
> So it sounds like you basically want to have a Wiki, that only those 
> with privileges can edit -- (versioning is part of the Wiki), but 
> still have the comment system as implemented by Slash.  Sorry, just 
> thinking out loud so that I'm clear.

Some Wikis do versioning, but from what I've seen it isn't universal.  
I'm pretty sure the Slash plugin just updates the Wiki pages in the 
database, writing over the previous page contents.  That was the 
biggest reason I did not find it good enough.  It was a while ago, but 
I'm pretty sure I verified that this was the case.

> This is a great idea, and I bet that it wouldn't be too out of the 
> question to implement using chromatic's stuff as a base.  (I'm 
> assuming you're speaking of written content though, and not code 
> content)  The "upload file as bodytext" functions already exist 
> elsewhere, you could implement this without too much trouble 
> probably...

Like I said, I don't think it does the versioning.  There is also the
issue of just how much stuff you can edit with the web-interface, and 
whether that is versioned too.  I've already gone pretty far beyond the
basic Wiki functionality so that I can edit the templates with the same 
tool (this is a more or less 'pass-through' mode that I call HTML 
mode).  Even more powerful is the XML processing I've added later that 
supports pulling markup from several sources.

> I'd also like to look into chromatic's Wiki module, because this 
> could also be extended to allow more tags.  I looked around at other 
> Wikis and found that there are some tags like "==" that indicate a 
> <h2> font or whatever.  I saw another that made WikiWords in a grey 
> color if their page(s) hadn't been defined yet.  That was another 
> good idea.

That's a difficulty of Wikis, I don't think there is one common way of 
doing things.  In SubWiki, a WikiWord would just display as typed with 
a '?' after it linked to the add function for that page.  I was very 
disappointed in the quality of the HTML generated by the SubWiki 
formatter.  I'm sure that it varies a lot with other implementations, 
but all-in-all if find Wiki to be to much of a user oriented hack to 
use seriously.

> Regardless, I think the Wiki concept is pretty cool.  It was hard to 
> explain to the guys in my department.  Funny how something so simple 
> can be so effective.  For pages like FAQs and whatnot, it's the 
> ticket.  The problem is that I can't get people to contribute!!

Wikis have their proponents who think they are the greatest, but there 
is a learning curve.  It doesn't have the critical mass to make the 
case for it easily.

Gerry
> --Bill
> 
> 
> 

Re: [Slashcode-development] No more cowards in Messaging

[Shane <sh...@lo...>]

On Dec 8, 2003, at 7:41 PM, Christopher Winn wrote:

> I've replaced the term "Anonymous Coward" throughout my blog =97 but=20=

> it's popping up in Messages, their subjects and the content, and I=20
> can't seem to figure out where it's coming from.
>
> I changed reply_msg;comments and reply_msg_subj;comments =97 but that=20=

> doesn't seem to do it.
>
> Any help would be greatly appreciated.
>
>
Did you change the name of the user w/ the anonymous_coward_uid?
If you didn't, do it.
And even if you did, be sure to mark all your stories as 'dirty', then=20=

slashd will end up re-writing all your stories to disk w/ the new=20
anoncoward username.