ryan

New post: New PW website ready

Recommended Posts

17 minutes ago, adrian said:

My only other thought is when would you want to actually set a field value to a formatted version? Could setting always apply unformatted values?

You wouldn't ever want to set a formatted value, but for a lot of cases there's no easy way for PW to detect if value X being set to field Y is formatted or not. Think of scenarios where the value being set to a field is some variable that has been built up earlier the dev's code. If the formatted value is a different type of data than the unformatted value (e.g. object vs string) then maybe PW could detect that but there are lots of cases where the formatted and unformatted values are both strings but with one or more textformatters applied to the formatted value.

I think we need another nice verbose documentation page explaining output formatting because it's definitely not a simple thing to get one's head around. 🙂

  • Like 2

Share this post


Link to post
Share on other sites
10 minutes ago, adrian said:

I have an interesting scenario for you though. Say you try this:

image.png.f0deaf8fe6b7656fad3833ff532e85ec.png

It's sort of breaking a cardinal rule in the first line though. If people overwrite core API variables then confusing error messages would be just the beginning of their troubles. 🙂

  • Like 1

Share this post


Link to post
Share on other sites
2 minutes ago, Robin S said:

It's sort of breaking a cardinal rule in the first line though. If people overwrite core API variables then confusing error messages would be just the beginning of their troubles. 🙂

Of course, but even if you haven't overwritten $page, if you are using page() and you get a message to do $page->of(false) it is still confusing.

  • Like 1

Share this post


Link to post
Share on other sites
5 minutes ago, adrian said:

if you are using page() and you get a message to do $page->of(false) it is still confusing.

True. Although the code suggested in the message would still resolve the issue so long as you haven't overwritten $page.

If things go in the direction that I think Ryan has hinted at of the Functions API being the new default approach then maybe we'll see message references to API variables start switching over to the Functions API equivalents.

  • Like 1

Share this post


Link to post
Share on other sites

I have mentioned this one before, but I think it's weird that we have a $urls variable, but not a $paths variable.

With the functions API we actually have both urls() and paths() which seems like a weird inconsistency to me. Is there a reason for no $paths variable?

Even the docs (https://processwire.com/api/ref/functions/paths/) suggest:

// basic usage
$paths = paths();

 

  • Like 3

Share this post


Link to post
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

  • Recently Browsing   0 members

    No registered users viewing this page.