I am working on a project that requires functionality similar to that provided by the Composite Layout (CL) module. However, the requirements for the configuration options and UI are quite different from what CL provides. For example, we require that only a fixed set of layouts be presented to a content author, and that this fixed set varies depending on the node type. In order to achieve this I have created a thin wrapper module that delegates most functionality to composite.module, while altering the forms and so on. However, this is harder to achieve than it might be.

In order to disable composite.module from directly configuring our nodes, we are not setting composite_enabled for those types, but instead setting our own flag. However, this then causes problems as several places in the code (e.g. the composite_nodeapi hook) explicitly check this flag and abort if it is not set. This makes it impossible to delegate to this function, and instead I have to copy and paste this entire function, even though I am only making a slight change to the 'alter' operation. Likewise, in order to customise the options available on the node and node type forms, I am having to copy the entire form_alter hook. These alterations make my code dependent on composite.module internals, leaving me exposed to breakages in future releases of composite.module, and basically in the position of maintaining a private fork.

The solution, I believe, is to refactor composite.module to cleanly separate out the various components into domain model, service, persistence and presentation layers, so that each can be customised and replaced independently of the others. For example, the customisations to the node and node-type forms should themselves be Drupal forms (retrieved with drupal_get_form()) and then merged with the parent form, rather than hard-coded into the form_alter hook. This would allow extensions to customise these customisations. Likewise, all the nodeapi operations should be encapsulated in separate persistence layer and LayoutEngine objects (or equivalent non-OO constructs), which can be overridden by extensions.

I can provide more detailed design and (eventually) code if you are interested.

Regards,

Neil Madden

Comments

bengtan’s picture

bengtan commented

Hi,

My initial reaction is ... 'Uh oh, I don't really want to know about this because it's going to cause me more work'. Especially if it involves large changes to Composite Layout (CL) and/or isn't beneficial to most users.

Part of the reason I wrote Composite Layout was because Panels (back then) didn't do quite what I wanted (although it was the first option I looked at). Panels did about 80%, but trying to make it do the other 20% was fighting it too much, because Panels was designed to work in a different way.

Similarly, if your needs diverge too far from what Composite Layout (CL) does right now, then I'd suggest maybe you'll end up spending as much time writing your own module from the ground up (but borrowing code from CL) as trying to force CL to do what you want.

I dunno, it really comes down to the details of the matter.

If you can achieve what you want by making small patches to CL which improve it's modularity, then I'd consider them.

If large changes are involved, then I'd be very reluctant. Also consider that any changes must not break compatibility with existing sites which currently use CL. Which means any such task perhaps should be done in a 6.x-2.x branch or something, if it is done at all.

If you are asking me to completely replace the internal architecture and 'wiring' of CL, then I'd also be very reluctant unless you can convince me that it's beneficial in some way.

nmadden’s picture

nmadden commented

Similarly, if your needs diverge too far from what Composite Layout (CL) does right now, then I'd suggest maybe you'll end up spending as much time writing your own module from the ground up (but borrowing code from CL) as trying to force CL to do what you want.

Right, but then we'd end up with another layout module that probably does 80% of what somebody else wants. I'd rather spend the time improving CL in a backwards-compatible way where possible. My feeling is that a decent improvement in flexibility (enough to accomodate my needs) can be had relatively cheaply, by breaking a handful of functions down into 2/3 separate functions each and possibly adding an extra hook or two. I'm busy this week with work commitments, but I should have time next week to compile a small patch for your perusal. If you feel it's too much of a change, then that is fair enough.

bengtan’s picture

bengtan commented

Hi,

My feeling is that a decent improvement in flexibility (enough to accomodate my needs) can be had relatively cheaply, by breaking a handful of functions down into 2/3 separate functions each and possibly adding an extra hook or two.

If you can manage this, then that would be much better since Composite Layout doesn't have to change too much.

bengtan’s picture

bengtan commented
Status: Active » Closed (won't fix)

Expiring this issue as it is old and uncertain whether it is still applicable.