mindplay.dk

Wow, thank you for taking the time to answer this question so thoroughly! I love how you accept a challenging question like this - a lot of people would have taken it as criticism. I would submit though, that I do believe the real underlying strength of PW lies not in the query syntax, but in the data-model that supports it. You've sort of come up with a different kind of data-model, and I don't know what to call it, in some ways it's more like a "hierarchic document" database (not a real term) but it's not really relational - it just happens to be implemented using a relational database. The document aspects of the data-model of course lends itself well to content management, which is really data-management or document-management, depending on how you look at it. While the hierarchic aspect lends itself extremely well to the hierarchic nature of URLs. As Pete pointed out, it frees you from needing to know what the database structure is - again, I would attribute that quality to the data-model and not to the syntax. As you said, no, there is no comparison between this and a template engine - that isn't what I was trying to suggest. What I'm suggesting is that the syntax itself is just syntax: it's a string of characters that can be interpreted. The interesting thing about language, is not whether it uses parentheses or curly braces, single or double quotes - but rather the structure and instructions that those symbols express, and the functionality that they invoke. A template engine has no real value, because all it really does, is invent different structure and symbols to express essentially the same things you can already express using existing native PHP syntax. Okay, so PHP doesn't have built-in syntax for queries. It also doesn't have built-in syntax for MVC, event hooks, database access, document object models, or any number of other patterns and ideas - but (for the most part) people don't invent custom syntax for any of those, just APIs. And maybe PHP syntax isn't as convenient for something as condensed as a query API. But at the end of the day, isn't that the same selling point used by template engine peddlers? Granted, query syntax in PHP is a more extreme case of the same thing - most query APIs (that I've seen) written in PHP are not pretty. There are exceptions though - phinq for example manages to provide very familiar syntax by piggybacking on PHP itself for expressions, where other LINQ implementations for PHP (such as phplinq) usually resort to parsing strings. Of course, phinq has the luxury of just supporting native PHP data-structures like arrays - implementing efficient database-support would likely involve parsing and interpreting PHP, and then where are we going... All things considered, I think custom query syntax is probably the best approach you could have chosen for the PW query engine. The reason I brought it up in the first place, is that I strongly suspect that the day will come, when I want to do something that can't be done with the query engine. When the day comes, I will return. muhahahahhahaaaah!

@ryan I'm hoping to hear from you on this subject. I'm quoting from this article: I completely agree. I too wrote template engines in the past - and ended up not using them. But my question is this: don't these arguments work against using custom syntax in the query engine, too? As opposed to a native query builder API, the custom syntax is shorter, but at what cost? Some redundancy, some inefficiency, a learning curve - even if the syntax is great (it really is) and learning curve is minimal, for one, it won't receive IDE support, so you have to learn the syntax and symbols by heart. Other than shorter syntax - the same argument for template engines that got overruled - what are the arguments in favor of custom query syntax? I had to ask

Okay, I'm sold on that

I've added a Repeater field to a Template, and added some fields to it. Whenever I go to edit a Page using a Template with the Repeater-field on it, it shows a single item with a grayed out message saying, "this item will become editable after you save". This is on a Page that is already saved. And it never does become editable. No matter what I set the "ready-to-edit" repeater items to, I always get a single, dead item showing as that number + 1... so if I enter 3, it displays "item #4"... if I enter 1, it displays "item #2"... but no actual items... If I press "add item", I do get a user interface for the repeater item, and it does work. Except I'm always seeing this extra disabled item, even when I set the number of "ready-to-edit" items to 0...

Is anybody else missing a Description field on Templates? I've been trying to use the Label field to describe my Templates, but it really doesn't work well when you enter a 20-30 word summary of what the Template is for, or some basic guidance on how to use it, because this text appears in the drop-downs. What's more, the Label is only displayed at the time when you select a Template - if you go back and edit a Page, you don't see the Label anywhere. I think it would make sense to display both the Template Label (or Template Name when no Label is defined) and a Description of the Template somewhere, so that it's obvious what you're editing. Perhaps a separate discussion, but related to that - it would be nice if the Label (or Name) would also display in the sitemap... This would make it easier to under what's what, in a site with many different Templates.

Very good point, unfortunately.

There's something to be said for consistency with jQuery though - since it's basically ubiquitous and familiar to any developer. I would not be opposed to enhancing parent() though, I'm starting to think maybe that makes the most sense - since it already basically works like we're describing, as far as selecting a single parent... And the API would be backwards compatible, since not passing a selector would mean "anything goes", consistent with the rest of the PW API. (come to think of it, sometimes after not using JQ for a few months, I'll instinctively try .parent() for what we're discussing - it seems logical... but maybe that's just me...)

Heresy! I've been using the nose on boards, Usenet, IRC and forums for at least 25 years. Only recently have lazy kids stopped typing the nose because it's faster while texting and playing video-games. Dropping support for the nose would be like dropping support for <b> or <i>

During development of a big project? Oh yes, you did.

I'm not a fan of rootParent, and I think there's a reason why jQuery has no equivalent to that - the exact type of page you're going to get, is unpredictable. Not in the sense that you won't always get the parent below the root of course, but in the sense that the root-parent could change - because pages can be moved around. And in some cases that's what you want - e.g. for breadcrumbs... but in the "site area" situation, the site could grow, and what currently happens to be a root-parent, could become a sub-area of another new area, some day...

This forum is buggin' the heck out of me... For one, it doesn't translate standard smilies... ;-) etc. ... becomes and ;-) etc. The WYSIWYG editor itself seems really quirky and buggy. Most annoying thing so far, is the tag, which only seems to work properly when inserted by pasting into the dialog box after clicking on the toolbar... If you edit your post (or preview it) afterwards, the indentation in the pasted code is lost, and you have to delete it and click the toolbar button and paste (or type in) the formatted code again.Using Chrome here, by the way. Is anyone else annoyed with this forum software? Doesn't seem very well suited for code anyway...

Finding a parent with a particular template, typically... very useful if your site is divided into major areas, e.g.: area 1 page 1 page 2 area 2 page 3 page 4 page 5 page 6 Suppose you're on page 5 and need a title or image for that area of the site... $page->closest('template=area')->image->... etc.

Actually, my first take was an extension of parents() adding a $selector argument - it turns out that's probably not very useful, as this would potentially give you multiple parents. When would you need only certain pages from the trail of parents, skipping some of them? Seems like an edgy use-case. And if you do want filtered parents, you can already do $page->parents->filter('template=xyz') Also, if you're looking for one specific parent, there's no need to traverse the parents all the way to the top, if the parent you're looking for is closer than that - hence the function-name, closest() ...

I often need to find the closest parent Page of a particular type, and I found that something equivalent to jQuery's closest() function was not available. It's a simple addition to the Page class: /** * Return this page's closest parent matching the given selector. * * If no parent matches the given selector, this function returns a NullPage. * * @return Page * */ public function closest($selector) { $parent = $this->parent(); while($parent && $parent->id) { if ($parent->matches($selector)) { return $parent; } $parent = $parent->parent(); } return new NullPage(); } Please consider including this in the next release.