Don't know if I can ask this app design question in a reasonable way, but here goes... This page basically shows a single record. Thing is, some of the data fields aren't just simple values, they're essentially an array or query with id and title fields, maybe other stuff. It's not as simple as each sub-part of the page asking for its own separate data, because some aspects of the page need to look at multiple "sections" of the data. It all has to be available to the whole page. How would you return that data to the page renderer, in what sort of structure? For instance: 1. Main query, plus a sidecar struct containing a query or array for each of the complex-value columns. 2. Main query, some of whose columns contain that complex-value data directly. Is it evil for a query to have columns with complex data? That feels more sensible to me than a separate sidecar that has to be separately referenced and/or passed around. Thoughts?

Does your query return multiple records? Does the complex data directly correspond to each record?

On this page the main query is one record, possibly two. Some other parts of the app return multiple rows, but the theory is we don't need the complex bits in those cases. For each row, there are 5 columns that may have their own complex-value data. Make sense?

like this?

1record = {
  "column1": "simple value",
  "column2": {...} 
  "column3": [...] 
}

yeah

I think you'd have to show us some page rendering code

I don't think it's inherently wrong for a query to contain complex data. A query is just one way to organize it.

I'm not serializing or converting to arrays of structs, no reason to at this point. The main query is a normal cf query, and somewhere in the neighborhood I need the complex pieces.

Stop describing the requirement as a narrative. Show actual examples of what you need. Example with simple value Example with complex value Example with complex value variant etc

@Dave Merrill it doesn't sound like you have an issue providing the data to the edit or view page. Sounds like you have an issue coming up with a table grid that can be used for read-only or editing. Are you trying to render everything server side with cfml or are you passing this data to the browser so that javascript can render the form elements?

Or are you simply asking how to pass the data to the view? That seems like too basic a question to be asking, so I am bemused. How is the answer anything other than:

yourViewContextOrHoweverYouProvideDataToTheView = {
    fooRecords = someQuery,
    sideBarStuff = whatevs,
    maybeASubTitle = "Here's some stuff"
}

Rendering is cfml. Edit page and the 2 flavors of view page are all separate cfms. The method to get the data is the same for all 3, with an arg to say it wants just IDs or the actual complex data. What I'm pondering is what the data should look like for the complex case. @Adam Cameron I heard your question, but I'm not going to try to communicate the rendering stuff here, that's not the point, and it can be written to handle the data in whatever form I settle on.

Or is

fooRecords

just a single record, and this is a detail page, and... some of the detail values are complex values? Like:

Name: simple value for name
Address:
    This
    Is
    An
    Object
Favourite colours: ooh, it's, an, array, this, time
Etc

Oh, then the data can look like whatever you like. As long as it makes sense to you.

Reading back, this seems more like it. So you pass the view an object like

{
    name = " simple value for name",
    address = {
        street1 = "This",
        street2 = "Is",
        city = "An",
        country = "Object"
    },
    favouriteColours = ["ooh", "it's", "an", "array", "this", "time"]
}

@Adam Cameron that last is what I'm thinking, except that's one row of a query, with the complex data as columns in it. That's as opposed tp the query having only simple value columns, and there being another sidecar struct passed in with the complex stuff. And yes, the rendering stuff knows or will know how to cope.

I would not use a query for this

Why go to the extra step of converting the data into another form? Because it IS evil for a query to have columns with complex values, maybe even another query?

nothing evil about putting any sort of data in query object.

The rows are totally similar. It's just that some of the columns contain text or ints, and some contain q query.

It's semantics / idiomatic code / clarity of code. Someone seeing a query is gonna be thinking "multiple rows"

Honestly, your data structure, if you add everything the pages need, is not even that complex.

@Daniel Mejia yeah, I just meant complex in the !isSimpleValue() sense.

One should not think "oh I can just sling this thing in here, it'll kinda work [shrug]". One should think "what's the appropriate data structure to use here"

Agree. That's why I'm thinking and talking about it before committing to The Plan.

There's also a consideration of keeping your code loosely-coupled. Just cos a query is the "right" sort of object to receive single-row data from a DB call, doesn't mean it's the "right" sort of object to provide data to a view. A view that renders key/value pairs wants an object or a struct

To me a query is a fine "type" here, it's just that some column values aren't text or ints. Say I wanted the texts of the checked checkboxes, like for a viewer page. The query column could return that as a cf list. UNLESS some of the values contain commas, in which case an array or a query makes more sense.

I really would not ever use the CFML concept of "lists" as a collection type. Use the list functions for transforming strings to arrays and back again, but don't consider a list as a type. Makes for shit error-prone code.