Ah, I see - like a decorator.
On Jul 13, 2011, at 5:56 PM, Chris Bartlett wrote: > On 14 July 2011 04:32, Greg Brown <gk_br...@verizon.net> wrote: >>> It just seems cleaner to prepare the data first, and then let >>> ImageView simply show whatever it has been given. Much the same as >>> when populating a ListView, TableView or TreeView for example. >> >> The difference is that the renderer would be modifying the data, rather than >> the application. That isn't good. > > No, I am not suggesting the renderer do anything other than render, > and certainly not modify any data. In fact the renderer wouldn't even > know that the 'clipped' image was in any way different to any other > image. For that matter, neither would ImageView or anything else that > uses Images, as it is none of their concern where the data originally > came from, or comes from now. They just need to know how to deal with > it once they are given it. > > Continuing the comparison with ListView - I can use a base > List<Widget> as the 'listData' for one ListView, and then create a 2nd > List<Widget> (which is backed by the other list) and use as the > 'listData' for another ListView. (The old FilteredList class would be > a perfect example of one list backed by another) > > Similarly, offsets & clip bounds would be handled by a lightweight > Image (the equivalient of the FilteredList above). That Image would > be backed by the 'source image' and just would paint the relevant part > of that source image when its own paint method was called. > > It could be considered similar to how the consumer of a > java.io.InputStream just deals with the data it receives, without > knowledge of any processing that may have occurred beforehand and > transformed the data in some way. > > Image = java.io.InputStream > ClippedImage = java.io.FilterInputStream
