Images are 1st class citizens of TXP

Bloke · 2010-01-29 13:38:12

wet wrote:

I beg to differ

Of course, you’re right. I forgot that it left $atts intact and just extracted the contents.

^{Note to self: shut up}

jsoo · 2010-01-29 13:41:31

Bloke wrote:

If I put 2, 3, 4 in my article_image field I get nothing from the <txp:article_image /> tag :-s

Ha — I’m full of it. article_image first does an is_numeric check, so you’re right.

the_ghost · 2010-01-29 18:12:39

You can, in fact, get at the uncategorized images already like this: category=”,” (show all uncategorized images) or category=“cat1, cat2,” (show cat1, cat2, and all uncategorized images)

Using category="," to output images without category looks very strange and unexpected… And what about category="*" to output images from all categories?

mrdale · 2010-01-29 19:14:54

…missed this one, stef. Been after this in core for literally years. You’re the dogs bollocks.

Last edited by mrdale (2010-01-29 19:18:36)

Bloke · 2010-01-29 21:52:43

the_ghost wrote:

Using category="," to output images without category looks very strange and unexpected

I agree. It’s just a way to do it — it’s not an officially supported mechanism and I didn’t expressly make it that way, I just noticed it by mistake as I was testing the feature. In fact, this trick will work in <txp:file_download_list> and <txp:linklist> too.

Next question then is what would make sense? Before I stumbled upon the cheat, I had started building support for a special option TXP_UNCATEGORIZED. That itself was a trick — all I made the code do was replace TXP_UNCATEGORIZED with an empty string, thus category="TXP_UNCATEGORIZED, cat1, cat2" internally became category=", cat1, cat2" (i.e. the same as if you’d omitted it yourself).

what about category="*" to output images from all categories?

Again, I considered this but it kinda goes against the meaning of ‘*’. An asterisk in the id attribute works because all images have an ID. But in a category (and name) the value itself may be empty. Thus some people would expect category="*" to output all cats (including unassigned ones) and other people might expect it to select all except uncategorized ones. The former case is redundant because id="*" covers all images. I’m not comfortable with the latter case unless someone can convince me its meaning won’t be confusing.

mrdale

Nice of you to stumble in from the cold. Glad I could finally do something that’s been on your wish list. Figured it was about time upm_image was essentially distilled and made a core feature because a) it’s a stock component of most people’s arsenal, b) the inconsistency between treatment of files, links and images annoyed the tits off me :-)

jsoo · 2010-01-30 19:56:50

Rick has an interesting point (and patch) on the txp-dev list about selecting images with multiple attributes in image_list, namely, that an AND (conjunctive) search should be an option as well as an OR (disjunctive) search.

I agree that one is unlikely to want to select images by, say, category="foo" has_thumb="1" with a disjunctive search. AND is much more useful for this combination.

Generally I would expect an OR search within an attribute, e.g. category="foo,bar" means category='foo' OR category='bar'. But across attributes, I generally expect an AND search. For example, category="foo" author="joe" means category='foo' AND author='joe'. It’s how doArticles() works. Getting even more complex, I would expect category="foo,bar" author="joe,jane" to give (category='foo' OR category='bar') AND (author='joe' OR author='jane').

id and name are an exception. It is pretty much pointless to be able to search for, say, id='2' AND name='foo'. But then I doubt I’d ever need to search by both id and name even disjunctively.

Tangentially, above I used author in an example. This would be a useful attribute for this tag. Also ext, search by file extension.

maniqui · 2010-01-30 20:12:59

jsoo wrote:

(…) I generally expect an AND search. For example, category=“foo” author=“joe” means category=‘foo’ AND author=‘joe’. It’s how doArticles() works. (…)

That’s the behaviour that I would expect by default too.

ruud · 2010-01-30 21:01:18

jsoo wrote:

For some plugins I have set one or more attributes’ default value to null, so that a user-specified attribute="" means something different. But it would be confusing to introduce that kind of behavior in core, when so many other tags don’t work that way.

It’s certainly less confusing than introducing attribute="*", because in most cases not specifying attribute in a list tag already means that attribute is not used to limit the resulting list. Using a default NULL value to distinguish from an empty value is better, I think, and it doesn’t introduce the asterisk as a special character.

rsilletti · 2010-01-31 01:48:22

Allowing for an AND search would make a choice like this workable:

Where assigned categories go this way, links in the sidebar, image_display tag in the content div:

image ids 1, 3 & 4 test_cat1
image ids 2, 8 & 9 test_cat2
image ids 5,6,7 & 8 test_cat3

<txp:category_list type="image">
<h3><txp:category /></h3>
<ul>
<txp:image_list category='<txp:category />' id="1,2,3,4,5,6,7,8,9" sort="id ASC" add_atts="1">
<li><a href="<txp:site_url />category/<txp:image_info type="category" />/?p=<txp:image_info type="id" />">
<txp:image_info type="caption" /></a></li>
</txp:image_list>
</ul>
</txp:category_list>


<txp:image_display />

Bloke · 2010-01-31 11:20:21

jsoo / ruud / rsilletti / maniqui

Thanks for your thoughts. Makes a lot of sense and I would definitely like to make this as TXPish as I can but also as useful as I can.

ruud wrote:

in most cases not specifying attribute in a list tag already means that attribute is not used to limit the resulting list

Yes, that’s why beforeheand I had it select all images if you specified no attributes because that’s how all the other tags work. But I judged the consensus to be that was not useful in this case. To accommodate the AND / OR thing raised above, I have a suspicion I’d have to revert to the original intention.

jsoo wrote:

one is unlikely to want to select images by, say, category=“foo” has_thumb=“1” with a disjunctive search. AND is much more useful for this combination.

And in fact (somewhat confusingly I admit) AND is what you get at the moment with that combination. The only things that are ORed together are category, id and name precisely for the combination Rick suggested. Namely, as it stands:

<txp:image_list id="1, 3, 4" category="test_cat1">

will produce a list of images 1, 3, 4 and the images in test_cat1.

Conversely, if I change it to the ‘expected’ behaviour of other tags where conjunctive searches occur between attributes, the same code above would result in only producing a list of images where image IDs 1, 3, 4 are actually in test_cat1. name and id I agree are anomalies because they refer to the same thing and, as you say, most people are unlikely to choose both to search by.

The upshot is that I figured id, name and category would make sense to be taken together as a group and cumulatively used to get your list of images. has_thumb, however, is applied after id/name/category have been chosen so it then reduces the list to a subset of your selected images that have thumbs. This duality of sometimes including images and sometimes excluding them is perhaps what is causing the confusion. And I don’t want confusion!

So, definitvely, which method of working makes sense to you all? Here are the variables and my takes on them:

stick with the current TXPish behaviour so no attributes = all images. Alternative is no attributes = no images — I don’t mind either way. Currently it’s the latter, but originally it was the former
specify one or more categories to include images from all listed categories — makes sense to me and, I assume, everyone else
specify one or more image IDs to include those specific images. Should this override category in this case, or add to it? Currently it adds to it (which is “AND” in terms of human logic (“I want images 1 and 3 and 4 and those from test_cat1”), though not in the computer logical sense so we need to clear that up first… damn taxonomy!)
specify one or more image names to include those specific images. Again, override category or add to it? Currently adds to it though unlikely to mix id and name in one image_list tag
choose images that only have thumbnails — in my view this is an absolute choice irrespective of which ids/names/cats are chosen, the resulting pool will only contain images that have thumbnails. In other words, a logical AND
choosing images by author and ext is valid (I forgot, thanks for pointing it out jsoo). Again, I believe these to be absolute choices. No image will be in the pool even if it matches your category. In other words, a logical AND again, so it only chooses images from your listed IDs/categories that ALSO have the given author and ALSO have the given extension
under what circumstances should article_image be taken into account? And should article_image add to the image pool or be used solely as the definitive list of images? At the moment it is only taken into account if you do NOT specify any attributes AND you are viewing an individual article AND the article_image contains one or more ID values. Under any other conditions, it is ignored
I’m not comfortable with the id="*" thing, but it seemed necessary due to the fact that the tag was altered from its original modus operandi (see point 1)
I’m also not comfortable with category=" ," to depict “uncategorized images” but that is how it works in all the other tags (file_download_list, linklist, probably even section_list?). The alternative is a named constant and, for the reasons ruud states above re: the asterisk, I’d prefer the current syntax to a named constant like TXP_UNCATEGORIZED (primarily for RSI reasons :-) . IMHO, specifying an empty item in a list is the lesser of two evils but I can be swayed either way

Anyway, they are the issues as I see them. There is some confusion between which attributes “add to” the pool of images and which “restrict” the pool, plus there is some non-TXPish behaviour at the moment. The question is whether we can live with it this way because it’s actually more useful or if we should be super-TXPish about it for consistencies sake. I haven’t looked at Rick’s patch yet — perhaps that’ll give me some mroe ideas but as it stands I ned some poking from all you lot out there so we can choose the best method. If there’s no consensus, you get my way which ain’t always the best way :-D

P.S. can’t do anything about it today — stupid ISP is experiencing sporadic packet loss (up to 75% in most cases) so until they fix the router my connection is banjaxed. It takes about 3 attempts and 4 minutes to post to the forum atm… grrrr

Last edited by Bloke (2010-01-31 12:22:18)

jsoo · 2010-01-31 12:43:28

Bloke wrote:

And in fact (somewhat confusingly I admit) AND is what you get at the moment with that combination. The only things that are ORed together (remember we’re building up a list not whittling it down) are category, id and name precisely for the combination Rick suggested.

OK, the confusion is mine then. Thanks for clarifying. When in doubt, I say stick with Txpish behavior. I can certainly be happy with having no attributes = all images. My original concern had been how this would work if image_list is to take article images when there is no article image, but as I said that can be controlled with if_article_image.

Rick’s patch includes an extra attribute to choose the AND option, so allows default Txp behavior. So I would say go conjunctive across attributes as the default, and incorporate a modification of Rick’s patch to give the disjunctive option (make the default value of and_atts = 1). That addresses your points 3 through 6. (Alternately, name the attribute and_or with possible values "and" and "or"; more intuitive I think.)

Get rid of id="*", it was just a toss-off suggestion.

I didn’t realize that category="," worked in other tags, so keep it.

Article image: it was my suggestion to make this automatic in the absence of other atts, but I admit that’s not intuitively Txpish. So perhaps the thing is to have a boolean article_image attribute.

Bloke · 2010-02-05 00:00:09

Spurred on by wet’s neat shortcut in r3309, I think r3310 has cracked it. A brief overview of changes:

three new filtering attributes author, realname and ext allow selection by those characteristics (thanks for reminding me, jsoo). Note that realname has an extra one-query penalty per name for the lookup, but it’s a useful feature if you wanted to show a gallery based on the site.com/author/Joe+Bloggs URL scheme
new attribute context (any better names for this attribute, please holler). By default, the tag is context sensitive, such that if you omit all other selection attributes it checks the article image field for ID(s) to use as your gallery. In future, this attribute may take values other than article (its default). For example, context="file, link, article" would tell the tag to first look for any file images; if it doesn’t find any there, check the link images; and if it doesn’t find any there, check the article image field. This allows you to define which order the contexts are checked in case you’re nesting lists. You will probably rarely use this attribute because it’ll be automatic in most cases
removed id="*". You can now use context="" to mean show me all images, i.e. images without any context-sensitivity. I anticipate this will rarely be used, to the extent that I nearly didn’t expose context to the outside world

Anyway, here are a whole bunch of example tags and their outcomes to demonstrate the effect of the attributes. Please verify the tag works as you expect under these (and other) circumstances and report here if it’s non-intuitive or you feel the tag should behave differently. I think this version is much more logical and takes into account the various views expressed so far in this thread from maniqui, jsoo, ruud, rsilletti, et al.

Heeeeeere goes:

<txp:image_list /> : uses article image field as list of image IDs (if empty, returns no images)
<txp:image_list context="" /> : all images in database (see point 2 above)
<txp:image_list id="" /> : no images
<txp:image_list name="" /> : no images
<txp:image_list category="" /> : no images — e.g. things like category='<txp:custom_field name="my_cats" />' will show nothing if the custom field is empty, as expected
<txp:image_list id="2,3,6" /> : images 2, 3, and 6
<txp:image_list name="lion.jpg, zebra.jpg" /> : the named images
<txp:image_list name="pengiun.jpg" /> : no images (mis-spelled image name)
<txp:image_list name="lion.jpg, zebra.jpg" id="2,3,6" /> : images 2, 3, and 6 and the named images
<txp:image_list category="mammals, birds" /> : all images in the named categories
<txp:image_list category=", mammals, birds" /> : all images in the named categories and any uncategorized images
<txp:image_list category=" " /> : just uncategorized images (note that category="," also works but a space looks better, imo)
<txp:image_list category="mammals, birds" id="8, 42" /> : all images in the named categories and images 8 & 42
<txp:image_list author="attenborough" /> : all images by author (ID) attenborough
<txp:image_list realname="David+Attenborough" /> : all images by author David Attenborough (subject to one extra query)
<txp:image_list author="attenborough, morris" /> : all images by the given author IDs
<txp:image_list author="attenborough" realname="Desmond Morris" /> : all images by the given authors
<txp:image_list category="mammals, birds" author="attenborough, morris" /> : all images in the named categories that are assigned to the named authors
<txp:image_list category="mammals, birds" ext=".jpg" /> : all jpg images in the named categories
<txp:image_list category="mammals, birds" ext=".jpg" author="attenborough, morris" /> : all jpg images in the named categories that are assigned to the named authors
<txp:image_list ext=".gif" /> : all GIF images
<txp:image_list category="mammals, birds" thumbnail="1" /> : all images in the named categories that have thumbnails assigned to them
<txp:image_list thumbnail="1" /> : all images that have thumbnails assigned to them

That’s just a set of tests I performed to verify that the tag behaves uniformly, based on the feedback so far. Bottom line is I don’t want the tag to be too cryptic, but I want it to be intuitive such that a naked tag is fairly useful, plus if it’s given a set of attributes it returns something you might reasonably expect, and it’s also flexible enough to cater for (possible) future file/link images.

Please let me know your thoughts on how TXPish this is, vs how useful it is, vs how easy it is to understand. First person to chart this in a meaningful way on a multi-axis graph wins a gold star :-)

Thanks in advance.

Last edited by Bloke (2010-02-05 09:56:45)

Textpattern CMS

Textpattern CMS support forum

#37 2010-01-29 13:38:12

Re: Images are 1st class citizens of TXP

#38 2010-01-29 13:41:31

Re: Images are 1st class citizens of TXP

#39 2010-01-29 18:12:39

Re: Images are 1st class citizens of TXP

#40 2010-01-29 19:14:54

Re: Images are 1st class citizens of TXP

#41 2010-01-29 21:52:43

Re: Images are 1st class citizens of TXP

#42 2010-01-30 19:56:50

Re: Images are 1st class citizens of TXP

#43 2010-01-30 20:12:59

Re: Images are 1st class citizens of TXP

#44 2010-01-30 21:01:18

Re: Images are 1st class citizens of TXP

#45 2010-01-31 01:48:22

Re: Images are 1st class citizens of TXP

#46 2010-01-31 11:20:21

Re: Images are 1st class citizens of TXP

#47 2010-01-31 12:43:28

Re: Images are 1st class citizens of TXP

#48 2010-02-05 00:00:09

Re: Images are 1st class citizens of TXP

Board footer