Help - Search - Members - Calendar
Full Version: MTCategories&MEntryCategories|Context Difference?
Movable Type Community Forum > Other Product Discussion > Bugs and Odd Behavior
aaber
quoting from the docs:

QUOTE
A container tag representing a list of all of the categories--including the primary category--to which entry belongs. Inside of this container you can use any of the <$MTCategory*$> tags (documentation) to display information about each category.


inside [MTCategories] container tags if a pair of [MTEntries] is used, MTEntries inherits the category information from [MTCategories] but if [MTEntries] is used withing [MTEntryCategories] it does not!

think about what RelatedEntries plugin does, we can do it even without the plugin! this way:

CODE
    <MTEntries>
    <$MTEntryTrackbackData$>

    <div class="blogbody">    
    <a name="<$MTEntryID pad="1"$>"></a>
    <h3 class="title"><$MTEntryTitle$></h3>
    
    <$MTEntryBody$>
    
    <MTCategories>    
    <MTIfEqual a="[MTEntryCategory]" b="[MTCategoryLabel]">
    
    <MTEntries lastn="3" offset="1">
    <MTEntriesHeader>
    Related to this<br/>
    </MTEntriesHeader>
    <MTEntryTitle><br/>    
    </MTEntries>
    
    </MTIfEqual>    
    </MTCategories>

    
    <div class="posted">
 Posted by <$MTEntryAuthor$> at <a href="<$MTEntryPermalink$>"><$MTEntryDate format="%X"$></a>
    </div>
    
    </div>
    </MTEntries>


I've used MTCompare here to limit the output here. I could use MTEntryCategories instead of MTCategories so there wouldn't be any need for MTIfEqual tags but as I mentioned MTEntries doesn't inherit category information from MTEntryCategories .. is this a context bug huh.gif

I'm aware of certain plugins for showing related entries and this is not the problem.. in fact i'd like to know WHY doesn't MTEntries show entries as it must in this example .. maybe the reason is that all this is inside another MTEntries which is generating the entry itself!!
markpasc
QUOTE
maybe the reason is that all this is inside another MTEntries which is generating the entry itself!!

As I understand it, that's exactly it: you're still in a certain entries context when you use the inner MTEntries, so it displays those entries still.
girlie
QUOTE (aaber @ Jan 5 2004, 11:01 AM)
but if [MTEntries] is used withing [MTEntryCategories] it does not!

MTEntryCategories is intended to be used inside of MTEntries, not the other way around. huh.gif

It's used to list categories assigned to an entry, not entries within a category assigned to an entry.
markpasc
E's trying to have MTEntries inside and outside, I thought:

CODE
<MTEntries>
  <h1><MTEntryTitle></h1>
  blah blah blah...

  <MTEntryCategories>

     Recent entries in <MTCategoryLabel>:
     <MTEntries> <MTEntryTitle> </MTEntries>

  </MTEntryCategories>
</MTEntries>

which gets you something like:
CODE
<h1>Uncategorized #1</h1>
 blah blah blah...
 
 <h1>Uncategorized #2</h1>
 blah blah blah...
 
 <h1>Woozle #1</h1>
 blah blah blah...
 
    Recent entries in Woozle:
    Uncategorized #1
    Uncategorized #2
    Woozle #1
    Uncategorized #3
 
 <h1>Uncategorized #3</h1>
 blah blah blah...

The inner MTEntries is in both an entries and a category context, and the entries context takes precedence, counter to aaber's intent.
girlie
That's what I'm saying: I don't believe this is a bug, I think that's how it's supposed to work (or supposed to not work, depending on how you want to approach it). He wanted to know "WHY doesn't MTEntries show entries as it must in this example". Well - who says it "must"?

The documentation says "you can use MTCategory* tags to display information about the categories" - it doesn't mention entries.

On the other hand, regarding MTCategories, the documentation states:

QUOTE
A container tag representing a list of the categories in your weblog. For each category, you can use any of the tag variables below; in addition, you can use an <MTEntries> tag to display information about each of the entries in this category.


So - MTEntryCategories and MTCategories do not behave the same way. And therefore, I think we are at most looking at a feature request, not a bug, unless both the programming and the documentation are incorrect. wink.gif
markpasc
aaber did something that was fairly reasonable, was possible, and didn't work as e expected, so it's arguably a bug. smile.gif I agree it's waaay over in the bug-feature grey area though.
girlie
bug /n./
An error in a program or a malfunction in a program's code.

CODE
sub _hdlr_entry_categories {
   my($ctx, $args, $cond) = @_;
   my $e = $ctx->stash('entry')
       or return $ctx->_no_entry_error('MTEntryCategories');
   my $cats = $e->categories;
   return '' unless $cats && @$cats;
   my $builder = $ctx->stash('builder');
   my $tokens = $ctx->stash('tokens');
   my @res;
   for my $cat (@$cats) {
       local $ctx->{__stash}->{category} = $cat;
       defined(my $out = $builder->build($ctx, $tokens, $cond))
           or return $ctx->error( $builder->errstr );
       push @res, $out;
   }
   my $sep = $args->{glue} || '';
   join $sep, @res;
}


As far as I can tell with my limited Perl knowledge, there's no error, no malfunction, just one user's desire that it be coded to work in another way. wink.gif
markpasc
At the risk of continuing this very meta debate... wink.gif It didn't work as aaber reasonably expected from the documentation, which I would call a malfunction.

Whether it's a bug is really the question, "Does the author intend for it to work like the user expected (yes, a bug) or like it does (no, not a bug)?" My personal guess would be at the time of writing he didn't intend it to work either way, because he didn't consider people using it quite like that—so, presented with the idea, what is the author's intent? Personally, I'm in agreement with aaber that the inner MTEntries should honor the category context, so I'd call it a bug.

However, it would be a very difficult thing to actually fix, so out of enlightened self-interest one might say it's merely an unintended consequence and avoid using that three-letter b-word. smile.gif
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
Invision Power Board © 2001-2008 Invision Power Services, Inc.