mindplay.dk

@pwFoo if this turns out to be a NetBeans issue, and if you figure it out, please post and let me know the solution - I can add it to the README to help others get started.

The source is on GitHub, knock yourself out https://github.com/mindplay-dk/SystemMigrations

I have a free account and only 10 shares allowed, but... I think I will migrate the project to GitHub tonight and just open-source it. I will post when it's done.

Yeah, sorry about that. I just added an "EDIT" in bold to the original post, so others can decide whether they want to read through it all ;-)

I don't use NetBeans, I use Storm, but I would be very surprised if NetBeans doesn't support basic standard php-doc annotations like @var. Maybe your IDE isn't set up to inspect the stubs.php file? Check to make sure the contents of stubs.php is being updated and reflects your templates/fields? Make sure the output matches your type-hint - this is configurable, e.g. "tpl\basic_page" is one option, but "tpl_basic_page" is also possible. Just checked, the default is the "tpl_" prefix, and no namespace (for compatibility with older PHP versions) so check the module configuration, you can set the prefix and namespace as needed.

Cool, are you on BitBucket? If not, create and account and let me know your username.

@joe_g this is basically what the module I've been working on does - except, it writes this file for you (as flat JSON files for source-control friendliness) creating a repeatable record of every change made to templates and fields. I don't work with ProcessWire in my day job anymore, and probably won't get around to finishing this... I wonder if I should go ahead and release it as-is. Would anyone be interested in taking over this project?

I don't see it so much as adding another layer. The underlying data model already resembles entity/component - I see it more as getting to a run-time model that more accurately reflects the underlying data-model. I didn't know about ProFields - it looks like it does add a kind of "compound field", managing to reuse those field-types that can co-exist in a single, flat table - so, as far as I understand, any type that isn't multi-valued, e.g. doesn't require it's own table. So effectively, this does implement an entity/component pattern - though it kind of feels like an afterthought to me... I wish the field-type model had been built from the ground up using this pattern consistently...

At the database-level, yes, it does closely resemble the E/C model - fieldgroups, however, are a logical grouping of fields, not a physical grouping; the difference being, fields inside a fieldgroup are still exposed at the root of the entity, just like any other non-grouped field. Because it's only a logical grouping, the model does not reflect this grouping as such. Getting fieldgroups their own database table would not be possible given the current architecture, as far as I can figure - field types manage things like table schema and query construction. I could be wrong, but pretty sure some drastic changes would be required to switch to a full-blown entity/component model.

I had a realization recently about the PW data-model that I would like to share. The PW model is actually very akin to that of the Entity/Component model. Pages can be seen as Entities, and Fields can be seen as Components of those Entities. Templates can be seen as Component Types. One important difference from the E/C model, in terms of implementation, is the shape of the resulting entities - Fields are mapped directly onto Pages; or in other words, Component properties are mapped directly onto Entities, which means the Components themselves are limited to a single property at the model-level, even though some Field types are backed by tables with more than one property value, e.g. more than one data-column. I can't help thinking the resulting model is really close, but one step removed from being anywhere near as powerful as a real E/C data-model. To explain why I feel this way, here's a very simple case example. Let's say you have a shop with different types of products, many of which have at least one thing in common - they have a unit price, product title, and manufacturer name. With the PW model, I will add these three fields individually to every Template that describes a product type, and I will address these as, say, $page->price, $page->title and $page->manufacturer. Fetching these three fields requires three joins to separate tables. Conceptually, these three fields are meaningless on their own - they belong to a single component that defines the necessary properties required for something to "be" a product in our system. The, let's say, shopping cart service, for example, is dependent on the presence of all of these three fields and doesn't function if one of them is missing. With the Entity/Component model, instead of adding three individual fields, you define a component type that defines these three fields. You would address them as, say, $page->product->price, $page->product->title and $page->product->manufacturer. In other words, these three fields, which belong together, are exposed in the model as a single, integral component. Fetching these three fields requires a single join to one table. The ability to group together related properties in components has performance advantages (fewer joins/queries) but more importantly, it has practical advantages in terms of programming. You wouldn't need to group together related fields by prefixing them with "name_" anymore, which seems like an unnatural way to create a kind of "pseudo component". Adding/removing properties to a component property would naturally propagate that change to every entity that uses that component, rather than having to run around and update them manually. Controllers/services could define their requirements in terms of component shape. I realize it's a pretty substantial departure from the PW data-model, but perhaps something to think about for an eventual future 3.0. Or perhaps just an idea to consider for a different CMF in the future. Or perhaps just something interesting to think about and do nothing

I just ran into this issue, and it was not a permissions problem. This was a site I have checked into source-control (Git) and the problem was, some folders are exempt from source control, namely "cache", "logs" and "sessions" in the "assets" folder. Apparently, PW will silently fail when these folders don't exist and can't be written to. Shouldn't it should throw an exemption on failure to write to any of these folders? The error message given currently is misleading more than helpful.

Still thinking about this frequently. Still reaching no satisfying conclusions. Lately I'm leaning towards a solution that completely avoids HTML altogether - I came across this Markdown editor, and really like the concept: https://markdown-it.github.io/ The problem with this, is there's no server-side (PHP) version of this otherwise excellent, fast, very complete Markdown implementation. Would rather not depend on Node for this. Would rather not have to port and maintain the whole thing. Wonder if js2php would run it, but the project has been unmaintained for 3 years. I would like to use this in conjunction with a simple token replacement system - so if you were to type in "{kittens}", the token would appear on a list, from which you'd be able to specify what you want to replace it with. This would have plugins, so you could add image features, a table builder, or other things for which Markdown isn't ideal. Just thinking out loud here... I'm working on too many other projects at the moment

> Wouldn't this already possible with the WireCache? Not really. Each page should be able to have more than one cache entry - you can't enumrate cache entries for a page, since cache entries are not indexed by page number. For that, you would need a page-specific caching facility.

> sounds like you want to see a cache for storing calculated values associated with a page More or less - not really associated with the page per se though, more like tagged as being related to a page ID. I envisioned $page->cache returning e.g. new PageCache($page->id) and any name/value you write to the cache would then get written to a table with the Page ID. So cache entries indexed by Page ID basically. And with cache entries related to a Page getting automatically cleared when you delete the Page. Other than that, I picture this working just like any normal data cache - just a generic facility where you can store name/value pairs. I don't expect it to magically keep track of dependencies on other pages, although that is an interesting idea, if it could somehow be implemented without major performance drawbacks... probably not.

I'd like to see a caching API added to Page objects. This would differ from WireCache, in that this would enable caching in a Page-specific context, which would make it possible to provide some meaningful options for (among others) cache expiration in a Page-context. The API might be something like a PageCache class, which is attached to Page objects as e.g. $page->cache. It would work much like WireCache, but would write cache entries with the Page ID attached to each entry, allowing some new options for cache expiration: Expires when the Page object is deleted Expires when the Page object is changed Expires when the Page object, or a Page in it's parent path, is changed When, for example, you have a page/template that aggregates content from another page (fetching content server-side), or when your template needs to perform expensive calculations or database queries to produce the page content, the fetched/generated content could be written as cache entries that lives forever (until the Page object is deleted) or until the next change to that Page, or a parent Page. Thoughts?