Custom Image Module

[morsecodemedia]

Hello, 

My Goal: 

• To create a custom module that will take an array of images and generate a sprite sheet, as well as, the CSS to access each sprite. (This part I have completed  ).
• To have it be a custom InputType, so that every image field does not create a sprite sheet. (Still needs to be completed).
• To create an admin page for the module to allow you to customize the output, size, etc. (Still needs to be completed).

My Problems:

• Currently, it is looking at a specific folder that is hardcoded in the module, and creating a sprite sheet from those images. I suspect that creating a custom InputType would allow me to have the folder dynamically set based on the page that is using the module. I am struggling on finding the proper documentation that would allow me to do that.
• I also, have created a "Create Sprite Sheet" button and have it hooked after the page save button... on every page, even if there isn't an image upload on that page  .
  • I would like the create sprite sheet functionality to be hooked to the actual page save button only on the pages that have the custom InputType that needs to be created - mentioned above.

I'd appreciate any help/direction provided, to help me achieve my goals. Also, if anyone has any recommended features that they think would be helpful as a part of this module, please feel free to make suggestions.

Thanks in advance.

[LostKobrakai]

I've some notes for you:

• This should basically be a own fieldtype, not only an inputfield. The fieldtype would obviously extend the image fieldtype, but this is not a standart image field anymore, with just some custom "frontend" (a.k.a. inputfield). 
• The configuration part should most likely not be a admin page, but part of the field's configuration. 
• The images in an image field already have dedicated folders and you can simply get their paths like this:

foreach($page->images as $img){
  echo $img->path;
}

• The button won't know if there's a image field on a page by looking into a crystal ball. You'd need to check that for yourself (check the current page) and only add it, where you want the button to appear.
• To have the generation be started automatically you'd add this to the fieldtype's sleepValue() function, which is essentially the save-to-db function for each fieldtype. That should be the place to initialize an update of the sprite file.

[Craig]

Is there a specific reason you want this to be managed using a button on the field itself?

If I was doing this, I'd look at creating a module that just added a hook method (like 'generateSprite()' or something), to the Pageimage class, maybe, which exposes a function to return the generated sprite image URL and CSS content for a given images field. There would be a cache table behind this which saves the generated status and metadata/CSS to prevent processing the images on every request (this would have to be invalidated whenever the images changed). Using this method, there is complete freedom to do all of this from the API. You can still have a configuration page, but the downside of this is that it would be less customisable per field instance in the templates.

For example:

$sprite = $page->images->generateSprite();

$sprite could be an array of generated CSS and/or path to the image for you to use in the template/code however you like.

I think the main consideration in approaching this, is how (and why) you want the sprites to be made.

[morsecodemedia]

I've some notes for you:

• This should basically be a own fieldtype, not only an inputfield. The fieldtype would obviously extend the image fieldtype, but this is not a standart image field anymore, with just some custom "frontend" (a.k.a. inputfield).

Thank you for clarifying that for me. After reading your response I found a post from 2011, talking about extending the image field and Ryan provided some code the explain how to do that ( reinforcing what you have said ).

For anyone who is looking to do something similar the article can be found here.

[morsecodemedia]

Is there a specific reason you want this to be managed using a button on the field itself?

If I was doing this, I'd look at creating a module that just added a hook method (like 'generateSprite()' or something), to the Pageimage class, maybe, which exposes a function to return the generated sprite image URL and CSS content for a given images field. There would be a cache table behind this which saves the generated status and metadata/CSS to prevent processing the images on every request (this would have to be invalidated whenever the images changed). Using this method, there is complete freedom to do all of this from the API. You can still have a configuration page, but the downside of this is that it would be less customisable per field instance in the templates.

For example:

$sprite = $page->images->generateSprite();

$sprite could be an array of generated CSS and/or path to the image for you to use in the template/code however you like.

I think the main consideration in approaching this, is how (and why) you want the sprites to be made.

Thanks Craig for your response. 

I actually don't want it to managed by a button on the field itself, that is just the functionality it has now, because it was the easiest and first thing I figured out how to do. I do have a method called generateSprite() that does most of that, except it's hooked into the wrong thing and isn't taking advance of the API as you mentioned above.

As for the configurations, it's more so users can determine the size of images, output location, nomenclature for the CSS that is outputted, etc.

And I agree with you about considering how and why I want sprites to be made. I can assume that a large percentage of the time, users will probably not need/want this module to create sprite sheets for normal layout purposes.

How this module came to be is that I am working on a site where the client wants a slider of images that build a collage. The slider has grid-like slides, where each slide is a 5x3 grid made up of 15 images. The images represent employees that work for that company. If there were 15 employees contributing a minimum of 5 photos each, that would be 75 images, or more importantly, 75 HTTP requests, just to build a 5 slide carousel. If the company and/or the amount of images per employee grew, so would the HTTP requests. So it made sense to me to take all those images and create a sprite sheet and which I can then just use one image to build out the carousel instead of 75.