Eeewww...

Ugglissimo. I wouldn't mind if you deleted this series of comments to save embarassment; that would be a major step backwards, and I do mean major. Are you guys all so young, and so CS-oriented, that you never worked with database report languages like Informix's ACE, and haven't even heard of RPG?

For that matter, what about your "legendary" commitment to de-geeking your user interfaces? It had to be compromised to a degree to get something as useful as these plugins (Reporting, Scaffolding et al), and I'm grateful that you did it, or I'd have torn all my hair out by now. But you needn't compromise it further for this.

This problem was canned decades ago; as a C programmer on Unix systems 20-odd years ago, I earned the gratitude of the former mainframe-applications people I worked with on one project when I created a simple library routine that took an ordered list of structures with pointers to the sort fields and functions to call when their values changed – they were relieved that finally, someone had given this dark and dangerous world of lower-case programming languages, pointers and serial terminals some of the comforts of home they had enjoyed for years.

Enough chastising and bragging (especially since it may just be based on misunderstanding you ); it's very simple – put all that variable glop inside the plugin:

• create a new macro, e.g. {break-header}, with the sort field's keychain as a required parameter, whose body will be rendered as the heading text before the next record just as {report-header} does before the entire report.
  • Some thought may need to be given to how to specify the behavior in a {report-table} context.
  • perhaps an error should result if the key does not appear in an {xxx-sort} macro call in a reporter currently in context...?
• wherever individual records are output, arrange to keep copies of the {break-header} key values and, starting from the highest-level sort key:
  • compare to previous value
  • if different (not necessarily in this order):
    • store the new value
    • render the associated body
    • clear the value of the next-lower-level sort key to force it to do the same

Simple, n'est-ce pas? As a little bit of syntactic sugar for further de-geeking, create yet another macro to do nothing but create an alias for that cognitive offense you call a keychain - possibly nothing more than something that creates another temporary keychain with a non-required prefix (checking first to see if it duplicates an existing one) so as to pass Radeox's syntactic gates into macro-parameterland without getting shredded. Maybe make a version with a body, and you can even fulfill your masochistic death wish for arbitrary variable declarations, although now that I think of it you've already got that with scaffolding {xxx-data} macros, 'aven'tcher?

A final note: My question about referring to referring to a path back from a key value to objects that contained it may have thrown you off – my approach to a solution entailed a report that began by listing only ZIP codes, which would (hopefully, though experimentally it seems otherwise) render the report body only once for each distinct ZIP code value. From there, I would attempt to use {report-on} to set the context to that report item, but of course there was no user associated with that value...

Thanks, that seems to work, although I'm getting the same issue I was getting with report-info in that some variables work, some do not.

I have a page that is referencing 10 eval-data variables from another page. 5 work correctly, 4 return no values at all and the other returns an incorrect value - this particular one is a combination of two of the other referenced variables which is evaluated in the source page correctly, but in the reporting page it seems to be treating one of the underlying values as zero.

This is very frustrating - any help would be appreciated.

Thanks David

The expand-on option works after a fashion, but it creates a separate row in the report-table for every sub-item - what I'm trying to do is loop all the items in ActionProgress in one field within the report-table row, so I get something like:

Hi David

 Thanks for the quick response. I tried both suggestions and neither seemed to work?! They returned nothing? I am running 2.6.0 ... am I missing something else?

This is what my code looks like:

{report-block}
{content-reporter:types=page}
{content-filter:label=open-issue}
{date-sort:content:creation date|order=descending}
{content-reporter}
{report-body}
{div:style=padding:3px 0px;border-bottom:1px solid #F0F0F0}{report-image:content:icon}  {span:style=vertical-align:top;}*{report-info:content:title|link=true}*{span}\\       {span:style=font-size:7pt}Posted {report-info:content:creation date > date:"dd MMM yyyy"} by {report-info:content:creator} | *{report-link:content:url|postfix=#comments}{report-info:content:all comments > collection:size} Comments{report-link}* {report-info:content:all comments > collection:last > content:creator > user:full name}
{span}{div}
{report-body}
{report-block}

Many thanks

M

That would be it, we don't have the plugin. I guess it is not compatible with 2.8.
Is there any other route I could take, so I am able to pull metadata into a table?
Thanks,
Crystal

That did it. Thanks!