Jump to content

Field set to unique in table


horst
 Share

Recommended Posts

@Peter,

Isn't that what selectors are about? :) Including and excluding things? If I am getting results that include things I don't want, I have various options to exclude them. PW provides various means to exclude them by very finely tuned selectors - name, parent, child, etc...I would add the trash check; it's simple and effective and will give me the peace of mind that trashed pages will not be returned :)...then again, this is just my 2 cts. :D

  • Like 1
Link to comment
Share on other sites

Dear Kongondo,

I'm fine with including a trash check. This thread has simply been a process (no pun intended) of clarifying the usage and documentation on the behavior of get().

I think the documentation (even on the wonderful cheatsheet) should state something like:

* get() never looks in the trash unless:

a) you use include=all, or

b) your only selector is looking for a page id

Then we won't get tripped up by assuming otherwise.

But now I'm wondering if a find(id=$id) will also look in the trash.

I'm *loving* ProcessWire: don't get me wrong. It's a joy to use.
 

Thanks to all...

Peter

Link to comment
Share on other sites

You make it complicated where it isn't. I agree it can be confusing if you're not experienced working with PW, but it's as Ryan said we hardly ever need to think about it.

But I have to agree with Peter that Ryan mentioned something above which add to the confusion of the confusion even more in that it isn't exactly true or not including all infos (which seems natural to him or us)

  Quote
$pages->get() or $pages->find() are not going to include pages in the trash unless you specify an "include=all" or one of the high status levels. $pages->get() is different from $pages->find() in these respects: $pages->get() only ever returns 1 page. $pages->get() bypasses access control and will include hidden pages. You don't need to specify "include=all" to $pages->get(); unless you want to retrieve an unpublished page or a page from the trash. If there are times when you want a $pages->get() that performs exactly like $pages->find(), except only returning one page, you can do this:

This is not really the case:

echo $pages->get(1733) . "<br>";
echo $pages->find("id=1733")->first(). "<br>";
Will both return pages from the trash! Event the find. No include=all needed.
 
BUT, what what Ryan maybe wanted to say there is that when using get or find with a selector like a usual:
$page->get("template=basic-page, isactive=1");
or a
$pages->find("template=basic-page, selected_page=1002") 
... will never return a page from the trash, unless you add a "include=all"! 
 
A $pages->get(1733) is much like saying "SELECT * from pages where pages_id = 1733", will return the page no matter what. So is a find("id=1733")->first();
 
It feels kinda natural and after using PW API for some time you'll never ask again. But have to agree it can be confusing for people... wait till you start coding modules where there's also no outputformatting and not access aware!
 
If you have some case where you really want to make sure you don't want a page from the trash, just add a check like ryan showed above, or add a status selector.
  • Like 2
Link to comment
Share on other sites

Dear Soma,

I appreciate your input; thanks.

To summarize then, I believe that you're stating that both get() and find() return items from the trash when the only selector is the page id?

Is it thus correct that with all other types of queries, those functions do not access the trash unless include=all is specified?

I think that the real issue here is that the trash is seen by many (or maybe just me?) as a walled-off area of "deleted" records that will never be accessed by regular code statements. In my opinion it makes programming much easier to think that the trashed items are in a protected silo that you have to make special effort to access.

Based on that concept, one can program away, confident that no matter what one's syntax, the trash will not be accessed, unless specifically requested.

I think that's *much* cleaner, in terms of design and real-world usage.

Ryan, what do you think?

Yours,

Peter

Link to comment
Share on other sites

Maybe you want to inform the user that the page actually has been deleted and you would anyway use:

$p = $pages->get(1001);
if($p->isTrash()) {
    $wire->error("This page has been deleted by " . $users->get($p->modified_users_id));
} else {
     ...
}

YOu don't have to check the if the user is in the trash because users can't be trashed, but maybe he also got deleted...

Building a webapp as it sounds you're doing there's actually quite a lot of scenarios you got to cover. THe issue is kinda made by you :) but I get what you're saying and it's a valid consideration. WIth the possibility that Ryan says different and think it's a good idea... I think I'm not sure if changing it will break backward compatibility, even maybe rare. But I think it really doesn't matter that much and don't see how it would change much. I think you're the first even questioning this (not that it says something bad about it)

edit: damn wrong button, had to finish the post first sorry :D

Another example maybe more real world

$p = $pages->get(1001);
if(!$p->id) {
    $wire->error("Sorry, this page has been deleted already!");
    return false;
} else if($p->isTrash()) {
    $wire->error("This page has been trashed by " . $users->get($p->modified_users_id));
    return false;
} else {
     ...
}
Link to comment
Share on other sites

Dear Soma,

Thanks for those examples. They're certainly options, to tell the user that a page is in the trash.

> I think you're the first even questioning this (not that it says something bad about it)

I've heard that before, more than once. :-)

If Ryan is open to modifying the behavior of get() and find() when id params are used, and if it doesn't

break backward compatibility, I'd vote for that.

The only backward compatibility thing that I could think of would be if someone had coded something

like "get($id)" and *wanted* to find items in the trash.

Having get() and find() skip the trash unless specified would indeed break the code in the above scenario.

But how many coders actually *code* an app to look in the trash? It's the kind of thing that might be done

by hand, via the admin interface.

When it comes right down to it, with a web app like mine, I'll be running a script every night

(probably) that deletes the trash anyway.

Yours,

Peter

Link to comment
Share on other sites

Peter,

There's certainly nothing wrong with it but why do you use this form for internet forum postings? Seems a bit redundant and overly polite to be honest.

  On 8/31/2013 at 3:58 PM, Peter Falkenberg Brown said:

Dear Soma,

- snip -

Yours,

Peter

  • Like 1
Link to comment
Share on other sites

Then why have a trash at all? You might swell just delete pages and not trash them in the first place. I'd vote for no because I want to get the page when using get(id). It's not searching.

Link to comment
Share on other sites

Dear SiNNut,

> There's certainly nothing wrong with it but why do you use this form for internet forum postings? Seems a bit redundant and overly polite to be honest.

That's a question I've never been asked! :-)

(Of course, I'm well aware that my method of salutation is now "old-fashioned.")

So, let's see. I'll be 59 in two weeks, and have been a writer for a long, long time.

I still remember when people wrote letters on *gasp* -- *paper*...

Pop Quiz: what is "whiteout"?

From "Dear Sir", "Dear Friend" and "Dear Billy Bob", to "Hi", and then not even "Hi",

there has been a rapid Net-driven descent into what I feel is a far more impersonal method

of communication.

I don't want to become an anachronism in the Internet age, but I feel that with

the massive change in communication that has even reached the point of using shorthand

for words, such as 'u' for 'you', the beauty of language and the importance of courtesy

are in danger of being discarded.

You see it on TV all the time. Someone will be talking on the phone and then hang up without

saying, "Bye." I always think, "Those lazy script writers are destroying etiquette."

Digging deeper, it's not just courtesy and etiquette that are important, but the underlying qualities

of personal care, respect, kindness and compassion that are communicated between people.

Thus, I'm holding out as long as I can, treating email and forum posts the way I would a letter,

working hard to put my finger in a dike that will probably give way anyway.

I do agree that one liners might not need the whole "Dear" and "Yours" thing, but for notes of

any length, I still like them.

I hope being overly polite is not rude. :-)

Yours,

Peter

  • Like 1
Link to comment
Share on other sites

Dear Soma,

> Then why have a trash at all? You might swell just delete pages and not trash them in the first place. I'd vote for no because I want to get the page when using get(id).

> It's not searching.

I think the trash is very important. I'm just suggesting that it should exist in a programmatic silo.

But... I'm the new guy, so I respectfully rest my case. :-)

I'm glad that the details could be clarified, and will now simply add a param to not look in the trash.

Yours,

Peter

Link to comment
Share on other sites

  On 8/31/2013 at 3:58 PM, Peter Falkenberg Brown said:

The only backward compatibility thing that I could think of would be if someone had coded something

like "get($id)" and *wanted* to find items in the trash.

That is exactly the thing I am doing with Trashman: https://github.com/apeisa/Trashman/blob/master/ProcessTrashman.module#L124

I understand both "sides" of the discussion - both opinions are valid so it is matter of having one way and stick with it :)

Link to comment
Share on other sites

Dear Antti,

I understand. Sounds like there's too much potential to disturb legacy code.

I think I may create a var that contains a query to skip the trash, e.g.

$skip_trash       = "parent!=$config->trashPageID";
 

and then add $skip_trash to many, or all, of my gets and finds, just for peace of mind.

In terms of the above query, since the trash can contain subsections, and thus 'trash'

is not the parent of every page in the trash, do you think the query should be:

$skip_trash       = "rootParent!=/trash/"

in order to make sure that all trash pages are correctly identified?

Peter

Link to comment
Share on other sites

Dear Antti and Soma and All,

I created a variable:

$skiptrash           = "has_parent!=$config->trashPageID";
 

Then, in my query, I use:

$check_page    = $pages->get("id=$some_page_id, $skiptrash");
 

It seems to work, and I'm under the impression that one can use

has_parent != ID

to say that the page does not have the trash id anywhere in the trash tree.

Thus, it's explicitly stating not to check in the trash.

Is there a better way to put this into a query, or will this do the trick?

I understand Soma's recommendation to check the status of the found page after the query,

but I'd like to skip the trash in the query itself.

Yours,

Peter

Link to comment
Share on other sites

Any selector added to the id=id will work except include=all. It doesn't really matter what as it will ignore anything in trash anyway.

(1001 is in trash)

"id=1001" // will return the page if exists, bypassing a find "search"

"id=1001,status=" // will search and return the page if exists, except if in trash

"id=1001,status>".Page::statusTrash // ditto, even though the status says only pages in trash

"id=1001,parent=" // ditto

"id=1001,template=" // ditto

"id=1001,parent=7" // ditto

"id=1001,has_parent!=7" // ditto

As Ryan stated get and find searches will never return pages from the trash. 

As soon as there's another selector found, it will do a pagefinder search and exclude trash and others that are not accessible by the user.

So apart from it doesn't matter you could add a:

",status<" . Page::statusTrash

Instead of the variable to add to all those get(id), you could create a function to search for a id exluding trash.

// at the beginning of you template output, or something like _init.php
$pages->addHook("getPage", null, "getPageNotTrash");

function getPageNotTrash($event){
  $id = (int) $event->arguments(0);
  $event->return = wire("pages")->get("id=$id,status<" . Page::statusTrash);
}

// in your templates use
echo $pages->getPage(1733)->title . "<br>";

But I'm still with my code previous, to check for if the page is in trash and trow an error.

Link to comment
Share on other sites

Thinking about that you seem to have your app mainly working under "/members/". Why not just add that?

$pages->get("/members/")->get("id=1733");
$members = $pages->get("/members/");
$members->get("id=1322");

And you don't have to care about trash.

  • Like 1
Link to comment
Share on other sites

Dear Diogo and Soma,

Diogo, this line:

$skiptrash = "parent!=7";

doesn't take into account that in the trash, you can have grandchildren records, so the parent

might not be /trash/, which is why I used has_parent!=.

Although the syntax of has_parent!= seems confusing to me, since has_parent= looks for a

specific page in the ancestral tree, whereas != could mean that it has any non-trash parent,

rather than the fact that the trash page does not exist. The boolean logic with the wording of

'has_parent!=' is muddy, to me.

Soma, your comments above are very helpful, and those are some great ideas.

Kind of like Perl: "there's more than one way to do it." :-)

At least to me, this discussion has been very helpful because it exactly clarifies

the behavior of get() and find() in a way that was not clear to me before.

Perhaps a brief note about the behavioral change of get() and find(), when only

an id query is passed, could be added to your wonderful Cheat Sheet.

Thanks once again!

Peter

Link to comment
Share on other sites

Peter,

I think what Diogo meant to say is that this:

$skip_trash = "has_parent!=$config->trashPageID";

could probably be (more efficiently?) replaced by this:

$skip_trash = "has_parent!=7";

Unless Ryan has one crazy morning, the ID of trash will always be 7 :):D

<aside>Peter, any reason why you don't take advantage of the forum's inbuilt code highlighter? ;):D</aside>

Link to comment
Share on other sites

Kongondo, I don't think that is wise optimization to make. Although trash page id is not likely to change (at least on site on production, but might be different between site profiles etc), there is no real speed gains and doing that way you should at least comment what id=7 is.

Link to comment
Share on other sites

Dear Kongondo,
 
I agree with Antti, that codewise, it's safer to not assume that the ID of the trash will always be 7.
 
And... you asked,
 

  Quote

Peter, any reason why you don't take advantage of the forum's inbuilt code highlighter?

 
Because:

$ignorance != $bliss;

I just didn't even notice that there little icon. Zowie. :-)

I thought that icon meant, "go into HTML mode".

One learns something every day, and thus draws closer to coding bliss.

Peter

Link to comment
Share on other sites

  • 4 years later...
  • 4 months later...

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

×
×
  • Create New...