Dynamic/Selector Fields and Page creation layouts

[alevine]

This is 2 questions in one post; I hope that's permissable.

1:  I'm trying to find a way to create a field whose value is a selector query, and at page time the field runs the query.   This is very akin to http://processwire.com/talk/topic/1489-how-to-retrieve-possible-pages-list-in-a-page-field, but reducing code duplication and making it as natural as any other field.  The Page input already allows for the query/snippet to provide possible _selections_ at page creation, but not a way to harness that query's results as a field.   Am I making sense?

I've not started digging in to the fieldtypes, and I see http://processwire.com/talk/topic/4079-input-field-for-dimensions/ may be a good place to start down this path, unless there's a module I missed that already addresses this. 

2:  I've seen some screenshots where creating a new Page from a template has a nice layout to the field entries.  I am aware that you can specify the entry widths during declaration.  However, is this an adjust/reload/repeat process to get some fields grouped together on the same line nicely, or is there a way of handling the field entry layout that I'm not aware of?

If either of these questions seem addled in thought, it's me, not you.

Thanks for any help, input, and advice you may provide!

[bcartier]

Hi Alevine,

One way to accomplish this would be to use Ryan's Hanna code module. Set up a Hanna code, let's say "output_pages" to accept a selector parameter and output what you need. Create a text field that contains the Hanna code and the parameter like  [[output_pages match=template=basic_page]]. 

Hope that helps,

-Brent

[alevine]

Brent:

   Thank you for the suggestion.  I'm having issues installing Hanna code (and I've so posted on the support page), but I'm anxious to see if this is the solution that I hope it is.

Thanks again, and I'll post back with my experience.

-- adam

[alevine]

Ok, this looks like it's mostly the solution.  The piece that's missing is declaring default text at the field level

1:  hannah code to run my pages selector

2:  field declaration:  Type: Text;  TextFormatter: Hannah; Visibility: Always hidden

        -- default value??

The idea is to add this to a template so the same query is present on all pages/templates using this field.  This keeps the content creators from having to worry about adding it (or even breaking it), and I know it's there and what to expect from it.

I know it'd be easy enough to create a function somewhere to accept a page and return my page lists that I need, but what fun is that?

I'm looking again trough all the modules to see if I overlooked a way to allow specifying the default value for a field.

[alevine]

Okay, I've solved this for now, tho it does add an extra find call.

1:  Hanna only does text replacement - all you get back from a tag is text.

So, my hannah code executes the query and returns the ids in a piped list

$foundPages = $pages->find($pagesQuery);
$idList = "";
foreach($foundPages as $img)
{
 $idList .= "$img|";
}
echo $idList;

2:  I declared my field as a Concat field, with the formatting field as:

[[pages_query pagesQuery=template=template-1]]

3: My code now receives the id list, in pipes, when referencing the field, which makes a 2nd call to find all the ids that were returned.

$myIds = $page->query_pages;
$myPages = $pages->find("id=$myIds");
foreach($myPages as $targetPage)

I don't like having to make a second call to the db, as that's unecessary overhead.  I may try to dive into hanna code code (heh) and see what it would take to return the original results, rather than doing text substitution.   Ryan, any insight would be appreciated here

Thanks again, Brent, for directing me to Hanna.  It got me to 99% of where I want to be.

EDIT:  sleep always clears the head.  seralize/unserialize to prevent a 2nd db trip   I marked your answer as solved, thank you.  I'll revisit the new Page form layout question at another time.

-- adam