mindplay.dk

Templates need to be aware of context either way - this way, you can actually do a simple check to see if a context was provided at all: isset($data) - plus it makes it easier to pass the entire context on to another child-template.

Possibly what makes the most sense, is to just pass one variable? The developer can pass an array or a single string, or an object, e.g. for strongly typed view-models if wanted. If you did want to pass an array and have it extracted as local variables, all you'd have to do is call extract($data) in your child-template - it's not a lot of work...

My problem is this: class Collection { public function save() { if (conditions) { onBefore() doStuff() onAfter() } } } Because the event system already uses the before and after concepts, it gets confusing - the above could be simplified as: class Collection { public function save() { if (conditions) { $this->doStuff() } } } Because I can already hook doStuff() both "before" and "after", you just need an inner and an outer method. "ready" is just a synonym for "before". You said yourself, it doesn't matter if you hook those "before" or "after", because nothing actually happens inside them...

Looks like added() and saved() are both being called on save() ? It's a bit confusing with the high number of events - I can't imagine I'll need all those? I'm really not a fan of the word "ready", it's meaning is never really clear - ready for what? ... is it a good idea to have so many of these "vestigial" methods? I think I'll just take a stab at this working from the current code in Git - and then see if I need any new events, how does that sound? I'd rather not bear the guilt of making you muck up your elegant tidy codebase with all this junk just for my sake

Okay, I did some work on this today - adding, updating, renaming, deleting and changing the type of Fields now records and repeats. I have only done some superficial testing of this: created and deleted some fields, changed properties on various tabs, renamed a Field, deleted one, and was able to repeat all of those actions, without problems. Tables were correctly created, renamed and deleted during those operations. I'm impressed with how robust ProcessWire is in this regard - because the important stuff really does happen at the API-level (rather than in controller/action methods) all the operations are easily repeatable and the results appear to be consistent Nice work @ryan ! Now, there is one thing that concerns me. $this->addHookAfter('Fields::load', $this, 'hookFieldLoaded'); $this->addHookAfter('ProcessField::fieldSaved', $this, 'hookFieldSaved'); $this->addHookAfter('ProcessField::fieldAdded', $this, 'hookFieldAdded'); $this->addHookAfter('ProcessField::fieldDeleted', $this, 'hookFieldDeleted'); $this->addHookAfter('ProcessField::fieldChangedType', $this, 'hookFieldChangedType'); I'm hooking into Fields::load to obtain a copy of all the Field properties before any changes can be made to these. But in order to capture the changes, I had to hook into the ProcessField::field* methods, which appear to be there for the purpose of monitoring these events. My concern is that those events only fire when changes are made via the ProcessField controller - and that this is not (necessarily) the only way to make changes to Fields. (I no longer recall why I had to use the controller-level events, as opposed to hooking into the Fields collection-level events - I will investigate this further the next time I work on this.) I would really like to hear from @ryan on this one before I continue - there are currently no equivalent controller-level events for Templates (e.g. in ProcessTemplate) as far as I can tell? So currently the only option is to hook directly into the Templates collection methods.

I have been asked numerous times in the past to upgrade various projects from GPL2 to 3, and have willingly done so. My policy has always been quite simple - there is only one scenario where I could picture enforcing my legal rights: if somebody were selling my product (or a derivative product) and passing it off as their own. I feel comfortable that both GPL2, GPL3 and MIT protects me in that situation. Other than that, I don't really care what people do with my software. Simple I think, at the end of the day, precisely what license is used probably matters more to the consumer than to the vendor - and for various reasons, consumers seem to prefer GPL3 or MIT.

It's how most view-engines work, I suppose - the render() method usually takes the name of the view and the data to render. I'm not sure precisely how we would get around the fact that numerous variables are already in scope by default, however? If you pass array('page'=>'foo') will the "real" $page get overwritten? do you lose that variable? or do you get an Exception? Perhaps better would be to pass additional view data as a single variable rather than extracting it before rendering? e.g. $view or $data or someting?

Do you think it would make sense for the render() method to also accept a second argument: an array of values to pass to the template of the sub Page? As explained, I'm really not keen on adding transient values to Page objects - which would be (and currently is) the only other way to pass options to sub-templates...

To clarify, by "parent template", I simply mean the template of the Page object that was dispatched - and by "child template", I mean the templates of any other Page objects related to the parent. What I'm currently doing, is either rendering child content directly from within the parent template, or using include/require to pull in an include file used to render a child template. What I'd like to be doing, is simply loop over child Page objects and call render() - as explained, that rarely works, because child Page objects usually are a full page; they're not designed to render inline - with the exception of things that are strictly child Pages, never themselves rendered as a parent, i.e. never dispatched directly.

I've heard recently that a few projects are moving from GPL v2 to MIT licensing - there was a long discussion and it looks like Twitter is moving Bootstrap from GPL2 to MIT.

Many other projects are upgrading from GPL version 2 licensing to version 3 these days. In order to be legally compatible with other GPL version 3 licensed libraries, maybe it's time for ProcessWire to consider upgrading?

I don't like the idea of overwriting any persistent property with a transient value, in any model. It's just extremely bad practice. Having the ability to specify the template on render makes more sense - after all, you're not changing the template of the page, you're changing which template gets rendered. Not the same thing, unless you also plan on calling save() for some odd reason

You can already pass parameters to child templates - it's also possible for child templates to look at their parent template and obtain information from there. So I think there are already enough ways to communicate between templates. (Myself I use a global Document object that carries metadata and other things that need to be accessible/shared between templates, as opposed to adding data to Page objects - which feels dirty to me, since Page objects are persisted; I've never held any love for mixing persistent and transient data in the same object.) What I'm looking for, is a way to avoid having that conditional logic in the child template - and instead, having that control in the parent template. And of course you can do that with include() or require() now, but then child templates don't run in an isolated scope - variables from the parent template become accessible to the child template, and the child template can overwrite values set by the parent template, which is error-prone... render() ensure each page executes in it's own scope, and lets you be explicit about what you want to access or share and when...

Hmm, one good observation there, is the fact that, even if there was a way to have multiple views for a template, you still need to select them somehow - so, as a minimum, you would still need something like $subpage->render('subview') which is really just indirectly specifying the view. Which negates the value of defining it via the admin interface, as you would still need to change the template - or add a view dropdown to the page reference field config, as you suggested. I think that starting down that path, this can grow out of proportion to the benefit you get from this, very quickly, so I'm starting to not like this idea so much. However, what do you think about the following simple solution: have the render() method take an optional argument specifying a relative path, from the current template file? So if your template file is "blog/view.php", calling render('author.php') renders "blog/view.php" - while an absolute path such as render('/blocks/author.php') is "absolute" from the templates root-folder. How does that sound?

I agree that this can already be done with code - no question. To use a practical example, let's say we have two templates, "author" and "blog-post". The "blog-post" template has a reference field, crediting one or more authors for the post. An "author", when rendered as a page, is going to display detailed profile information about the author, and maybe list his most recent posts. A "blog-post", when rendered as a page, is going to display who the authors are, but probably in a short summary format. Now currently, the way I would implement the template for "blog-post", is I get the list of authors, and I loop over them inside the "blog-post" template. As opposed to calling $author->render() for each author, because that would render with the full template with all the details and listing other posts. So you've got the "blog-post" template now in charge of actually rendering bits and piece of "author" pages, but not using it's template, and avoiding the render() method, because it renders a full document view, where in this case, all I want is a partial. What I'm seeing, is that you actually have multiple views of the same information in different contexts. Let's say we also have an "article" template, which also has a list of "author" references - now I can either duplicate the snippet of code that renders the authors in the compact format, or I can move that code into an external include file, e.g. a separate view. But there's currently no way to formally associate an alternate view with a template. Another example would be a template that requires two different views - for example, an "article" template might have both a "teaser" view and a different (default) full article view. Currently, we can model that with an extra URL argument, and an if/else statement in the template, making the decision about which view to render. But again, there is no formal way to associate the alternative view(s) with the template. I'm not saying there has to be - it just seems like a rather common requirement, and possibly one of those things where it might be beneficial for a non-programmer (designer) to be able to add multiple views for a template, without having the programmer (me) become a bottleneck in those situations...

This may be another one of those ideas that are answered mostly along the lines of "you can already do that by..." - but I'm going to post it anyway, just to see what you make of it. I wonder if it would make sense to support more than one view (php file) for the same template? Currently, php views/files are tied 1:1 to Templates - I realize you can tie more than one Template to the same file, but what I have in mind here is the opposite: tie more than one file to the same Template, and make it optional which one to render. So with this change, $page->render() would render the default view, and other named views could be rendered e.g. using $page->render('summary') which would be useful for example when you're rendering related pages (e.g. from a page selector field) from within another view, as these are typically not displayed in the exact same way as when they render on a dedicated page. Thoughts?