Overriding pkContextCMS->executeTabs()

[Spike B]

Hi there,

I'm modifying the behavior of the navigation tabs so that the user can
select the nav area in which the tab appears (Main, Footer, Utilities,
etc.), and so I need to modify the executeTabs() method to filter out
any tabs from $this->tabs which do not match the specified nav area.

I first tried dropping in a file:
/apps/frontend/lib/pkContextCMSComponents.class.php

as follows:

<?php
class pkContextCMSComponents extends BasepkContextCMSComponents
{
public function executeTabs(sfRequest $request)
{
parent::executeTabs($request);
sfContext::getInstance()->getLogger()->info
('------------------------------------------------------------ test
tabs');

$tabs = array();

foreach ($this->tabs as $tab)
{
$page = pkContextCMSPageTable::retrieveBySlug($tab['slug']);
if ($page->getNavarea() == 'Main')
{
$tabs[] = $tab;
}
}

$this->tabs = $tabs;

}
}
?>

made sure to 'chmod 0775' the file and 'symfony cc'. No dice, the
file is not being executed. Thinking it may be due to the file/class
naming, I even tried renaming the file to:
/apps/frontend/lib/BasepkContextCMSComponents.class.php

and the class name to:
class BasepkContextCMSComponents extends
pkContextCMSBaseComponents

thinking that this file would take precedence over the one in:
/plugins/pkContextCMSPlugin/modules/pkContextCMS/lib/
BasepkContextCMSComponents.class.php

but again, no dice.

Am I missing some key concept here?

Thanks!
Spike B

[Spike B]

Oh man, yes definitely missing a key concept! All the CMS magic made
me forget that it's just a normal component.

I just renamed the file to
/apps/frontend/modules/pkContextCMS/actions/components.class.php

And it the file is called. The tabs don't display yet but still.

Spike

[Spike B]

Here's the new usage of the tabs in my layout.php file:

<?php include_component('pkContextCMS', 'tabs',
array('navarea' => 'Footer', 'hard_links' => array(
array(
'title' => 'Home',
'slug' => '/',
'attributes' => null
),
array(
'title' => 'My Account',
'slug' => '/account',
'attributes' => null
),
array(
'title' => 'Partner Login',
'slug' => 'http://partner.example.com',
'attributes' => 'target="_new"
rel="nofollow"'
)
))) ?>
<?php endif; ?>

Couple things here. First, with the 'navarea' variable, the
executeTabs() component action filters out all pages without a
matching $page->getNavarea() parameter. this is handy because it
means pages can exist in multiple navigation areas (footer, main,
etc.). Drag'n'drop reordering isn't working though, I'll be looking
into that. I have a hunch that it may be smarter to use the
pkContextCMSNavigation class; this is something i'll be looking into.

Second, I added a hard_links variable to the component invocation,
because for the footer and utilities navigation links it is useful to
have links to non-CMS pages. I may revise this in the future,
hopefully to take advantage of the DnD reordering. Wondering out
loud, perhaps I may have to do something sort of hackish i.e. making
these non-CMS links point to fake/empty CMS pages if I want the
reordering to work.

[Tom Boutell]

pkContextCMSNavigation is indeed the newfangled way to build
navigation, although we haven't added drag and drop support to it yet.
Keep in mind that the "reorganize" tool is always available as well.

pkContextCMSNavigation can be used to add navigation to any part of
the page, based on a variety of navigation styles - trees, accordions,
tabs (children of the home page), breadcrumb to the current page,
children of the current page...

If you want more, you should also check out the getChildrenInfo(),
getTreeInfo(), etc. methods of the page object, which are the low
level interface that pkContextCMSNavigation relies upon to obtain
information about related pages very efficiently.

> --
> You received this message because you are subscribed to the Google Groups "pkcontextcms" group.
> To post to this group, send email to pkcont...@googlegroups.com.
> To unsubscribe from this group, send email to pkcontextcms...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/pkcontextcms?hl=en.
>
>
>
>

--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com

[Spike B]

Also, a strange bug I was getting as consequence of dropping in a
components.class.php file in:
/apps/frontend/modules/pkContextCMS/actions/components.class.php

Now the following line from:
/plugins/pkContextCMSPlugin/modules/pkContextCMS/templates/
_ajaxUpdateSuccess.php

<?php pk_context_cms_slot_body($name, $type, $permid,
$options, $validationData, $editorOpen) ?>

was causing a PHP Fatal Error, could not find
BasepkContextCMSComponents class. To fix this, I just copied:
/plugins/pkContextCMSPlugin/modules/pkContextCMS/lib/
BasepkContextCMSComponents.class.php

to:
/apps/frontend/lib/BasepkContextCMSComponents.class.php

Hope that helps anyone who tries to replicate this.

Cheers
Spike

[Tom Boutell]

Hi Spike,

If you take a look at the components.class.php that you copied, you'll
find there is a require statement to locate the base class. Copying
the base class is not a good idea because you will not get the benefit
of any bug fixes or improvements made. The right solution is to fix
the require statement to point to the right location.

This ought to do it (off the top of my head):

require_once(sfConfig::get('sf_root_dir') .
'/plugins/pkContextCMSPlugin/modules/pkContextCMS/lib/BasepkContextCMSComponents.class.php');

Unfortunately the Symfony autoloader does not search for classes in
lib folders within module folders on its own.

(As I explain this, I must admit find myself wondering why plugin
authors don't simply put the base classes in a subfolder of
plugins/pluginNamePlugin/lib, which *would* be found by the
autoloader. Perhaps I'm following a convention that doesn't deserve to
live. (: )

[Spike B]

Ah, yes, thanks Tom!

Spike

> > For more options, visit this group athttp://groups.google.com/group/pkcontextcms?hl=en.