Jump to content


Fieldtypes without DB table

Module Plugin

  • Please log in to reply
1 reply to this topic

#1 Oliver


    Sr. Member

  • Members
  • PipPipPipPip
  • 166 posts
  • 82

  • LocationBasel, Switzerland

Posted 18 February 2012 - 05:35 AM

As I said I've been thinking about creating a kind of short cut InputfieldType similar to ryan's idea of repeatable fields. But this one would allow to manage a page's hidden child pages of a set of allowed templates skipping the way through the page tree. It's something I think would help people editing contents to work faster and avoid mistakes. And it still would keep the data hierarchically consistent within the tree.

In the case of Repeatable Fields I guess it's all based upon FieldtypeMultiple and ryan stores the IDs of the hidden pages representing the single repeatable elements in the DB like in FieldtypePage.

The point is, that - in case of my Fieldtype's idea - it wouldn't make sense to store any additional information in the db, as all information would be already stored within the pages' relations within the page tree (children, IDs, sort values). But when I'm not totally wrong, the Fieldtypes expect a DB scheme to be provided for installation, saving and getting values. Which methods do I have to override to work around using an own DB scheme and just provide data from API calls? Is it possible at all?

#2 ryan



  • Administrators
  • 10,222 posts
  • 11240

  • LocationAtlanta, GA

Posted 20 February 2012 - 01:04 PM

Good question Oliver. The Fieldtypes do each require a DB table, and must have at minimum a 'data' column (regardless of whether it's text, integer, etc). I also recommend that you extend Fieldtype rather than FieldtypeMulti. If you don't need multiple items stored in the DB per page, then there's no reason to use FieldtypeMulti. Your wakeupValue will construct an array or WireArray or some other object, and it doesn't really matter where it gets the data from to do it. If your Fieldtype holds (but doesn't store) multiple items, I recommend using your 'data' column in the schema as an integer that just stores a count of how many items there are. That way it can still be used in selectors to find pages that have a populated value vs. pages that don't.

Also tagged with one or more of these keywords: Module, Plugin

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users