Page 4 of 5

Posted: Wed Aug 23, 2006 4:09 pm
by Ollie Saunders
Plugins adhere to an API which gives them access to components in the pluggable system, and also allows the pluggable system to trigger calls in the plugins.
At the risk of hijacking your thread could you show a simple example of this please.

Posted: Wed Aug 23, 2006 4:40 pm
by Chris Corbyn
ole wrote:
Plugins adhere to an API which gives them access to components in the pluggable system, and also allows the pluggable system to trigger calls in the plugins.
At the risk of hijacking your thread could you show a simple example of this please.
You could look at my Swift source code but in pseudo terms it's like an observer-come-decorator with two-way coupling.

Code: Select all

<?php

interface PluginAPI
{
    public function loadPluggable(APluggable $pluggable);
    public function onSomeEvent();
}

class APlugin implements PluginAPI
{
    protected $pluggable;
    
    public function loadPluggable(APluggable $pluggable)
    {
        $this->pluggable = $pluggable;
    }

    public function onSomeEvent()
    {
        $this->pluggable->phrase = '<span style="size: 4em;">'.$this->pluggable->phrase.'</span>';
    }
}

class APluggable
{
    protected $pluginCollection = array();
    //Certain items in our API either need to be public, or have accessors
    public $phrase;
    
    public function loadPlugin(PluginAPI $plugin, $name)
    {
        $this->pluginCollection[$name] = $plugin;
        $plugin->loadPluggable($this);
    }

    public function runEvent($event)
    {
        $event = 'on'.ucfirst($event);
        foreach ($this->pluginCollection as $plugin)
        {
            $plugin->$event();
        }
    }

    public function speak($phrase)
    {
        $this->phrase = $phrase;
        $this->runEvent('SomeEvent');
        echo $this->phrase;
    }
}

$speaker = new APlugabble();

$speaker->loadPlugin(new APlugin());

$speaker->speak("Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Nullam fringilla.");

//4x size of text prints out!! (I said speak, not SHOUT!) 

?>
Obvsiously, you'd have a much bigger number of triggers than that.

Posted: Wed Aug 23, 2006 4:50 pm
by Ollie Saunders
Thanks d11wtq that was great. I think I may have to credit you for this at some point in my project. Next time you are near london let me know and I'll buy you a beer.

Posted: Wed Aug 23, 2006 7:10 pm
by alex.barylski
Just curious...

You name the class HttpRquest, but I've noticed many references to $_COOKIE, $_GET & $_POST

Why not just use $_REQUEST?

Do you plan on having the class distinguish between the different incoming data?

I can't see a reason why that information would ever be useful??? :)

Posted: Wed Aug 23, 2006 7:15 pm
by sweatje
Hockey wrote: I can't see a reason why that information would ever be useful??? :)
What about a method which compares for identical keys between them and tries to see of someone is trying to hack your site by injecting information where it is unexpected. McGruff always talked about his request object searching for "alien" keys, including from the wrong input source.

Posted: Wed Aug 23, 2006 7:24 pm
by alex.barylski
sweatje wrote:
Hockey wrote: I can't see a reason why that information would ever be useful??? :)
What about a method which compares for identical keys between them and tries to see of someone is trying to hack your site by injecting information where it is unexpected. McGruff always talked about his request object searching for "alien" keys, including from the wrong input source.
How did I know someone would bring that up... :P

Fare enough, but my point is...it's over kill...people can spoof data no matter where it comes from GET, POST, COOKIE...So what difference does it make???

It's an extra step of un-essential processing, further slowing down my code for what? You couldn't use it as a replacement for actual data sanitization...

If anything, you could use it as logged data to indicate whether you had script kiddies trying to hack using GET instead of POST because they didn't have the know how to download a simple application which would let them carry out POST or COOKIE injection as well...

The only usefulness I see in it, is if you had a COOKIE with the same name as your POST, in which case, I'm not sure of the results...

In this case, I would argue that's bad convention and should be avoided anyways...

2 variables, same declaration and same namespace (super globals) = bad idea IMHO :P

Cheers :)

Posted: Wed Aug 23, 2006 7:49 pm
by Chris Corbyn
It makes for more readable code if you explicitly declare where the data comes from. End of :)

Posted: Thu Aug 24, 2006 2:50 am
by Jenk
same as above, but also we are doing this completely from start to end of process - the goal is to get a class that works and is proven by TDD, we'll worry about the little extras after :)

Perhaps when we have finished, this thread can be tidied up and submitted as a tutorial on UnitTest's and TDD? :)

btw - yes, cookie is also affected by magic quotes.. GPC = Get Post Cookie :)

Posted: Thu Aug 24, 2006 6:02 pm
by Jenk
Right, now we are satisfied it can accept, retrieve and clean GPC data... what now? :)

Should this object be able to retrieve from all 3 superglobals, or should the developer create 3 instances?

Posted: Thu Aug 24, 2006 6:07 pm
by Luke
I kind of want it to have different instance for each... maybe we can have it support both?

Posted: Thu Aug 24, 2006 6:40 pm
by Chris Corbyn
3 instances make sense. They are 3 requests... ermm... cookie is a weird one. If cookie's in there session almost deserves to be in there. Meh.

Posted: Thu Aug 24, 2006 6:42 pm
by Luke
yea, but we don't really want session in there. Do we even want cookie in there?

Posted: Thu Aug 24, 2006 6:44 pm
by Jenk
cookie is most definately part of HTTP request.. just think where it comes from, where as session does not :)

Posted: Thu Aug 24, 2006 6:46 pm
by Luke
that's true... but part of session comes from the user too (the id)

Posted: Thu Aug 24, 2006 7:04 pm
by Jenk
Which comes from.. Get, Post or Cookie :)