smd_wrap: conditionally wrap stuff with tags and labels

Bloke · 2011-12-13 00:29:44

v0.20 beta is available to try. The chh_if_data mode is triggered by specifying content_mode="txp_tags". Any better naming convention or attribute name welcomed. I chickened out of making it the default method because that woud mean things like:

<txp:smd_wrap>{some_stuff}</txp:smd_wrap>

where {some_stuff} was from another plugin would return nothing. So you have to explicitly say you want to only check tags instead of all content. If you are using transform="form" you can now choose to use the slightly-less-secure {smd_wrap_it} or the safer <txp:smd_wrap_info />. Untested inside PHP blocks, but I suspect the tag version won’t work unless you add your own parse() around it.

Please give this one a flying lesson and let me know how it works.

Last edited by Bloke (2011-12-13 00:30:15)

maniqui · 2011-12-14 20:42:34

Bloke wrote:

v0.20 beta is available to try. The chh_if_data mode is triggered by specifying content_mode="txp_tags".

Cool, thanks.

Any better naming convention or attribute name welcomed.

Maybe just data_mode (inspired by chh_if_data). Can’t think of any better.

I chickened out of making it the default method…

Argh! :)
I’d like this mode (txp_tags) to be the default. It will make us all feel better when replacing <txp:chh_if_data>...</txp:chh_if_data> just with shorter <txp:smd_wrap>...</txp:smd_wrap> (instead of longer <txp:smd_wrap content_mode="txp_tags">...</txp:smd_wrap>).

Bloke wrote

… because that woud mean things like <txp:smd_wrap>{some_stuff}</txp:smd_wrap> where {some_stuff} was from another plugin would return nothing.

I admit I don’t understood the “excuse” ;) Of course, because I lack the knowledge to understand how all the search-and-replace-of-bracket-variables+parsing-of-txp-tags works.

If you have one minute or two, could you explain the logic of how this chh_if_data-like feature works?
I see you implemented it in a very similar (if not the same) fashion that the one used in chh_if_data (a regex that strips out txp tags, right? and then, you compare the length of remaining non-parsed string vs length of parsed code, right?).

Maybe two brains can think almost as one working at full capacity. :)

maniqui · 2011-12-14 20:44:23

It will make us all feel better when replacing <txp:chh_if_data>…</txp:chh_if_data> just with shorter <txp:smd_wrap>…</txp:smd_wrap> (instead of longer <txp:smd_wrap content_mode=“txp_tags”>…</txp:smd_wrap>).

BTW, I think can live peacefully with the longer version, and/or keep chh_if_data at hand :)

renobird · 2011-12-14 20:58:03

maniqui wrote:

BTW, I think can live peacefully with the longer version, and/or keep chh_if_data at hand :)

Indeed. Viva La <txp:chh_if_data>!

Bloke · 2011-12-14 22:12:10

maniqui wrote:

data_mode

That works for me and it’s shorter.

I’d like this mode (txp_tags) to be the default.

I hear you, but when nothing comes out the other side of the (more usual) case of “wrap the entire contents and perform these transforms”, the potential support calls are probably going to snow me under!

The primary motivation behind the plugin was to wrap and transform things of unknown origin, like {replacements} (or their <txp:smd_some_data /> counterparts) from, say, an smd_query instead of having to do a conditional first. Thus it needs to be short so it doesn’t get in the way and make code more unwieldy than using the conditional.

But now I see that both approaches — tags and entire contents — have merit, how about I compromise and write a convenience tag called, I dunno, <txp:smd_wrap_tags> or <txp:smd_wrap_data> which calls the main smd_wrap but automatically sets data_mode="txp_tags" on your behalf? Any better names welcome. I could maybe stretch to <txp:smd_if_wrap> to make it the same number of characters as <txp:chh_if_data>, as long as you didn’t think that was too misleading as a tag name :-)

Argue away.

could you explain the logic of how this chh_if_data-like feature works?

Sure. It works pretty much as you said:

capture the ‘true’ segment of the container / form
strip out any <txp:...> tags
note how big the output is, in characters
parse the true part including the txp: tags
count the number of characters
on the basis that the txp:tags must add something to the document, if the two counts differ then the txp:tags returned some content and thus the true part can be displayed, else if they are still the same length after the txp:tags have been run, they didn’t output anything so display the false bit

Make sense?

Last edited by Bloke (2011-12-14 22:14:03)

maniqui · 2011-12-15 00:08:04

maniqui wrote:

I’d like this mode (txp_tags) to be the default.

Bloke wrote:

I hear you, but when nothing comes out the other side of the (more usual) case of “wrap the entire contents and perform these transforms”, the potential support calls are probably going to snow me under!

(click!) But… but… precisely!
Who would be wrapping (& maybe transforming) anything that is not dynamic content ({replacement} <txp:some_data /> tags)?
In other words, no one will be wrapping just static (hardcoded) content to transform it.

When using smd_wrap around some dynamic content, if that dynamic content is empty to begin with, user probably won’t need anything “coming out the other side”.

The primary motivation behind the plugin was to wrap and transform things of unknown origin, like {replacements} (or their <txp:smd_some_data /> counterparts) from, say, an smd_query instead of having to do a conditional first. Thus it needs to be short so it doesn’t get in the way and make code more unwieldy than using the conditional.

Unless I’m missing something not very obvious, the primary motivation of smd_wrap still has the spirit of chh_if_data (i.e. the data_mode="txp_tags" by default) inside it.

Let’s consider these basics examples of smd_wrap usage:

<txp:smd_gallery limit="1">
  <img src="{url}" />
  <txp:smd_wrap transform="textile" wraptag="div" class="caption">
    {caption}
  </txp:smd_wrap>
</txp:smd_query>

<!-- Alternatively -->

<txp:smd_gallery limit="1">
  <img src="{url}" />
  <txp:smd_wrap transform="textile" wraptag="div" class="caption">
    <txp:smd_gallery_data data="caption" /> <!-- note: imaginary tag -->
  </txp:smd_wrap>
</txp:smd_query>

In this cases, if {caption} or <txp:smd_gallery_data> return empty, then smd_wrap goes away silently…

Let’s go one step further, now adding some hardcoded content inside smd_wrap

<txp:smd_gallery limit="1">
  <img src="{url}" />
  <txp:smd_wrap transform="textile" wraptag="div" class="caption">
    This is the caption for the beautiful image above:  {caption}
  </txp:smd_wrap>
</txp:smd_query>

<!-- Alternatively -->

<txp:smd_gallery limit="1">
  <img src="{url}" />
  <txp:smd_wrap transform="textile" wraptag="div" class="caption">
    This is the caption for the beautiful image above: <txp:smd_gallery_data data="caption" /> 
  </txp:smd_wrap>
</txp:smd_query>

I’d doubt there is any user out there that would like to get the “This is the caption for the beautiful image above:” when {caption} or <txp:smd_gallery_data data="caption" /> returns empty.

Then, I can’t think of any use cases where the following would be desirable:

<txp:smd_wrap transform="apply|some_crazy|transform"><p>{caption}</p><p>That's the story</p></txp:smd_wrap>

that, if caption is empty, in current default data_mode="all" will just return <p></p><p>That's the story</p>.
Why would anyone want to output all the hardcoded tags (or content) if the inner dynamic content ({replacement} or txp:tags) generated no output?

——

I’m taking this too far… let’s wait for the masses of smd_wrap users to raise their voice on the matter.

I could maybe stretch to <txp:smd_if_wrap> to make it the same number of characters as <txp:chh_if_data>, as long as you didn’t think that was too misleading as a tag name :-)

If I cannot yet convince you that data_mode="txp_tags" as default is the way to go, I will leave you at peace if that <txp:smd_if_wrap> comes true ;).

Sure. It works pretty much as you said:
(…)
on the basis that the txp:tags must add something to the document, if the two counts differ then the txp:tags returned some content and thus the true part can be displayed, else if they are still the same length after the txp:tags have been run, they didn’t output anything so display the false bit

Thanks, that explains it.
And, btw, in case I finally convinced you about the data_mode="txp_tags", I suppose this mode should also have a regex to cover {replacement} tags, right?

Thanks (and sorry for the usual disturbance I put in your way…)

Bloke · 2011-12-15 01:57:55

maniqui wrote:

Who would be wrapping (& maybe transforming) anything that is not dynamic content ({replacement} <txp:some_data /> tags)?

Nobody, but that’s not the point.

Firstly, thanks for the examples. In those opening two cases it doesn’t matter either way: the result is identical no matter which mode you use.

In the second pair, yes a txp-tags solution is perhaps preferable unless you were to employ the label (or prefix) attribute or use the add transform:

<txp:smd_gallery limit="1">
  <img src="{url}" />
  <txp:smd_wrap transform="textile" wraptag="div" class="caption"
     label="This is the caption for the beautiful image above:">
    {caption}
  </txp:smd_wrap>
</txp:smd_query>

The difference is in semantics vs personal readability. I (mostly) prefer attributes, you prefer containers.

But now here’s another example, in use on a site:

<txp:smd_bio_author author="SMD_ALL">
    <txp:smd_bio_info>
        <h1>{smd_bio_RealName}</h1>

        <section class="socblock">
            <txp:smd_wrap wraptag="ul" class="profile-links">
              <txp:smd_wrap wraptag="li" transform="link|Website">
                <txp:smd_bio_data field="website" />
              </txp:smd_wrap>

              <txp:smd_if_bio field="twitter">
                <txp:smd_if field="{smd_bio_twitter}" operator="begins" value="http">
                  <txp:smd_wrap wraptag="li"><a href="<txp:smd_bio_data field="twitter" />">Twitter</a></txp:smd_wrap>
                <txp:else />
                  <txp:smd_wrap wraptag="li" transform="replace||@">
                    <a href="http://twitter.com/<txp:smd_bio_data field="twitter" />">Twitter</a>
                  </txp:smd_wrap>
                </txp:smd_if>
              </txp:smd_if_bio>

              <txp:smd_wrap wraptag="li" transform="link|G+">
                <txp:smd_bio_data field="gplus" />
              </txp:smd_wrap>

              <txp:smd_wrap wraptag="li" transform="link|LinkedIn">
                <txp:smd_bio_data field="linkedin" />
              </txp:smd_wrap>

              <txp:smd_wrap wraptag="li" transform="link|Facebook">
                <txp:smd_bio_data field="facebook" />
              </txp:smd_wrap>
            </txp:smd_wrap>
        </section>

        <txp:smd_wrap transform="textile">
          <txp:smd_bio_data field="bio" />
        </txp:smd_wrap>

    </txp:smd_bio_info>
  </txp:smd_bio_author>

That monstrosity outputs a social media block with links to a person’s social sites alongside their bio, and if any are empty they are silently skipped. I employed <txp:smd_if_bio> around the Twitter one because I wanted to use smd_if and I preferred to be sure the variable existed instead of doing the NULL dance.

There’s no hard-coded text in there whatsoever and I’m mostly using real tags instead of {replacements}, but with data_mode="txp_tags" no output is rendered at all between the <section> tags. Why? No idea! But it’s a legitimate use of the tags and it works in ‘all’ mode.

That sort of thing is what the plugin was built for. Little need for conditionals around any items and no empty list items generated for missing data. Plus I get the transformations for free. If I was to do the above and received no output I’d be mighty annoyed and would probably spend a long time debugging it, only to discover the plugin was at fault.

In your ‘crazy transform’ example, an alternative approach might be either:

<txp:smd_wrap transform="apply|some_crazy|transform" wraptag="p" suffix="<p>That's the story</p>">{caption}</txp:smd_wrap>

(admittedly uglier, and more typing). Or perhaps:

<p><txp:smd_wrap transform="apply|some_crazy|transform" suffix="</p><p>That's the story">{caption}
<txp:else />No caption defined</txp:smd_wrap></p>

if you wanted to always have the paragraph marks so you can report the error condition. You could do the same of course with the container using data_mode="txp_tags" so this simplistic kind of thing isn’t the greatest use of the plugin.

Anyway, I’ve shown that txp_tags mode can have unexpected effects but if you really feel so strongly about having that mode as default, I’ll change it and make, erm, a <txp:smd_wrap_all> tag (or something) that behaves like v0.10 did.

I suppose [txp_tags] mode should also have a regex to cover {replacement} tags, right?

I thought so too at first, but it doesn’t seem to make any difference. I think it’s because the replacements are done prior to parsing so they’re treated as ‘static’ content and are thus included in the character count.

For example I expected this:

<txp:smd_query query="select * from txp_users">
   <txp:smd_wrap wraptag="li" transform="case|lower|ucfirst">
      {name}
   </txp:smd_wrap>
</txp:smd_query>

to skip user names that were shorter than 6 characters (the length of {name}). But it doesn’t: they get rendered regardless in either mode, even if the wraptag is removed (which I thought may have been contributing to the character count of the post-parsed content). *shrug*

In any case, this behaviour might change if I sneakily replace {smd_wrap_it} with the <txp:smd_wrap_info> tag on your behalf so I might have to run some tests and jig about with stuff if I do that.

Last edited by Bloke (2011-12-15 02:01:37)

maniqui · 2011-12-15 03:24:42

Thanks for the thorough reply, Bloke.

The difference is in semantics vs personal readability. I (mostly) prefer attributes, you prefer containers.

I prefer both, and TXP (and smd_wrap, in this case) let me use both :).
Just that sometimes attributes (I’m mainly talking about wraptag/break & class) may be more limiting that plain old, hardcoded wrapping HTML spiced up with a few txp:tags. At the same time, I have to admit that tags-in-tags + wraptag/break & class could also bring some extra flexibility not achievable when HTML is hardcoded.

That monstrosity outputs (…)

Nice monster; to be fair, not a monster at all, I like how it looks: short, concise, clever and readable.

I thought so too at first, but it doesn’t seem to make any difference (…) even if the wraptag is removed (which I thought may have been contributing to the character count of the post-parsed content). shrug

Aaaah… I hope one day I’ll learn how (in which order) all the TXP tag parsing really works, and get to see how a page template or form really looks like after it has been parsed and re-parsed and re-re-parsed by TXP…

Anyway, I’ve shown that txp_tags mode can have unexpected effects but if you really feel so strongly about having that mode as default, I’ll change it and make, erm, a <txp:smd_wrap_all> tag (or something) that behaves like v0.10 did.

No, no, please, not at all.
I’m sorry and ashamed for being so insistent with the idea. I’ll be more than OK with the current default. And if an smd_if_wrap (a shortcut to data_mode="txp_tag") slips in into some future version of smd_wrap, that would be more than welcome…

milosevic · 2011-12-30 14:39:38

Hi, everybody:

I am trying to convert the response of <txp:cbe_helpful> plugin with smd_wrap and I am getting crazy trying to find the solution.

<txp:cbe_helpful> is returning to me values such:

100,00 %
90,50 %
80,00 %
…

and I would like to transform that values to

100
90
80

that is, deleting everythink on the right side of the “,” simbol.

How would you transform that example values width smd_wrap?

jakob · 2011-12-30 15:53:57

how about using <txp:smd_wrap transform="split|,|1">...</txp:smd_wrap> ? That should split at the comma and return the first part only.

milosevic · 2011-12-30 16:40:01

jakob dijo:

how about using <txp:smd_wrap transform="split|,|1">...</txp:smd_wrap> ? That should split at the comma and return the first part only.

Thanks, Jakob. That was my first option to try, but <txp:smd_wrap transform=“split|,|1”>100,00 %</txp:smd_wrap> returns nothing and an error message:

-> Warning: explode() [function.explode]: Empty delimiter on line 215

Then, trying to avoid problems with the “,” character (default delim), I tryed this:

<txp:smd_wrap delim=”:” transform=“split|,|1”>100,00 %</txp:smd_wrap>

But returns nothing. No error but no data.

Bloke · 2011-12-30 16:45:28

milosevic wrote:

transform=“split|,|1”>100,00 %</txp:smd_wrap> returns nothing

Try transform="split|,||1" (note the extra pipe delimiter). You need that one to signify that you don’t want any join characters — it’s a mandatory second argument if you’re using the third argument to specify which piece(s) you want back.

It shouldnt, however, return the error if you’re only using two args so I’ll look into that one, thanks for finding it. EDIT: appears it’s not an error as such. As milosevic noted, the default character to chain transforms is the comma.

I could add some mathematical transforms if it would help: round, absolute, ceiling floor, etc. I’ll consider it for the next version.

Last edited by Bloke (2012-01-27 22:02:47)

Textpattern CMS

Textpattern CMS support forum

#49 2011-12-13 00:29:44

Re: smd_wrap: conditionally wrap stuff with tags and labels

#50 2011-12-14 20:42:34

Re: smd_wrap: conditionally wrap stuff with tags and labels

#51 2011-12-14 20:44:23

Re: smd_wrap: conditionally wrap stuff with tags and labels

#52 2011-12-14 20:58:03

Re: smd_wrap: conditionally wrap stuff with tags and labels

#53 2011-12-14 22:12:10

Re: smd_wrap: conditionally wrap stuff with tags and labels

#54 2011-12-15 00:08:04

Re: smd_wrap: conditionally wrap stuff with tags and labels

#55 2011-12-15 01:57:55

Re: smd_wrap: conditionally wrap stuff with tags and labels

#56 2011-12-15 03:24:42

Re: smd_wrap: conditionally wrap stuff with tags and labels

#57 2011-12-30 14:39:38

Re: smd_wrap: conditionally wrap stuff with tags and labels

#58 2011-12-30 15:53:57

Re: smd_wrap: conditionally wrap stuff with tags and labels

#59 2011-12-30 16:40:01

Re: smd_wrap: conditionally wrap stuff with tags and labels

#60 2011-12-30 16:45:28

Re: smd_wrap: conditionally wrap stuff with tags and labels

Board footer