Images are 1st class citizens of TXP

Bloke · 2010-03-24 23:27:12

Since there’s been very little reaction and the one or two concerns raised here or privately have been that it might be too complicated for core use, let me rephrase the question:

Would anybody miss the ability to specify an AND/OR scenario in this tag if I removed it?

Removing the ‘image pool’ idea means that all filter attributes are applied on top of one another and only images that match all the criteria are returned. In other words, id, name, category, author, realname, ext and thumbnail work like they do in other tags.

If the tag is reverted to this more TXPish behaviour then anybody wanting anything more complicated, will have to use a plugin. OK? Or not?

Last edited by Bloke (2010-03-24 23:28:05)

rsilletti · 2010-03-24 23:41:07

Bloke
I’ve cloned a plugin that includes the and_or att, and if_first | if_last options, from the commit prior to the pagination additions. It runs as expected under Ver 4.2.0 and it would provide for the needs of anyone interested in the added functionality. Updating another for the next release would also work.
The primary question is whether or not you want your code used that way by a third party.

jsoo · 2010-03-25 01:32:15

Bloke wrote:

Since there’s been very little reaction and the one or two concerns raised here or privately have been that it might be too complicated for core use

Sorry. Too busy lately to do more than skim, and didn’t want to chime in without due consideration. Unless you are going to allow wildcards, partial matches, regexp, or what have you, I don’t see enough benefit from the AND|OR switch to outweigh the additional complexity.

Gocom · 2010-03-25 06:49:17

Bloke wrote:

If the tag is reverted to this more TXPish behaviour then anybody wanting anything more complicated, will have to use a plugin. OK? Or not?

I personally do like your latest additions. But, IMO they are way too complex: As I earlier said something that I would except finding from smd_plugin. Don’t take me wrong, they are great but just that… why.

What comes to shortage of comments, possible because this isn’t what userbase wants? Maybe they are fine with the current smd_gallery and what not. When you look at feature requests they seem to want better image management and handling to the backend not to the tags which can only be used by web developers, not the actual content authors. Way that they can do uploading, content and common tasks at once.

wet · 2010-03-25 08:49:44

Bloke wrote:

If the tag is reverted to this more TXPish behaviour then anybody wanting anything more complicated, will have to use a plugin. OK? Or not?

From a gut feeling: OK. I once dabbled in improving image-related tags – and then came soo_image, adding yet another item to the vast collection of all thing gallery we already have at our disposal. From my POV, the area of images and galleries and what not is too diverse to find a on-size-fits-all solution. Look, even those lightbox effect scripts are legion nowadays.

Bloke · 2010-03-25 08:50:09

rsilletti / Gocom /jsoo / all

Thanks. You’re all right. I will strike the complexities from the code forthwith. In order to keep the auto-article-image stuff though, I think the context wil have to stay for the time being. If that feels too much I can kill that as well.

Rick, by all means clone the code. It’s there for your consumption. I’m thinking of stealing your date difference class for smd_calendar 8o)

Gocom wrote:

better image management and handling to the backend not to the tags

Yeah, point taken. It’s coming, just taking me longer than expected.

My aim for the front-end tags was twofold:

To introduce $thisimage so images are brought into alignment with the existing content types
To bring the best parts of upm_image / soo_image to the core so that $thisimage can be taken advantage of and we can get at the image fields natively. It makes little sense to have a caption if we can’t display it without a plugin!

I shall make amendments today, test and release. Watch this space, and thanks again for your thoughts / helping me see the light.

Gocom · 2010-03-25 09:16:36

Bloke wrote:

To introduce $thisimage so images are brought into alignment with the existing content types

Which is great addition :-)

helping me see the light.

LOL. Fires of doom ;-)

Last edited by Gocom (2010-03-25 09:17:40)

Bloke · 2010-03-25 09:58:53

Aaaaaand it’s gone. Sanity is restored.

Gocom · 2010-03-25 11:36:49

Crazyyyyyyyy.

gomedia · 2010-07-06 10:07:47

Any chance of a new <txp:image/> attribute to disable the output of HTML width="xx" height="yy"?

Bloke · 2010-07-06 10:34:01

gomedia wrote:

Any chance of a new <txp:image/> attribute to disable the output of HTML width="xx" height="yy"?

For what purpose? (forgive my ignorance). If it’s for manual resizing, you might like to be on the beta list for smd_thumbnail. Get in touch if you want to try it out and you’re running bleeding edge SVN.

gomedia · 2010-07-06 10:41:05

Bloke wrote:

For what purpose?

For elastic/stretchy/bendy layouts where images are resized in CSS according to ems or percents.

With the HTML width & height attributes:

img { width:20em; height:auto }

without width & height:

img { width:20em }

Saves my sanity & some code bloat. Both upm_image & soo_image have options to disable width/height in HTML <img> tag.

Textpattern CMS

Textpattern CMS support forum

#61 2010-03-24 23:27:12

Re: Images are 1st class citizens of TXP

#62 2010-03-24 23:41:07

Re: Images are 1st class citizens of TXP

#63 2010-03-25 01:32:15

Re: Images are 1st class citizens of TXP

#64 2010-03-25 06:49:17

Re: Images are 1st class citizens of TXP

#65 2010-03-25 08:49:44

Re: Images are 1st class citizens of TXP

#66 2010-03-25 08:50:09

Re: Images are 1st class citizens of TXP

#67 2010-03-25 09:16:36

Re: Images are 1st class citizens of TXP

#68 2010-03-25 09:58:53

Re: Images are 1st class citizens of TXP

#69 2010-03-25 11:36:49

Re: Images are 1st class citizens of TXP

#70 2010-07-06 10:07:47

Re: Images are 1st class citizens of TXP

#71 2010-07-06 10:34:01

Re: Images are 1st class citizens of TXP

#72 2010-07-06 10:41:05

Re: Images are 1st class citizens of TXP

Board footer