Jump to content

ProcessWire.rocks! My youtube channel ?


bernhard
 Share

Recommended Posts

Hello @bernhard! Thanks for sharing!

10 hours ago, bernhard said:

Do you think it is better on the latest video? 

Great and informative. Though, for complete newcomers to PW it might not be detailed enough, but if someone does not understand something then they can always ask :)

BTW, your init() method is not static. Is there a reason for that? Since $pages->get("template=quote")->init(); returns the first such page PW finds, it does not matter which page is that. If it does not matter, then a static init() method would also do the trick, wouldn't it? At least it works for me that way, too.

This init() method of yours does not initialize a page object as such, instead, it can be used to organize code which attach hooks related to the template class in question, and not related to a particular page (object). When dealing with a page object in the hook's functions, then that is a different matter, of course. Or is there anything else that (apart from attaching hooks) you sometimes put in this init() method?

 

  • Like 2
Link to comment
Share on other sites

1 minute ago, szabesz said:

Great and informative. Though, for complete newcomers to PW it might not be detailed enough, but if someone does not understand something then they can always ask ?

Yeah it's hard to provide informations if you don't know who is watching... there might be total newcomers but some things might also be interesting for advanced users... Not sure how to tackle this...

2 minutes ago, szabesz said:

BTW, your init() method is not static. Is there a reason for that? Since $pages->get("template=quote")->init(); returns the first such page PW finds, it does not matter which page is that. If it does not matter, then a static init() method would also do the trick, wouldn't it? At least it works for me that way, too.

Hey @szabesz not sure what you tried, but I don't think that this can work. If you define a method as static you can't do object-related things inside this method. My IDE instantly throws an error:

T7RsE0W.png

Static methods can be helpful for things like string-manipulations (eg Paths::normalizeSeparators()), but as soon as you need to work with objects (like pages and the wire object to attach hooks or such) you can't use static methods.

I just did a little testing because having it defined static could have benefits, for example if there is no page created yet. In RockMigrations I solve that by creating a dummy page and saving it in the trash. Ugly but effective ? 

We could make the init static if we didn't use $this to attach the hook. But then we'd need to provide the wire instance as parameter (which is kind of clumsy imho). Also, we'd need to define the hook in a callback instead of placing it in a custom method of the pageclass (because we can't access the pageclass from a static method):

7HN40sG.png

So if we did all that, the init method would get quite bloated. Also I try to avoid defining hooks as callbacks, because they are harder to debug! See Tracy's "hooks triggered" section:

U3DISnb.png

LHKZmvt.png

That's the reasons why I put all the hooks in the pageclass's init() but make all of them a custom method in the class ? 

  • Like 4
Link to comment
Share on other sites

  • bernhard changed the title to ProcessWire Rocks! My youtube channel 😎

Didn't think of using wire() - that would work. At least until you are using Multi-Instance. Or someone else uses it that uses your code ? And you still have to define the hooks as callbacks, which I don't like because of the reasons mentioned above.

  • Like 2
Link to comment
Share on other sites

5 minutes ago, szabesz said:

What we are talking about is not a "module context", after all.

I'm using custom page classes a lot like modules. It's all about making things reusable to get more productive and to be able to increase quality step by step and not re-inventing the wheel from project to project...

  • Like 2
Link to comment
Share on other sites

On 8/30/2022 at 11:00 AM, bernhard said:

Thx for the feedback @Spinbox I'll try to do that! ? Would you need an explanation of the concept of migrations in general or would that be too much?

A short explanation would help anybody not familiar with the concept

11 hours ago, bernhard said:

Do you think it is better on the latest video? 

I didn't want to make it bigger... it feels so... strange ? 

Great stuff, this helps a lot ? Easy to understand and definitely going to start using it.

Link to comment
Share on other sites

1 minute ago, bernhard said:

I'm using custom page classes a lot like modules.

I think that is why you "mix things up". You do not need to use $this just to attach a hook in this context. We do not get access to a page object in the hooked function via $this, instead we use $event->arguments(0). This is because strictly speaking these are unrelated code bits. Sure, organizing them under the class is very useful, but even though related functions are neatly organized this way, the methods attached by the hook live in a completely different context than the ones that are meant do be called directly via a page object. I hope I could clearly explain myself...

8 minutes ago, bernhard said:

Didn't think of using wire() - that would work. At least until you are using Multi-Instance.

Are you referring to $site = new ProcessWire('/path/to/www/'); perhaps? See: https://processwire.com/blog/posts/multi-instance-pw3/#using-multi-instance-in-pw3

In that case the site instance in question must be accessed via the variable the reference is store in (via $site in this example) which is a special use-case for sure, but are you really sure that what I proposed would not work in that context? Sticking to Ryan's example, if we do $site->pages->get("template=quote")->init(); then we already got the right context, so why would putting wire() in that init() method not work which is a different context?

Again, we are merging different contexts under the same PHP "class code" and we need to keep in mind which context we are in because they are not the same.

Link to comment
Share on other sites

2 hours ago, bernhard said:

And you still have to define the hooks as callbacks, which I don't like because of the reasons mentioned above.

Yes, that is true but since the functions called by the hooks are not to be called directly on a page object, is it that important to "pretend" that they could be called like that? I never use Tracy's "hooks triggered" section. In what scenario you take a look at it, regarding your own code? I am just asking to learn from your experiences...

Anyway, if we use an object method as opposed to a static method, perhaps that method should be protected as it is not intended to be called "from outside". What do you think?

Edited by szabesz
typo fixed "to learn FROM your experiences..."
Link to comment
Share on other sites

9 minutes ago, szabesz said:

if we use an object method as opposed to a static method, perhaps that method should be protected

Asking about the method being protected was not referring to the init() method but the one provided for the addHook method, of course (the one used instead of a closure).

Link to comment
Share on other sites

1 hour ago, szabesz said:

Asking about the method being protected was not referring to the init() method but the one provided for the addHook method, of course (the one used instead of a closure).

Quote

// inside a class (if 'myHookMethodName' is a public method of class)
$this->addHookAfter('Class::method', $this, 'myHookMethodName');

Those custom hook methods need to be public.

1 hour ago, szabesz said:

Yes, that is true but since the functions called by the hooks are not to be called directly on a page object, is it that important to "pretend" that they could be called like that?

It's not about pretending something. It's about keeping the code as easy to understand and therefore as easy to maintain as possible. If you put everything into a callback than it can be quite tempting to add a little bit extra code here and there, that actually does something different. Just because you want to do some additional logic and you think: "Well, I already have the hook in place... Let's add another line of code there". For example to change the "bar" property on page save. If you already have a dedicated method like "updateFooOnSave()" then it's much more unlikely that you add your BAR change there. Or at least you get reminded that it might not be the best idea...

Hope that makes sense. Another thing you can do is to share the same logic and apply it to different hooks:

<?php
public funtion init() {
  $this->addHookAfter("Modules::refresh", $this, "resetCache");
  $this->addHookAfter("Pages::saved", $this, "resetCache");
}

public function resetCache() {
  // reset cache of whatever
}

We can do the same on newer versions of PW by attaching multiple hooks in one line, but I usually find it cleaner to be a little more verbose.

Link to comment
Share on other sites

4 hours ago, szabesz said:

I think that is why you "mix things up". You do not need to use $this just to attach a hook in this context. We do not get access to a page object in the hooked function via $this, instead we use $event->arguments(0). This is because strictly speaking these are unrelated code bits. Sure, organizing them under the class is very useful, but even though related functions are neatly organized this way, the methods attached by the hook live in a completely different context than the ones that are meant do be called directly via a page object. I hope I could clearly explain myself...

I don't think so... Maybe I'm misunderstanding your message, but it looks like you are mixing things up.

I'm not talking about using $this to refer to the current page inside the dedicated hook method. Of course, that would not work. Because in the hook method, as you have said, the context is different. And there you get the page by using $event->arguments(0) or similar. That's what I explained in the video and I never said something different. I'm just using $this in the init, because then I can be sure that I'm in the correct context. $this in init is the custom page class (or the page object), and I request the wire property of the page, which is always an instance of the current processwire instance. And then I call addHookAfter()

No mixing things up.

Inside the dedicated hook method (like "resetCache" in the example above) we are of course in the hook context. So $this would NOT be the current page there. But I don't see a problem here and I don't get your point?!

Link to comment
Share on other sites

Hm... Just had the idea that it would be nice to have the domain processwire.rocks for my channel with that name...

My channel was created on 21.07.2022, the domain is taken by someone else and has been registered on 06.08.2022... coincidence? 

who.is leads to namesilo, which shows a "try to buy" button... https://www.namesilo.com/domain/search-domains?query=processwire.rocks

that.sucks

Any ideas for a better name + domain are welcome! I guess I'll have to register a domain BEFORE starting the next channel ? 

  • Like 1
  • Sad 1
Link to comment
Share on other sites

  • bernhard changed the title to ProcessWire.rocks! My youtube channel 😎
  • 3 weeks later...

This is great stuff - I love seeing how other folks work their process and it always gives me new approaches to try. I hadn't messed with latte at all before these videos (always got stuck using smarty and twig) but the simpler syntax looks awesome. Thanks for the work you've put into these modules and the videos!

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

On 8/5/2022 at 6:44 AM, bernhard said:

What do you guys think of the forwarded sections with 200/300% speed? Is that a good solution?

In terms of cleanup? Cleaner to leave it on the floor. I think the random commentary bubbles and stock are funny though. It's hard to spice up dry material like coding, but I felt like these video have a good pace - I've watched them all through.

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

  • 5 weeks later...
  • 2 weeks 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

  • Recently Browsing   0 members

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