aam_split_custom_field: Simple Multi-Value Custom Fields

Logoleptic · 2007-12-30 09:45:24

This plugin lets you collect related pieces of information into a single field, pull one or more of them back out again, and create conditional content based on individual values in the collection.

The collections themselves are simple string-delimited lists — easy to create, but flexible enough to accomplish some interesting things. With the aam_split_custom_field template tag, you can extract and output a single value or several successive values from the field using your choice of HTML markup. For example, you can turn a delimited custom field into a bulleted list or a series of paragraphs. The aam_if_scf conditional tag does comparisons against individual values from the delimited field. You can see some examples in this blog post, and full documentation is available in the plugin’s help.

Download v1.0 (8.6 KB)

NOTE: requires version 4.0.4 or higher

This Sounds Familiar…

This plugin serves a similar purpose to Steve Dickinson’s sed_pcf “packed custom fields” plugin. So why make anther plugin, and which one is better for you?

This plugin has a simpler syntax for custom field data than sed_pcf, but sed_pcf lets you give data greater structure.
- Consider using aam_split_custom_field when highly structured data is unnecessary, or when novice users will be maintaining the site.
- Consider using sed_pcf when structured data is important, or for sites with more advanced users.
This plugin offers a convenient way to generate marked-up output from several successive values in a list; sed_pcf lacks a similar feature, but lets you pick and choose specific values by name.
- Consider aam_split_custom_field when dealing with lists or collections of a fairly general nature (e.g. product features).
- Consider sed_pcf when data is more specialized (e.g. product color, size, price, etc.).

Although I haven’t tried, it should also be possible to work with both plugins on the same site. You can use sed_pcf for some custom fields, and aam_split_custom_field for others.

Important Update!

Forward-compatibility note: The behavior of the plugin’s conditional tag will be changing in the next release. It will become possible to compare a user-specified string against every item in the delimited field (instead of just one selected item). This feature will be invoked by omitting the offset attribute or explicitly setting it as empty. That’s a change from the current behavior, which has offset defaulting to 0. If you use the conditional tag in production, I recommend specifying the offset attribute, even when you intend it to be 0.

Last edited by Logoleptic (2008-01-02 01:38:04)

net-carver · 2007-12-30 16:36:53

Adam

Yes, this fills a gap that sed_pcf missed. For a few weeks now my latest (unreleased) version of sed_pcf has had the sed_pcf_for_each_value container/form tag that works on a comma separated list of values in a custom field. It was inspired by wet_for_each_image.

Your plugin looks way more configurable for conditional testing and range processing in the HTML generation though. Great work!

Last edited by net-carver (2007-12-30 17:51:14)

typeshige · 2007-12-30 17:23:41

I’ve been using custom fields to emulate subsections. I have a cf called subsection, subsubsection, sub3section, sub4section (so far). This has worked well, but it seems I could either roll up this into one custom field delimited by slashes without using sed_pcf for aam_split_custom_field, or I can try using one of these plugins.

Do you have a suggestion about which one, if any would work better for me?

Logoleptic · 2007-12-30 19:43:25

@net-carver: Thanks for the kind words. Coming from a top-notch plugin author such as yourself, that means a lot to a relative newbie like me.

@typeshige: I think you could do what you’re talking about with either one, but sed_pcf might make it easier. The more structured syntax that I mentioned sed_pcf having works like this: name1='value1';name2='value2'. By using sed_pcf, you could retain the names that identify each piece of data. Don’t go crazy with the length of those names, though — with both of these plugins, custom fields are still limited to 255 characters.

Logoleptic · 2008-01-02 01:39:22

I’m also adding this to the original post, but here’s an update for anyone who has subscribed to this thread:

Important Update!

Forward-compatibility note: The behavior of the plugin’s conditional tag will be changing in the next release. It will become possible to compare a user-specified string against every item in the delimited field (instead of just one selected item). This feature will be invoked by omitting the offset attribute or explicitly setting it as empty. That’s a change from the current behavior, which has offset defaulting to 0. If you use the conditional tag in production, I recommend specifying the offset attribute, even when you intend it to be 0.

Textile Formatting?

I was also thinking that it would be useful to be able to format output using Textile. There’s no reason for me to add this, however, if Mary’s upm_textile plugin can do the job when combined with this one. I won’t have time to test this for a while, so if anyone out there has tried it and can comment on how it worked, please let me know.

Last edited by Logoleptic (2008-01-02 01:52:08)

pieman · 2008-01-30 16:22:47

this looks ace

Adam, this may be beyond the scope, but could you tell me if it’s possible to output data from the custom field in pairs?

I need to allow a user to produce a Specification box about a product. The parameters may change in subject and quantity over time, so I can’t hard-code individual custom fields. I’d love to be able to output a <dl> definition list – to achieve something like

<dl>
<dt>Size</dt>
<dd>Medium</dd>
<dt>Colour</dt>
<dd>Red</dd>
<dt>Price</dt>
<dd>£9.99</dd>
</dl>

I hope that makes sense.. does it sound possible?

many thanks
Stu

Logoleptic · 2008-01-30 20:19:45

@Stu: You’re getting into territory that’s better covered by the sed_pcf plugin. Its ability to use name-value pairs could accomplish what you’re after.

Don’t forget to take the end user into account as you decide on a solution. If the site’s maintainers aren’t very technically-minded, it might be better to use separate custom fields and the glz_custom_fields plugin for drop-down menus (e.g. Small, Medium, Large).

pieman · 2008-01-30 22:54:09

Thanks for the advice, I’ll give that one a whirl.

My problem is that the specification parameters need to be left open, so I can’t predetermine the names of the custom fields, or even how many are required in each case.

Logoleptic · 2008-01-31 01:47:15

pieman wrote:

Thanks for the advice, I’ll give that one a whirl.

My problem is that the specification parameters need to be left open, so I can’t predetermine the names of the custom fields, or even how many are required in each case.

That’s a pretty rough situation to be in with any set of data, especially product data on a site geared toward selling things. This plugin is more suited to secondary product info that won’t be needed later on during checkout. To use t-shirts as an example, you could record the following in a custom field and then spit it back out in a bulleted list of features:

100% cotton|prewashed and preshrunk|top-quality screen printing, durable through hundreds of washes

I don’t know all the details of your project — and I definitely don’t want to tell you how to do your job — but you might consider biting the bullet and structuring your data in separate fields. You’re already experiencing how difficult it is to make any consistent use of unspecified and amorphous data.

That difficulty will only grow as the site expands over time. If you later need to extract information to be handed off to a shopping cart, saved in cookies, or handled by JavaScript, you’ll need reliable identifiers for that information. You may be able to use sed_pcf for this purpose, as long as nobody makes a data entry typo and spells it “Priec” or “Color” when filling in the product info.

Like I said, I don’t know all the details of this site. I could be way off the mark in my suggestions. I do know from (painful) experience, however, that it’s easier to get this kind of thing right from the start than to fix it when the site needs to expand. Talk with your client about their plans for the future, then keep those plans in mind during development.

And if you’re already doing that, ignore everything I just said. ;-)

pieman · 2008-01-31 07:34:38

Heh, thanks, that’s sound advice.

Apart from the variable nature of the specs, the product types are sorted by category rather than section, so ~~glz_custom_fields~~ sed_section_fields wouldn’t help in this case.

It is indeed secondary product data (my use of ‘price’ in the example was misleading). Retrieving and sorting the data, while useful later perhaps, isn’t enough of a concern to justify further investigation at this stage.

I was mainly hoping to be able to output a nice clean definition list, but I think I’ll just get the user to use simple Textile instead.

*name* value
*name* value
*name* value

once again, thanks for your help
Stu

Last edited by pieman (2008-01-31 08:30:28)

kemie · 2008-10-08 10:05:16

reviving this thread a bit.
I’m using glz_custom fields for a small store site. I want the store owner to be able to input the available sizes for each product.
I set up the custom field with checkboxes for each site, so the result should be something like S, M, L, XL
But on the frontend, I’d like a dropdown for the customer to select a size
<select name=“size”>
<option value=“S”>S</option>
<option value=“L”>L</option>
<select>

so, i can get a long way with
<txp:aam_split_custom_field name=“size” delimiter=”|”
wraptag=“select” break=“option” id=“os0” />

but i’m still left with the name and values. is there any way (even hacky ways) of making this work?

kemie · 2008-10-08 10:32:39

hm, made another attempt using this:


<select name="size">
<txp:aam_if_scf name="size" delimiter="|" val="S">
  <option value="S">S</option>
</txp:aam_if_scf>
<txp:aam_if_scf name="size" delimiter="|" val="M">
  <option value="M">M</option>
</txp:aam_if_scf>
<txp:aam_if_scf name="size" delimiter="|" val="L">
  <option value="L">L</option>
</txp:aam_if_scf>
</select>

but I only get the first checked value. any ideas of what could be wrong?

Last edited by kemie (2008-10-08 10:32:59)

Textpattern CMS

Textpattern CMS support forum

#1 2007-12-30 09:45:24