Jump to content

Selectors for page Field


vknt
 Share

Recommended Posts

I'm doing a questionnaire with multiple choice questions, so I built pages with different fields of the type "Page" to store the choices.

I now want to build some metrics that show how many people choose a certain option but I don't understand how to use the selectors for fields of the type pages. I can't just use "any_field=any_value" because the field holds a Page.

So what I search is something like: Find al the pages that this Field with as the selected page this ID=SomeNumber

I hope I'm a bit clear in this. Can anyone help me with this?

Thx in advance!

Link to comment
Share on other sites

Maybe looking for something like this:

<?php
$answer = $pages->get(1234); 

$questionnaires = $pages->find("question=$answer");

This assumes that 1234 is the "SomeNumber" in your example, and question is the "Field".

Probably easier version to maintain is to use paths:

<?php
$answer = $pages->get('/whois-father-of-luke-skywalker/anakin-skywalker/');
Link to comment
Share on other sites

You actually need page there when looking for page values. Good to know is that you can also put PageArray there. So you could something like this to return all :

<?php
$positiveAnswers = $pages->find("name~=yes");
$questionnaires = $pages->find("question=$positiveAnswers");
Link to comment
Share on other sites

  • 3 months later...

You actually need page there when looking for page values. Good to know is that you can also put PageArray there. So you could something like this to return all :

<?php
$positiveAnswers = $pages->find("name~=yes");
$questionnaires = $pages->find("question=$positiveAnswers");

I see many times on the forums where this 'find' feature is used... but everytime i see that successively done - i always tend to cringe - hence my question for clarification below:

"Is the above 2 liner - literally two separate queries on the dB? Or is it just a rifling thru what was already queried from the uber-query?"

Thanks.

Link to comment
Share on other sites

In that fictional example there are two find() operations, so those aren't going to happen in 1 query, unless the results of 1 are already cached. If I recall, this should work (though not at a place to double check):

$pages->find("question.name=yes"); 

But I want to point out that query counting is usually a waste of time. And I used to do a lot of it, up until I read High Performance MySQL. MySQL will execute a 100 simple queries faster than it will 1 heavy one. So performance usually has much more to do with query quality and proper indexing than query quantity. This is not the way I was originally taught, and not how I worked for many years, so it took me awhile to get it. You can always $db->query() and join the original example into 1 query, making sure that everything happens using an index, but you may or may not see any tangible benefit for your efforts. If there is some real performance bottleneck that could be resolved by querying directly, I still do it, though it's pretty rare.

Also note that layers on top of MySQL are not unlike layers on top of languages. C++ is built on top of Assembler, and PHP is built on top of C++. PW is a layer on top of MySQL and PHP. It's possible to make lower layers perform faster than higher layers, if you know your way around them. Every layer is a compromise that has to be compared against the need. I know my way around MySQL and PHP, and for me PW lets me develop stuff 10x (or more) quickly than I could without it... and it's rare that I think it's costing me anything in performance. But if I had a project where maximizing the performance out of MySQL and PHP took precedence over all other factors, then I would keep out all other layers (no CMS, frameworks or other libraries).

  • Like 1
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...