Similar module - differences from Block API module? [#1186802]

Also noted at #1186800: Similar module - differences from Bean module?. Trying to work out the differences between the two modules.

Comments

Comment #1

mrfelton CreditAttribution: mrfelton commented 18 June 2011 at 09:14

Referencing related discussion at #1190644: Duplicate / similar module - Bean vs Block Entity vs Block API. Great that you and fabsor have decided to work together.

Comment #2

mrfelton CreditAttribution: mrfelton commented 18 June 2011 at 09:25

Referencing another related discussion at #948066: Difference between block 2.0 and other block solutions (boxes, context, etc)

Comment #3

indytechcook CreditAttribution: indytechcook commented 19 June 2011 at 21:20

Cross post from #1186800: Similar module - differences from Bean module?

Our goals are really inline. We both want to provide a way to create block types, then create instances of the block types. You approached it from a modifying the current state while I approached it from a clean slate. My idea was to make the API first, then make the UI an implementation of the API. The plugins are how you create new block types. I chose making the blocks as content (hence entities) because of that's what they are becoming. This also gives us fields built in (but not needed for the blocks).

I turned the block into content. It has a separate home on the UI /block/add, it has separate permissions then the block types. Blocks types are bundles on blocks and are completely in code (except for the UI implementation which will be exportable). Not a huge array in code like features, but really in code. I chose the boxes plugin methodology of OO based plugins that will be replaced with the Plugin system that Larry is working on.

My goal was to make the block system how I would want it from a coding/framework perspective. After looking over you code, I see many places I need to add to my code (thanks!) to make it more inline with the current block system.