Accessing a variable upward in the scope in an object
Moderator: General Moderators
Re: Accessing a variable upward in the scope in an object
Yes, it's certainly similar. I'm using a backreference to the owner simply because each plugin object can *only* be used with the owner object. I even check that the plugin uses a specific interface when it's attached. I think Feyd's point in your thread about loose coupling is coming from the point of view that objects should be reusable ... if you closely tie them to an owner object they're not very reusable. In my case that isn't an issue.
Re: Accessing a variable upward in the scope in an object
xSpec frameworks have to maintain these types of references. In order to construct the phrases such as "$this->should(1)->equal(1);" the code is probably (I haven't looked, I'm transposing from SSpec as I type)
Code: Select all
class SpecContext {
public function should ($object) {
return new ShouldHelper($object);
}
}
class ShouldHelper {
private $target;
public function __construct ($target) {
$this->target = $target;
}
public function equal ($object) {
return new ShouldEqual($this->target, $object);
}
}Re: Accessing a variable upward in the scope in an object
Would it be possible to entirely reverse the dependency, so that each transformation object knows what image it's working on, but the original image doesn't have to know what transformation is performed on it?onion2k wrote:Well, it's not ready for public beta yet.. but this is the how the code works in practise now...
That opens a jpeg image, resizes it to 100*100 pixels, and outputs it to the browser. You can add as many attachments as you like.Code: Select all
$image =& new Image(IMAGE_BASE.DIRECTORY_SEPARATOR."drops.jpg"); $image->attach(new image_fx_resize(100,100)); header("Content-type: image/jpg"); $image->imageJpeg();
Code: Select all
$image =
new ImageResizeDecorator(
new Image("foo.jpg"),
100, 100);
header("Content-type: image/jpg");
$image->imageJpeg();
Re: Accessing a variable upward in the scope in an object
I'm sure it'd be possible, but what would be the advantage of it? The point of the system is that I want to be able to attach lots of plugins to an image. For example, I might attach a resize plugin, a crop plugin, and a black and white conversion plugin to an image. Doing it your way there'd be no logical way to know where to call imageJpeg() from ... any of the plugins would be equally appropriate.
Re: Accessing a variable upward in the scope in an object
It would have the motivations of the decorator pattern, or like piping transformations in unix: cat foo.jpg | blackwhite | resize 100 100. It turns a two-way dependency into a one-way dependency, it means that transformations don't have to know exactly what input they're working from (maybe it's an image from a file, maybe it's the output of a previous transformation), and it means that images don't have to know what transformations are applied to them.
I'm thinking about what might work for transformations of text streams, maybe it doesn't apply to transformations of image buffers.
I'm thinking about what might work for transformations of text streams, maybe it doesn't apply to transformations of image buffers.
Code: Select all
$image = new Image("foo.jpg");
$bwImage = new BlackAndWhiteImage($image);
$resizedBwImage = new ResizedImage($bwImage, 100, 100);
$image->imageJpeg(); // to output orig image
$bwImage->imageJpeg(); // to output bw image, orig size
$resizedBwImage->imageJpeg(); // to output bw image, new size
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
Re: Accessing a variable upward in the scope in an object
I think nice things about onion2k's design is that the filter processor can intelligently order and even remove added as needed. For example, if you attach two resize filters, it might make sense for the image to only use the last one. Likewise you might want to do some filters on the original, unresized image first, and then resize at the end -- even if the filters were not added in that order -- to maximize quality. (you might want to think of adding type or group information to the filters)
(#10850)
Re: Accessing a variable upward in the scope in an object
That's already in there.. type, subtype and version are all required.arborint wrote:(you might want to think of adding type or group information to the filters)
Re: Accessing a variable upward in the scope in an object
Are all of your plugins filters on the image content, or are you using the plugins for other reasons? Is it appropriate to talk about the plugins being applied in a sequence of say image file -> crop -> black and white -> resize -> display, or are there more complicated interactions between the plugins and their container? Even if the filters can be reordered, as arborint suggest, to remove redundant filters or reshuffle the information-losing filters to the end, the filters would still be applied in a sequence.
The thing is, when plugins are mentioned, I think of a component that extends an environment in some way and gets certain services from that environment, like plugging a usb device into your computer or plugging an electrical appliance into a socket. I can see that it's possible to turn an image upside down and double its size by starting with an image, plugging in a rotation filter of 180 degrees, and then plugging in a resizing filter of 200%, it just seems a bit forced. It seems more natural to think of chaining together filters and sending the image down the conveyor belt through those filters. Does that intuition not make sense, or is there some reason that the intuition doesn't apply to the image processing you're doing?
The thing is, when plugins are mentioned, I think of a component that extends an environment in some way and gets certain services from that environment, like plugging a usb device into your computer or plugging an electrical appliance into a socket. I can see that it's possible to turn an image upside down and double its size by starting with an image, plugging in a rotation filter of 180 degrees, and then plugging in a resizing filter of 200%, it just seems a bit forced. It seems more natural to think of chaining together filters and sending the image down the conveyor belt through those filters. Does that intuition not make sense, or is there some reason that the intuition doesn't apply to the image processing you're doing?
Re: Accessing a variable upward in the scope in an object
There are other reasons to use plugins. For example, I've created an analyser plugin that calculates things like the average hue of the image, and the brightness, etc. Other plugins still in the planning stages are things like complex area calculation to detect where the points of interest are in an image in order to feed through to a cropping plugin to remove borders and boring image content. Plugins will need to talk to one another.dml wrote:Are all of your plugins filters on the image content, or are you using the plugins for other reasons?
Generally plugins will be applied as a linear sequence of actions, but there may be reasons to revisit plugins after they've run, or skip them, or dynamically order them ... that's a long way down the road though.dml wrote:Is it appropriate to talk about the plugins being applied in a sequence of say image file -> crop -> black and white -> resize -> display, or are there more complicated interactions between the plugins and their container? Even if the filters can be reordered, as arborint suggest, to remove redundant filters or reshuffle the information-losing filters to the end, the filters would still be applied in a sequence.
There's no reason why the approach you're describing wouldn't work, it's just not the way I work. I approach image development from a "photoshop actions" point of view rather than a "unix piped commands" point of view.dml wrote:The thing is, when plugins are mentioned, I think of a component that extends an environment in some way and gets certain services from that environment, like plugging a usb device into your computer or plugging an electrical appliance into a socket. I can see that it's possible to turn an image upside down and double its size by starting with an image, plugging in a rotation filter of 180 degrees, and then plugging in a resizing filter of 200%, it just seems a bit forced. It seems more natural to think of chaining together filters and sending the image down the conveyor belt through those filters. Does that intuition not make sense, or is there some reason that the intuition doesn't apply to the image processing you're doing?
Re: Accessing a variable upward in the scope in an object
It's coming along quite nicely now..
Code: Select all
$image = new Image(IMAGE_BASE.DIRECTORY_SEPARATOR."drops.jpg");
$image->attach(new image_fx_resize(250));
$image->attach(new image_fx_crop(166));
$image->attach(new image_fx_corners(15,15));
$image->attach(new image_draw_border(5, "FF0000"));
$image->attach(new image_fx_corners(17,17));
$image->attach(new image_draw_border(5, "FF8888"));
$image->attach(new image_fx_corners(20,20));
$image->attach(new image_draw_border(5, "FFCCCC"));
$image->attach(new image_fx_corners(22,22));
$image->imagePng();
- Attachments
-
- Thumbnail...
- test.png (64.29 KiB) Viewed 1546 times
-
- Source image...
- drops.jpg (49.97 KiB) Viewed 1546 times
Re: Accessing a variable upward in the scope in an object
Thanks to the guys in the forum here is the result of other crop resize & watermarking:
..but this will work only on images with same destination dimensions as the transperant watermark (the border)
source:

result:

..but this will work only on images with same destination dimensions as the transperant watermark (the border)
source:

result:
