Jump to content

Processwire Data Objects


Recommended Posts

I have a friend who uses Silverstripe, and he was telling me about the Data Objects and the ORM it uses, for things like "has many", "one to one", "one to many" relations etc.

Maybe i'm not thinking about things correctly, but in the Processwire world, would a Page essentially be a data object?

Just want to get my head around how to think about structuring a web application in Processwire.

I'm familiar with traditional MVC (rails, code igniter) based structures.

The API may already enable this kind of functionality, but i was wondering if not, would Processwire ever get an ORM? or can an ORM be bolted onto Processwire?

If anyone could help me figure this out that'd be great.

Thanks

Link to comment
Share on other sites

If I understand that right (never used any of those cms's / frameworks) than you should look at WireArray and WireData. These are the basic building blocks of ProcessWire and are basically the single and multi-entity data blocks. All other Datatypes build on this e.g.:

  • User > Pagetype > Page > WireData
  • PageArray > WireArray
  • ….

But I don't know of any specific "one to one" or "has many" relation, while "one to many" is just done by hierarchy (FieldtypeWrapper (Field) -> children (FieldsArray)).

  • Like 1
Link to comment
Share on other sites

Over time we have often had discussions about the nature of Pages and the fact that the term 'Pages', in context of ProcessWire(PW), can be misleading. Pages can represent a lot of things and serve multiple goals.  (fun read: https://processwire.com/talk/topic/2296-confused-by-pages/ )

You are right that Pages can be seen as (URL accessible) data objects. What data a particular Page can hold is defined via the page his Template and the Fields added to that template. So a Template can, amongst other things, be seen as a data model.

ProcessWire has its own way of organizing and relating data. While the underlying database structure might be different than most MVC-ish systems, the Page tree and the Page fieldtype allow for really flexible ways of achieving most, if not all, of the traditional model associations like in Rails' Active Record. Finding and working with pages/data couldn't be easier thanks to the great API, so i don't think there is a need for an 'ORM' because in a way PW already has this.

  • Like 5
Link to comment
Share on other sites

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

×
×
  • Create New...