From: Cliff W. <cl...@sl...> - 2004-02-06 02:36:36
|
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 |