Title says it all.

block_api_entity.module...

  1. depends on block_api and entity modules.
  2. adds a {block_api_type} table, storing custom block types.
  3. implements hook_entity_info() to register the block_api_type "bundle entity".
  4. implements hook_entity_alter() to
    1. inject existing block types as 'bundles' into the block_api entity info.
    2. register Entity module properties in the block_api entity info, so we get the administrative UI for free.
    3. marks the block_api entity as 'fieldable' => TRUE.
  5. Ensures that Field Attach API functions are properly invoked for block instance configuration forms.
CommentFileSizeAuthor
#10 block_api_type-9963860-10.patch2.31 KBmustanggb
#6 block_api_type-9963860-6.patch25.63 KBmustanggb
#5 block_api_type-9963860-5.patch25.3 KBmustanggb
#3 block_api-HEAD.type_.3.patch1.45 KBsun
#1 block_api-HEAD.type_.1.patch7.86 KBsun

Comments

sun’s picture

sun
Primary language German
Location Karlsruhe
commented
Title: Add a block_api_entity sub-module to create custom (fieldable) block types » Add a sub-module to create custom (fieldable) block types
Status: Active » Needs review
StatusFileSize
new block_api-HEAD.type_.1.patch7.86 KB

Just to kick-start development.... *SCNR* :)

sun’s picture

sun
Primary language German
Location Karlsruhe
commented

And to simplify development a bit -- committed that to HEAD, but with the following .info file trick:

; Hidden until matured. Use drush to enable/disable.
hidden = TRUE
sun’s picture

sun
Primary language German
Location Karlsruhe
commented
StatusFileSize
new block_api-HEAD.type_.3.patch1.45 KB

Forgot the essential hook_block_api_info() implementation. ;) Also committed attached patch.

mustanggb’s picture

mustanggb commented 
+++ block_api_type/block_api_type.install	12 Dec 2010 22:27:31 -0000
+/**
+ * Implements hook_field_schema().
+ */
+function block_api_type_schema() {

Should this be hook_schema()?

mustanggb’s picture

mustanggb commented
StatusFileSize
new block_api_type-9963860-5.patch25.3 KB

Some more integration and a bit of menu structure rearranging.
Trying to make it act as close to Drupal core as possible.
Help was asked for so I gave it a shot, is this the right direction, feedback appreciated.

mustanggb’s picture

mustanggb commented
StatusFileSize
new block_api_type-9963860-6.patch25.63 KB

Missed out my own comment from #4.

sun’s picture

sun
Primary language German
Location Karlsruhe
commented

Unfortunately, core's Block module is totally not an example that should be followed in any way.

Most of the submodule's code was carefully designed and coded already; also, to not repeat the mistakes of the core Block module.

Thus, I totally appreciate your work here, but I'm not sure I'm able to spot the actual improvements within that huge-rename-of-everything ;)

Can you roll a new and leave everything out that attempts to follow Block module? :)

mustanggb’s picture

mustanggb commented

I actually didn't look at or take anything from core Block.
What I did look at however was core Node in order to try and have Node and Block acting the same as far as UX is concerned.
So I'm not sure what is reminiscent of Block that needs to be removed.

mustanggb’s picture

mustanggb commented

In short, help?
What needs to be done next?

mustanggb’s picture

mustanggb commented
StatusFileSize
new block_api_type-9963860-10.patch2.31 KB

So here is a re-roll that tries to keep things as simple as possible.

This gets me as far as being able to create a block type and add fields to it.

However when trying to create a block (of the block type) the newly added fields do not appear, any hints why?

EDIT: Do we need a field_attach_form() somewhere?

jamestombs’s picture

jamestombs commented

Doesn't Bean do fieldable block types?

Thought Block API was all but obsolete (with the exception of a slightly better name).