David Crossley wrote:
Tim Williams wrote:
Thanks David,
That patch appears to expand the image handling capabilities -- which
is cool -- but what I'm wanting is simply to write the image variants
to disk. I've pretty much got it working but since it's a pretty huge
change I want to make sure it's cool with everyone first. Right now,
each variant (small, preview, and big) is created in it's own
directory manually by the forrest user. What I want is to just be
able to drag a bunch of my photo directories into the gallery and have
those variants generated by Cocoon automatically -- when I implemented
it I also made the change of being filename-based instead of directory
based. This works fairly well though as you might imagine the first
time through it's still memory intensive too.
I also eventually want to make an additional change in behavior. The
gallery\ directory will be seen as the root gallery. Any subdirectory
of that one can have a gallery.meta file that describes the gallery
and also may contain sub-galleries itself.
I for one, am very happy that you make those changes.
This would certainly change that plugin's version number
since it is different behaviour.
+1
So this would require adding the cocoon-imagereader-block
to Forrest. Are you happy with doing Forrest's Cocoon
upgrade process? I will do it if you are not comfortable.
Do not add the block to Cocoon. Add it to the rel;vant jars to the
plugin lib - no need to rebuild Forrests Cocoon.
(caveat: this only works if there are no xconf changes in the block,
although it should be possible to make the plugin system work even in
this instance - we'd need to discuss how, I've tried a few methods in
the past)
Ross
