33 replies to this topic

[Bill]

In a module it's not the same as in template level, in a module you use

wire("input")->urlSegment1;
$wire->input->urlSegment1;

So (as in the above), you're accessing the (object) "input" via the PW API, right?

And, in the code below, you're accessing it via the Wire (that this module is actually extending)

or $this

$this->input->urlSegment1;

And, since it's extending the Wire, obviously $this->input is all that's needed. (gotcha!)

Now, just for my information, is using one over the other preferred?
I'm assuming $this->input->....

Reason I'm asking is that if i use the wire() API in the future from outside of PW (typ. Wire API usage), will it totally "reflect" on my module better if it's incorporated using the wire("input") vs. the $this->input???

Just don't want to back myself into a corner is all .

[Soma]

I don't think there any over the other, at the end it is and does the same. Just a matter of preference.

[Bill]

@Soma - thanks for the tip, and guidance


@Ryan - what the 'oh my!' brain cell implant did you have to come up with such a ridiculously versatile system, Ryan. I mean really! I created plugins for WP, addons for a few others, and 'implementing' your modules (once i've now done it) is like a cakewalk... no FUNKY nomenclature, tricks, 'jam this into here...' and the ever-present 'oh yeah, you can't do that here so you have to hack your way in this way' stuff... period.

Just soup to nuts, awesome, using observer patterns, full reflection, and keeping everyone on the handrail using "implements" in modules you rawk Ryan! (... and obviously the community that supports ya! )

Thanks all again...

Maybe i'll post my two new modules... for anyone else who wants to use them. Just launch platforms is all - for making new/improved modules and sorts.

Edited by Bill, 22 March 2012 - 12:49 PM.

[Soma]

Thanks Bill you're welcome!

[ryan]

Thanks Bill, I think the main difference is just PHP5. There is a lot about PHP5 that really benefits the ability to build simpler plugin systems. WP and others are still built around a PHP4 idea of plugins, probably for legacy support reasons.

Reason I'm asking is that if i use the wire() API in the future from outside of PW (typ. Wire API usage), will it totally "reflect" on my module better if it's incorporated using the wire("input") vs. the $this->input???

It doesn't really matter much which you use. But here are a couple factors. I definitely like the readability of $this->apiVar better, but the truth is that using wire('apiVar') is more bulletproof. In order to use $this->apiVar, you have to be in a class that extends Wire, and you can't take control over the __get() method in the class. Or at least if you do, you have to make yours call parent::__get() when your class doesn't have a handler for a given variable. So if you are using wire() exclusively, you really don't have to worry about things when you override a __get() method. Also, wire() doesn't have to pass through any comparisons, as it's singular purpose, so technically a little more efficient. Lastly, wire() can be used in procedural functions, and in classes that don't extend Wire, making it portable for use anywhere in your site's code. Still, it may not feel right to rely on a procedural function to access API vars. But if you can get past that feeling, it actually makes a lot of sense to use it. It's kind of like PW's version of jQuery() or $(). Using wire() is newer syntax, and not something you could do in the original PW 2.0. So I haven't standardized on one or the other, and use both interchangeably, and PW will always support both. Also want to note that PW passes all the API vars to your template files, so you don't have to use wire() or $this, and instead you can just access them directly, like $pages.

[Bill]

Thanks for the very thorough explanation. Lovin' it.

[ryan]

Right this is with the debug already set to TRUE. It's like it churns, churns, etc... on my localhost and then stalls out... nothing, no unseen html either... the page source is blank. Only (i mean ONLY) when i do the find('template=cool-page') syntax.

I'm still wondering about this, since it sounds like its not working correctly here. What is the scale of pages in your site using the template 'cool-page' and what auto join fields does that template have? I'm just trying to find out as much info as possible to be able to reproduce it.

Just curious, why is it an abstract call to that method, and not directly... conversely, if i used it to only extend the PageArray and implement Module, then wouldn't it be a direct call?

Not sure I understand the question 100% so let me know if i don't answer it right. The class::method syntax when you add the hook is just a way of communicating to PW that you want to hook all current and future instances. Kind of like a jQuery live() event. This is consistent to how you'd usually refer to a class::method in documentation, outside of a specific instance. If you only wanted to hook one instance then the syntax would be $objectToHook->addHook('method', $myObject, 'myMethod'); and $myObject is most commonly $this.

[Bill]

I'm still wondering about this, since it sounds like its not working correctly here. What is the scale of pages in your site using the template 'cool-page' and what auto join fields does that template have? I'm just trying to find out as much info as possible to be able to reproduce it.

I only have about 100 pages (nothing to sneeze at...).

... This is consistent to how you'd usually refer to a class::method in documentation, outside of a specific instance. If you only wanted to hook one instance then the syntax would be $objectToHook->addHook('method', $myObject, 'myMethod'); and $myObject is most commonly $this.

Got it now. The "::" abstract call was throwing me off a bit was all.

Bill

[Bill]

Module :: HelperAttributes

<?php
/**
* ProcessWire 'HelperAttributes'  module
*
* Adds a getAttr() method to all PageArrays
*
* ProcessWire 2.x
* Copyright © 2012 by Bill Ortell
* (acknowledgements: Ryan Cramer)
* Licensed under GNU/GPL v2, see LICENSE.TXT
*
* http://www.processwire.com
*
*/
/**
* adapted from example thrown in by Ryan Cramer on this thread:
* http://processwire.com/talk/topic/1083-get-specific-page-attributesfields-from-pagearray-set/page__pid__9500#entry9500
*/
class HelperAttributes extends Wire implements Module {
static public function getModuleInfo() {
    return array(
		    'title' => 'Get Page Attributes',
		    'version' => 100,
		    'summary' => 'Adds "getAttr()" method - get any {one} attribute from all pages in PageArray',
		    'href' => 'http://processwire.com/talk/topic/1083-get-specific-page-attributesfields-from-pagearray-set/',
		    'singular' => true, 
		    'autoload' => true
	 );
}
public function init() {
  $this->addHook('PageArray::getAttr', $this, 'getAttr');
}
public function getAttr(HookEvent $event) {
  $pageArray = $event->object;
  $key = $event->arguments[0];
  $pageKeys = array();
  foreach ($pageArray as $page)
  {
   $pageKeys[] = $page->$key; // all pages have one! <img src='http://processwire.com/talk/public/style_emoticons/<#EMO_DIR#>/smile.png' class='bbc_emoticon' alt=':)' />
  }
  $event->return = $pageKeys;
}
}

The above was saved to a HelperAttributes.module and placed into my site/modules folder

IF ANYTHING - someone will find this helpful in starting their own module (possibly?)

Edited by Bill, 23 March 2012 - 08:30 AM.

[WillyC]

soma yo can no| $wire->zam in modulos o classos. wire('zam') must it.be

bill getAttr beauty i.use good,thanking

[Bill]

Thanks...
(high-five with all of you for helping me with it!)

[Soma]

Bill I still don't get what this would do any different than simply doing this:

$keys = explode("|", $pagearray);

Except that this module will load on every page load. Bear with me, as I'm maybe missing the obvious.

Dumb me, now I get it! It's not only about id's

[Bill]

I'm still wondering about this, since it sounds like its not working correctly here. What is the scale of pages in your site using the template 'cool-page' and what auto join fields does that template have? I'm just trying to find out as much info as possible to be able to reproduce it.

I think i know the issue... kinda wild tho - not sure if it's a buffering limit or what... as i'm on my localhost.. (shrug).
Its when I do var_dump of the 'children' objects, etc.. any time i seem/tend to dump that to the screen, then i'm seizing up the system, and it gives me the 'white-wall-of-doom!'

When i remove it, ir do the var_dump on anything else (obviously smaller than the children object array, etc...) it's all fine.

Bill

p.s. er so it seems

[ryan]

Bill, that actually makes sense. I've done a var_dump on pages before, and it basically becomes an infinite loop (or something close to it).