Processwire Data Objects

[mrjasongorman]

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

[LostKobrakai]

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)).

[apeisa]

Page field is one to many or one to one relationship, depending on how it is configured.

[mrjasongorman]

Awesome, thanks guys for replying so quick!

I'll look into these.

[SiNNuT]

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.

[LostKobrakai]

Maybe this can be from interest, too: https://processwire.com/talk/topic/9305-the-pw-data-model-and-the-entitycomponent-pattern/