Semi-persistent general storage plugin

Bloke · 2008-06-08 10:43:21

Adds the ability to smd_var_put multiple vars with the same expiry in at once. Just comma-separate them in the name and value parameters.

You can also now defer replacement of ? field names to smd_var_get by specifying get_vals_now="0". It defaults to ‘1’ which means this:

<txp:smd_var_put name="v1, v2, v3" value="1st, 2nd has the ?url_title in it, 3rd" expiry="@20m" />

would insert 3 variables v1, v2, and v3 that all expire in 20 minutes. The 2nd one might be stored as “2nd has the my-first-post in it”. Contrast that with the same tag that sets get_vals_now="0". The 2nd variable would then contain “2nd has the ?url_title in it” verbatim. When you subsequently do an smd_var_get, the ?url_title will be replaced at that time.

I have also removed the delete attribute from smd_var_put. Instead you can now specify an action:

replace (default) overwrites any existing variable’s value
append adds the new value to the end of any existing value
prepend adds the new value to the beginning of any existing value
delete removes the variable the same as the delete attribute used to

See how you get on with it.

Bloke · 2008-06-09 09:44:38

Ooops, update to v0.12 | compressed which fixes the admin side to allow empty values, like the docs say it does!

Thanks to uli for spotting that.

Zanza · 2008-06-11 10:57:03

Bloke wrote:

There’s nothing to stop you setting up a system where the ‘name’ is, for example, “favarticle_zanza” (remember you can create these things on the fly so under TXP 4.0.7 you have the full range of TXP tags with which to grab stuff) and the ‘value’ is whatever article they have indicated they prefer. (..)

I still think cookies are perhaps the “correct” way to go about this, but there’s absolutely nothing to stop you using smd_vars to do it if you prefer. Subject to local data retention laws, etc (e.g. Germany).

Wow. Sorry for the delay in replying, too much things to mumble about for non-english speaker… :) I just wanted to say that you’re doing an exciting, excellent job, I’m looking forward to play with it, just need some time and maybe the SVN TXP version… thanks a lot!

Z-

Bloke · 2008-06-11 11:14:48

Zanza wrote:

I’m looking forward to play with it, just need some time and maybe the SVN TXP version… thanks a lot!

You’re welcome, and yes I think this combined with smd_query will be a good test for the new parser :-)

BTW, there’s a bug that uli spotted in the current version: you cannot delete the first item in the list for some obscure reason. The correct code is put on the page but it doesn’t wrap the delete <form> round the ‘x’ button in the first row. Totally screwy, but I think it’s to do with validation. I’ve uncovered about 50 validation issues (tut-tut, Stef) and fixed all but one of them in my dev version.

Once I have the page validating I can begin to track down what’s causing it. In the meantime if you want to delete the first item in the list, re-order the table by some other column and use a delete button in another row!

lee · 2008-06-11 12:55:31

Anyone give me a simple but and useful example of how this could be used please – it’s over my head at the moment.

Best wishes
Lee

Bloke · 2008-06-11 13:12:25

lee wrote:

Anyone give me a simple but and useful example of how this could be used please

Store some user-submitted info from one page and retrieve it on a later page; for example, a wizard. Break a form up over a few pages instead of having one big form. Store the results in smd_vars as each page is submitted and then — at the end when the user clicks “I’m happy, do it” — retrieve all the info stored so far and do something with it.

You could either choose to have the variables expire after a certain time (say, 10 minutes) so if the form isn’t completed within the alloted time, the vars become useless. Or keep them so if the user doesn’t complete the form staright away they can come back to it later.

EDIT: there will probably be some new convenience features coming soon to allow you to store related temporary variables and retrieve them all instead of having to list them explicitly. If I can get my head round it, that is.

Last edited by Bloke (2008-06-11 13:14:05)

lee · 2008-06-11 13:23:23

So for example if I were building an estate agent site, like I am, there could be a remember this property button on each property page and then a view previously viewed properties page where they could be a list of these properties.

Or another example could be like on Amazon where in the side bar you’re given links to previously viewed products.

Could this be done?

Thanks
Lee

Bloke · 2008-06-11 13:40:46

lee wrote:

So for example if I were building an estate agent site, like I am, there could be a remember this property button on each property page and then a view previously viewed properties page where they could be a list of these properties.

Exactly. It’s like cookies, but more permanent. The thing you have to remember with this (at the moment, until I add temporary sessions) is that the variables all have to be named. The names can vary of course based on info in the current article (a custom field for example, or something off the URL line) but you must be able to refer to the variables by name later in order to read their values.

So, for example, you could not hard-code on your page a variable called proplist if you intend to build a list of properties a visitor has flagged for later comparison. Because if two visitors were viewing the same page they’d fight over the variable name! When I implement temporary sessions there’ll be the concept of a ‘prefix’ (for want of a better word) so that all variables from a particular session/browser are kept together and treated as a group if you wish.

Or another example could be like on Amazon where in the side bar you’re given links to previously viewed products.

Yes. This one would benefit from using ign_password_protect or mem_moderation so the functionality is unlocked when a user has an account and is logged in. Then you can simply store variables that are prefixed with that user’s login name so they can be easily distinguished.

The plugin’s quite raw at the moment in terms of functionality but it’ll get some serious nitro over the coming weeks when my head’s stopped spinning enough to decide the best direction to take this. Also works best under an SVN copy of TXP so you have the new parser and <txp:variable /> to play with too :-)

lee · 2008-06-11 13:44:49

Thanks Stef, I’ll have a play and se what I can do with it. I’m in Cov next month (I think) if you fancy a meetup/beer let me know.

Cheers
Lee

Bloke · 2008-06-11 13:47:26

lee wrote:

I’m in Cov next month (I think) if you fancy a meetup/beer let me know.

Sweet. Sounds like a plan to me. When you know for sure, drop me a line. I’m away quite a bit next month myself but with luck there’ll be some overlap.

mrdale · 2008-06-11 15:04:00

Bloke: Just trying to wrap my brain around uses for this plugin…

Could I use this plugin to solve the following scenario. I want to allow selection of articles from a list of article titles via checkbox, to display full articles after the form is posted?

Bloke · 2008-06-11 15:47:32

mrdale> yes, but it’s probably overkill in this case because you’d have to know how many variables to read from the form results, then store them all and retrieve them straight away.

What you need is the (in development) companion smd_each tag. If I can iron out the functionality, that will iterate over pretty much anything you can get your mitts on, either from smd_vars or from the URL line (or a TXP field) and chuck the items at a form so you can do what you damn well like with them. The variables that get passed to the form (or containing doohicky) can be filtered by name or value or both. They can even be collated and quoted (like images in smd_gallery) so you can make up lists. I believe a lot of tags now (or will soon) accept lists of IDs, so that is probably what you’ll want to do. You can collate all the matching variables into a comma-separated list and then in your foreach form you can put an article_custom id="{value}" and that’ll plug in all the checked articles.

The limits are virtually limitless. You could store or append each matching thing to an smd_var, or put them in a txp:variable. You could filter them further using smd_if then perhaps build a query to throw at smd_query or plug each value into an SQL stub in an smd_var.

I’m sure you can a) find completely radical uses for this, or b) break it :-p

Watch this space.

net-carver · 2008-06-11 16:31:33

Bloke wrote:

The limits are virtually limitless.

Wow — ROFL Stef! Limitless limits. What routine could you possibly write to top that?

Seriously though, smd_each sounds like a neat tag.

mrdale · 2008-06-11 16:45:41

Stef ‘n Steve> Ah… yeah, like… I watched the space and nothing happened…

LOL. seriously great news. I’m not sure, but one of these days my smd/sed/etc plugin code will overtake my txp installs in size…

Last edited by mrdale (2008-06-11 16:53:45)

lee · 2008-06-11 23:39:37

Stef, how can I put the current article id into smd_var_put value=”“

Cheers
Lee

Textpattern CMS

Textpattern CMS support forum

#16 2008-06-08 10:43:21

Re: Semi-persistent general storage plugin

#17 2008-06-09 09:44:38

Re: Semi-persistent general storage plugin

#18 2008-06-11 10:57:03

Re: Semi-persistent general storage plugin

#19 2008-06-11 11:14:48

Re: Semi-persistent general storage plugin

#20 2008-06-11 12:55:31

Re: Semi-persistent general storage plugin

#21 2008-06-11 13:12:25

Re: Semi-persistent general storage plugin

#22 2008-06-11 13:23:23

Re: Semi-persistent general storage plugin

#23 2008-06-11 13:40:46

Re: Semi-persistent general storage plugin

#24 2008-06-11 13:44:49

Re: Semi-persistent general storage plugin

#25 2008-06-11 13:47:26

Re: Semi-persistent general storage plugin

#26 2008-06-11 15:04:00

Re: Semi-persistent general storage plugin

#27 2008-06-11 15:47:32

Re: Semi-persistent general storage plugin

#28 2008-06-11 16:31:33

Re: Semi-persistent general storage plugin

#29 2008-06-11 16:45:41

Re: Semi-persistent general storage plugin

#30 2008-06-11 23:39:37

Re: Semi-persistent general storage plugin

Board footer