[Slashcode-development] extracols/extra story fields

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

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
>