Randomland.net - Test Site Discussion

[zourtney]

Oh, so the source is totally broken at the moment. Sorry.

I've been spending my "free" time changing the code formatting to the Drupal standard (of as close as I care to make it comply). And I also added a ton of comments to the code. I'm going to post the phpDocs to randomland right now!

[zourtney]

Ok, it's up at http://test.randomland.net/docs/rlcore. The formatting sucks; big time. But all the text is there. Honestly, it'll be better just to look through the code itself.

Here are a few highlights (most of which is explained in the inline docs)

• rlcore.module defines the template files, help text, and the two content types (Image and Image Collection nodes)
• rlcore.install contains database table information and what to do when the module is enabled or disabled. Basically, it controls installing and uninstalling the content types and fields.
• rlcore.field.inc defines the ImageSelect field/widget which is a multiselect HTML box filled with Image and Image Collection node references. By selecting them, you'll associate an Image with whatever node this field is attached to.
• rlcore.filter.inc is the old rlimg module. It takes the text [rlimg] or [rlimg-block] and formats it based on template files in the module directory. We can use Drupal themes to override this.

There's probably more, so feel free to ask. I'm still a bit confused over the whole field/widget thing and how to implement it properly.

[zourtney]

I updated the module code a little bit. The image collection's multiselect field (unimaginatively dubbed "ImageSelect") now saves and deletes entries properly. This code can be seen in rlcore.field.processor.inc and is called from rlcore.field.inc.

It still has major issues; I would consider it unusable. Mostly because your previous selection is not highlighted when you go back to edit the field. I'll get to that next. But, if anyone's interested in seeing some simple field loading/saving guts, it's in there.

[Nick]

Sounds like progress. I am interested to see how all that works. I will do my best to take a look at some source tonight. It'll do me good.

[zourtney]

The Drupal standard is surprisingly NOT object oriented. So it feels very C-like to me (which I don't really like). At any rate, feel free to bug me about it. I'll gladly explain the code in any form of (non violent) communication you can muster.

[zourtney]

So....I have a UI design question I need to work out before I work on my Drupaler thing any more...that is, if anyone still finds it worthy of being created. If not, just let me know. There are plenty of another projects I can play with instead.

But, if I should continue to work on this, the question is:
How should the user select photos to add to a collection?

Drupal gives you the ability to dynamically add multiple instances of the current field. In the picture below, I created a dummy content type, added a single field of type "Decimal", then edited the "Number of Fields" to "unlimited." These fields are rearrangeable using the stock Drupal UI. No fancy needed.
I could use this same approach with a widget that lets you select a single image. And let the user add as many as they want, shuffle them around as they want, etc. But is this good enough for our purposes?

I was going to make a full-blown, complicated AJAXy widget which would let you do all this. But is there a need to? If you (anyone) has the time, try creating a dummy node that has some field with unlimited cardinality (I believe that's the terminology used in the code). If having multiple instances of a field which lets you select a single, existing image seems good enough, I'll go that route.

What say ye? (If I lost you, I'd gladly try to clarify.)

[Nick]

Whats this for? Uploading or adding to galleries? If its for uploading then it will work for small numbers of images. If its for creating galleries why not just use taxonomy to assign them to a gallery? Or is the point that you can sort the display order. If thats the only way to change then display order then OK. But it would be nice to be able to do both; Have images assigned to a gallery via a taxonomy term type tag, or to swap around the boxes. One might have to make a script that goes through and takes all the images with a gallery name tag and apply them to that gallery node.

Or am I missing the point?

[zourtney]

Well, I suppose the purpose was twofold:
1) I'm not sure what we want
2) I don't know what I'm doing

That said, perhaps I was thinking about this backwards. I was trying to store image references in collection nodes. If we instead slap a "collections" taxonomy on Image nodes, we've simplified it greatly. Perhaps we don't even need an Image Collection content type?

My reason for wanting it a content type was so we could associate author, date, etc with the group of images. If this isn't wanted, then everything is simpler.

[Nick]

It might be better to associate an author node (or user profile) with the images. Then we could just have the field for telling the images what gallery they are in. I think it would still be nice to have a node (or fake node that's just a canned search) for displaying the associated images in a nice formatted manner.

What are your thoughts?

[zourtney]

Actually, now that I think about it, I think my primary reasoning was that you would want to slap a description on the collection. Perhaps this is presumptuous. Of course, along with every node comes the author, date, and access-level data. Which may or may not be of any use on collections.

Or we could just use Flickr.

[Nick]

That's true... or we could use the flicker API to use the images/collection to drupal. But unless you have a paid flickr account, they impose all sorts of restrictions on you. Mostly about the amount you can upload. And I like the idea of us having our own little thing under our control.

I think we would want a description with collections. But I was thinking we could avoid the tediousness of adding images one by one. I don't know, as your doing (so far) all the work on it I think you should get to decide. I will just throw in my 42c.

If collection have images added to them then they are the masters of their own contents. Else images decide what collection(s) they belong to.
If images decide where they go you can assign a large number to a collection (or more then one collection) at a time (Like I want to add all these images to the collection 'nicks pics' and 'the beach' and 'summer 2012' all at once.
Or we could forget about collection as a node and just have an advanced search page that takes parameters. Then you just tag images and like-tagged images are all in the same collection.

You could still assign more information to the image either way. Like an author/owner to the image (beyond just who created the node. Have another Author node that has information about how who took it and if they do commercial work or something. ) And have some preset copyright license stings to add to image nodes so people know if they are available for free use or not.

There are (or were) things that would allow you to add descriptions to taxonomy terms. That could give you the description ability you were looking for. Just have to make a custom search page for displaying 'collection' terms that displays it with the images. Or below a thumbnail representing that collection.

Thoughts on that? Do I help, hinder or just confuse things more? Am I seeming to get what you are trying to say? I always worry that I am misunderstanding things.

[zourtney]

No, your input is quite helpful. Obviously, I haven't really thought this through. And now that you mention it, I stumbled upon the fact that you can add fields to taxonomy terms. I thought this strange at the time, but perhaps this is exactly what we're looking for(!)

(An hour later...)

Ok. So I've set up a manually created demo of how it can work with that setup. I really didn't DO much:

• Created vocabulary called Image Tags
• Created vocabulary called Image Collections
      Slapped a field rating on it, just to prove it can be done (it already has description)
• Created content type Image
      Added image upload field
      Added image tag and image collection fields as taxonomy term references
  

The image nodes work like I want. It's easy to slap on whatever collection comes to mind (just like tagging). AND! Better yet: Drupal can display the list of taxonomy terms oh-so-simply.

So, I think you nailed it. Your Drupal knowledge is far superior! I was intentionally avoiding the taxonomy because I thought it was not powerful enough -- boy was I wrong. The ignorance was not so bliss.

What do you think of this implementation? What does it lack?

[Nick]

Wow, I think you give me way too much credit. But thanks.

If we can make a nice way to display the images in a collection I think that will work just fine. Thats where I ran into problems before as we were lacking the views module. No way to display the images as a formatted table or get the RLimage tag onto them. I know there is a way to do it, I just don't know what it is.

[zourtney]

Ok. So, is that the basic setup of the current (6.x) setup? If that's all we're really looking for, plus a little formatting, I think we can do it..!

I'm still a proponent of creating these vocabularies, content types, and views programmatically. It allows us to quickly recreate the content schema, which is good for testing, site migration, etc. It's also redistributable -- as simple as it may be, we could probably still toss it up on Drupal's module section. Plus, I've already started (and I'm interested in learning the Drupal APIs).

I believe I could make the module programmatically create what's on the test site pretty easily. I can, then, drop the idea of custom fields...at least for the time being. If we want a slick UI for selecting images, we can work on that later (perhaps it'd be better as a utility page than a content type field anyway?).

Thoughts? Opinions? Rebuttals?

[Nick]

Sounds good. And if we start simple like that we can expand on it later if it does not seem to be providing everything we need.