Martin Atkins (mart) wrote in fotobilder,
Martin Atkins
mart
fotobilder

Difference in Vision

Brad and I seem to be thinking about things a little differently when it comes to the use of S2 on FotoBilder. There are a lot of things he seems to want which I didn't consider and vice-versa. One of these which I can pin down is a difference of opinion about the point of separation between stuff that's set by settings and stuff that's set by styles.

When I was designing the core1.s2 I sent to Brad, I was thinking along the lines of "make styles flexible so that users can easily change settings for specific galleries and pictures via metadata. The layout of Brad's code seems to suggest that he's more going for things like the size of thumbnails, number of thumbnails per line and so forth being set in the style.

I think it's important that anyone should be able to take one of the stock styles (or, indeed, design their own single layout) and be able to apply it to many situations where the size of thumbnails can vary and the number of thumbnails displayed on a single line can vary, to name only a couple.

My design employed a set of predefined "Picture Views", which are forms of a single picture. At this time, the only "alternate form" available for most pictures is a different-sized version, but a Picture View could pretty much be any kind of modification permitted. The predefined ones were an array of thumbnails and a single "full picture". The array of thumbnails would be set up for the gallery and certain styles would be made to expect different amounts of thumbnails but, ideally, still be able to cope with the minimum of one thumbnail. The "full picture" would obviously be the full-sized version of the picture.

Brad's design also has Picture Views, but they are represented by the Image class and aren't such a specific concept. These are obtained by the style by calling a method of the Picture class to get a thumbnail of a given size which it can then use in output. This gives loads of flexibility, but it means that a given style will always display a thumbnail gallery in the same way, regardless of the particular requirements of a given gallery which would need to use a different style to compensate.


I propose a compromise. My 'array of thumbnails' was not a good design now that I consider it more. Instead, I suggest that there only be two predefined PictureView objects, the first representing the gallery's idea of a "default thumbnail" (which is part of the gallery metadata, perhaps) and the second representing the full picture as I had before. This alone would hamper flexibility, so here's the interesting part…

A builtin method can be added to the PictureView class which takes $this and performs some modification on it. At this time, the modification can only be more resizing, but in future it could also be cropping, changing gamma, reducing to greyscale, or other interesting thing. This would be represented, for simplicity, by an operation string and a "parameters" string, so that only one version of this function needs to be defined in the core layer. This function will then perform some magic on the URL it's the PictureView object already has to add the new settings to it, cancelling out other settings were it makes sense or has to be done (which will be documented, of course).

The result is that, for example, a particular style can take the "default thumbnail" it's given and use it as a template to produce a greyscale thumbnail of the same size, without it needing to only support a given size or even be aware of what that size is in many cases. This also means that if a particular image is set to have its thumbnail generated by a cropped version of the image resized, the extra greyscale operation can be piled on top without it needing to be aware of the elsewhere-defined crop zone. (Crop zones are obviously image-specific, so definitely don't want to be set by styles)

I'd be interested in people's thoughts on this solution, as well as any modifications to it which might be a good idea, or better plans to replace this one. (but only if they're equally or more flexible! ;))

Subscribe

  • 302: lj_dev

    In the interests of consolidating all FotoBilder development-related discussion, we're going to be closing down this community. The same…

  • Development stalled?

    Is the development of Fotobilder held? Stalled? I am asking because there is no activity on the community and there is no link to the Fotobilder…

  • (no subject)

    Does FotoBilder works with Apache2? I installed all the required modules on my debian sarge, and when I restart my apache server, it dies horribly…

  • Post a new comment

    Error

    Comments allowed for members only

    Anonymous comments are disabled in this journal

    default userpic
  • 15 comments

  • 302: lj_dev

    In the interests of consolidating all FotoBilder development-related discussion, we're going to be closing down this community. The same…

  • Development stalled?

    Is the development of Fotobilder held? Stalled? I am asking because there is no activity on the community and there is no link to the Fotobilder…

  • (no subject)

    Does FotoBilder works with Apache2? I installed all the required modules on my debian sarge, and when I restart my apache server, it dies horribly…