2 feature requests

Chester –

A couple feature requests, one trivial. (Of course, my [currently] most-desired enhancement is already listed as a ‘to-do’ in the changeset for 1.1.34 — namely, shortcode support for cacheImageFields — so I’ll just assume that one is imminent.)

The trivial one is to timestamp logfile entries. And, yes, I could probably add these myself, and I probably will, once I figure out how best to maintain a set of diffs to merge with your updates. (When I still struggling to wrap my head around this plugin, I started to add Doxygen-friendly comment blocks to a copy of the plugin. Then, in the space of about 18 hours, you released 3 new features and a bug fix, and I said to hell with it. ?? ) Right now, logged errors contain embedded timestamps — but, as I can attest, plenty of things that are valid Airpress definitions can still be dumb ideas, and, without a timestamp, it can sometimes be difficult to identify which user-erroneous transaction was which.

The not-so-trivial one is the sort of seemingly trivial request a good product manager could live on for a couple of months, at least. I’ll give it to you as the sheerest nub of an idea as it occurred to me, even though in that form it raises more questions than it answers.

I’m increasingly finding a need for some sort of conditional output. For instance, let’s say an item has one of four potential statuses: Status1 is a normal state, so there are no associated milestone dates; Status2 and Status3 are both transitory states, with associated ‘dateOut’ and ‘dueBack’ dates; and Status4 is an end-of-life status, with only a single significant ‘endDate’ to report. I’d like to display status information using a single chunk of screen space, displaying only dates and labels pertinent to the current status.

As I see it, currently there are two ways I can go about this. (All right, there are probably a half-dozen, of which two can be taken seriously.) The first approach is that typically recommended on the Airtable forum: Namely, create a new column in my table, define it as a function, and store within in the appropriate block of HTML, as pieced together from recursive ‘IF()’ functions. I realize I’m letting my gray roots show, here, but aside from the wanton commingling of content and presentation in what is supposed to be a database, by god, just the thought of populating so bloated a field in every record sets my teeth on edge. [Insert aimless grumble here about wanting to see one of these hotshot UX designers try and write an “app” that will run in the Small memory model’s 64kb, and what the hell is an “app” anyway? and I hope there’s pudding….]

The more sensible approach would be to build my conditional branches as a php function, possibly tied to a custom shortcode, and return the status block as a pre-processed chunk. This eliminates the need to store several thousand instances of several thousand redundant characters, and it keeps HTML out of my database, but it means I’d have to stop slacking off and try to remember how to write php. (I know I am only postponing, not avoiding, the inevitable; there will be things I can’t do using shortcodes only. I still intend to drag it out as long as possible…)

So, with that as background, here’s what I found myself wishing for last night: A simple logical test, embedded in a shortcode. Although it’s at this point the scope of this enhancement could grow astronomically, the scenario I envisioned was small and constrained to the point of being cuddly: In its current incarnation, my base includes a check-box field associated with each status. Accordingly, my immediate needs could be addressed by something as simple as this:

[apr_if field="needsClean"]{{checkClean"}} blah, blah, blah <br>[/apr_if]

In other words, if the ‘needsClean’ field returns true, echo everything to the closing shortcode; otherwise, skip everything through the closing shortcode.

Obviously, I can think of a dozen reasons why you wouldn’t want to do this — but just in case you were considering it, I wanted to place my vote….

Thanks,
maz