Re: [Slashcode-development] (no subject)

[Nathan V. <na...@th...>]

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