From templates to models

[hellomoto]

I love PW but there are certainly cases/times when I wish that templates were models (or mutants or something whatever you want to call them) instead, rather than necessarily hierarchical in the admin and routing. I have not been practicing much lately unfortunately, just reading more, so I wish I could implement this as an option for the PW community but I am not quite there right now...

I have read a little bit into @teppo's Wireframe, which is interesting, but does not implement the model component ("ProcessWire is the model"), more so the view-controller. The approach PW takes in terms of content management structuring and development (from a database viewpoint) seems awesomely scalable and modularly distributed (not sure if I'm using all the right language here but you probably know what I mean), and I just think that the single major aspect missing is the ability to organize routes and content sans tree structure.

The new template models could also have templates themselves... In WordPress for example, pages and posts/post types (I believe it's been a while) can have templates per, to change their content/formats however slightly or much, while remaining an object of the particular "model" (post type).

Agreements and/or arguments?

[hellomoto]

Maybe models could be implemented somehow as like floaters with a routing setup separate from the regular hierarchy, or an option on install, or something... or a total switch over that can easily be used as in the regular page tree hierarchy way... but also otherwise...

But situations like this

Maybe there is a solution to this as-is but it would just be simpler going the model & route route ?

Just an idea

[teppo]

46 minutes ago, hellomoto said:

... and I just think that the single major aspect missing is the ability to organize routes and content sans tree structure.

The new template models could also have templates themselves... In WordPress for example, pages and posts/post types (I believe it's been a while) can have templates per, to change their content/formats however slightly or much, while remaining an object of the particular "model" (post type).

Agreements and/or arguments?

This is interesting!

Full disclosure: on a few occasions I've considered adding a separate model layer to Wireframe, but I've never found a proper reason, i.e. I couldn't think of anything I can't do without it — or even anything it would make notably easier or more effective or more organised — and I'm trying not to add features just because they'd be fun to implement. That being said, I'm always on the lookout for interesting new stuff to add, as long as it adds real value to the framework ?

I think when you say "model" you probably mean something a little different than what it means to me personally. In my mind models are tied to data structure, have very little to do with routing, and so on. In fact from what I could gather from your examples it looks like such models would indeed be a lot like custom post types in WordPress in that they'd be located in a single "bucket" and define a per-model route that's separate from the regular page tree structure.

If that's the case, wouldn't one variation of that just require creating a parent page on the root level and then subpages below that? Or, for more complex routes, you could make the parent page render its subpages based on URL segments. All the building blocks are already there, though obviously this one needs quite a bit more work — you have to define the routes programmatically, for one.

Any chance you could flesh your idea out a little more:

• What would you use this sort of thing for?
• How would you envision defining the routes?
• How would this be different from existing options, such as placing a parent page under root and then subpages using specific template under that, or using URL segments — i.e. would the biggest benefit be some abstract method of defining routes?

WordPress templates are a bit different in that they're about representing data, while ProcessWire templates are obviously all about structuring data. Wireframe, for an example, has concepts called "layout" and "view", which are largely in line with WordPress' templates: each template can have multiple views, and each of those views can then be used to render pages in different ways, and/or for different purposes (JSON, RSS, HTML, etc.)

Long story short: I'm intrigued, but not entirely sure of all aspects that this concept would bring to the table. Definitely interested in hearing more though!

[hellomoto]

32 minutes ago, teppo said:

I think when you say "model" you probably mean something a little different than what it means to me personally. In my mind models are tied to data structure, have very little to do with routing, and so on. In fact from what I could gather from your examples it looks like such models would indeed be a lot like custom post types in WordPress in that they'd be located in a single "bucket" and define a per-model route that's separate from the regular page tree structure.

Hey! No I think we're thinking of models the same; I didn't mean to imply that they would be tied to their routes, as the templates (basically) are in PW. I do mean models entirely separate from routing, thereby allowing for routes to be specified as needed and totally custom.

The ways you mention with parent pages and URL segments I've tried, but still don't prefer totally overall, all the time... Yes, define routes abstracted. For example for a car sales website... which could totally be done in PW as-is, but for one thing I would not really want the listings to even be in the tree view in the admin...

Maybe it could just be a module that would allow for creating templates and admin views of pages (?) outside of the page tree that then can be controlled and moved around (?) more easily (?) in views for those within the tree. That's probably just fine.

Sorry this is a really rough idea. I don't believe I'm making it any clearer. Apologies.

[hellomoto]

Routing I have in mind like it's done in Laravel; that seems like it would be simple to even convert to, again maybe just via a module so people could just work with the original way it's been done; then every template (e.g., in said hypothetical module) could be a "model". Maybe templates on templates is too far-reaching... could basically be done with showIf etc. and the demand probably is not nearly high enough for such a feature. So that's off-topic for now.

[teppo]

2 minutes ago, hellomoto said:

Sorry this is a really rough idea. I don't believe I'm making it any clearer. Apologies.

No reason to apologise. Ideas are always welcome here, no matter how rough they might be ?

3 minutes ago, hellomoto said:

The ways you mention with parent pages and URL segments I've tried, but still don't prefer totally overall, all the time... Yes, define routes abstracted. For example for a car sales website... which could totally be done in PW as-is, but for one thing I would not really want the listings to even be in the tree view in the admin...

Maybe it could just be a module that would allow for creating templates and admin views of pages (?) outside of the page tree that then can be controlled and moved around (?) more easily (?) in views for those within the tree. That's probably just fine.

If I got this right, you could sort of achieve the Admin view part of this with Listers and some custom code, or perhaps ListerPro out of the box, though that would mean that such content is no longer managed in any sort of tree structure (yet, at the same time, it would still actually exist in the tree). The latter part could then be half resolved by hiding the page from the tree with a hook that hides such pages from the tree, but it still wouldn't change the fact that in ProcessWire pages always exist in a singular tree.

This "one tree" approach is actually pretty fundamental to ProcessWire, and — as Ryan explains in this very old thread —  there's a good reason for this:

Quote

Whether something is a branch or a tree doesn't really matter here from my perspective. The type is defined by the template, not the tree or branch. Any branch can be a tree. But if we start pulling branches out of the context of a common root, then we introduce a lot more complexity to the API. That's why we've been de-isolating other data containers (users, roles, permissions, etc.) and moving them to be part of the tree. Now all of these things are pages (in the admin branch) and they are a lot more flexible as a result.

I think someone was developing a module (?) a while ago that sort of created separate trees, though again it was basically a "virtual" approach where you get multiple page lists in admin, yet behind the scenes things are still in one big list.

On a loosely related note: a while ago I came across a site that used an approach of URL segments + separate PHP router library. Not necessarily an approach I would've preferred — in most cases that's just some added complexity you don't really need — but that's always an option.

Anyway, I think you may be onto something here, but I'm just not sure I'm seeing the entire picture yet ?

[Pixrael]

 

[bernhard]

13 hours ago, teppo said:

14 hours ago, hellomoto said:

The ways you mention with parent pages and URL segments I've tried, but still don't prefer totally overall, all the time... Yes, define routes abstracted. For example for a car sales website... which could totally be done in PW as-is, but for one thing I would not really want the listings to even be in the tree view in the admin...

Maybe it could just be a module that would allow for creating templates and admin views of pages (?) outside of the page tree that then can be controlled and moved around (?) more easily (?) in views for those within the tree. That's probably just fine.

If I got this right, you could sort of achieve the Admin view part of this with Listers and some custom code, or perhaps ListerPro out of the box, though that would mean that such content is no longer managed in any sort of tree structure (yet, at the same time, it would still actually exist in the tree). The latter part could then be half resolved by hiding the page from the tree with a hook that hides such pages from the tree, but it still wouldn't change the fact that in ProcessWire pages always exist in a singular tree.

If I understand you both correctly this is what I'm doing with RockFinder2 + RockGrid / RockTabulator. It's far from perfect yet, but it's built for managing content in a non-hierarchical way which is a very common need IMHO. I don't like listers for that purpose at all. They are limited, they are ugly (*personal opinion!* taking too much space etc), they are hard to customize (like colorizations etc), they are not reacting fast to user input. Of course, there are good reasons why they work as they work: Scalability, access control, multilanguage. These are all points that are challenges for my modules. But in all my projects the benefits of having structured grids of data that are nicely designed, compact and "reactive" (like when filtering columns etc.) outweigh the cons.

Not saying my modules are the way to go or better than what you describe. Just wanted to share what is already there and how I'm using it.