OneToOneProductSkuPresenter customization

[jearles]

Hi,

We are customizing Broadleaf to meet our specific needs. In doing do we have extended ProductSkuImpl to add extra attributes, including a couple of ManyToOne relationships. We have created a custom Presenter / View and registered them. This is working fine.

We are now trying to customize the Admin to provide the Search support for these attributes, which requires adding AdditionalForeignKey entries to the "productDS". The problem we are running in to is in our implementation of setup(). We don't want to lose all the additional capabilities of OneToOneProductSkuPresenter, so we are extending and overriding. However, if we call super.setup() then OneToOneProductSkuPresenter will already have declared the "productDS" and called setupDisplayItems. Even more so, a bunch of the other PresenterSetupItems will have gotten a reference to "productDS" and added Search Form Items. After super.setup() returns seems to be too late to try and augment "productDS" with extra ForeignKey entries - I can't get the new attribute to appear in the "right-side" Dynamic Form.

Do we, today, have no other option but to copy the entire OneToOneProductSkuPresenter.setup() code into our presenter, and not call super.setup()?

If this is the case you might want to consider refactoring the way you setup the "top" datasource to call a "template method". This way a subclass could drop in a replacement and it would allow easier extension.

Thanks,

- John

[jefffischer]

The way this piece works is deceptive, in that in traditional OOP, you would think your override is too late to have an impact. However, these setup items are not processed in the way you think - these items are not actually processed until after the setup method is completely exited, so you definitely have the opportunity to add to or override any of those items. This is why we named the method "addOrReplaceItem" for working with these setup items.

In your case, you should be able to add your customized setup item (as long as it's name is still "productDS") in your presenter and your implementation will replace the one in the Broadleaf superclass and your implementation will be executed in the same order as the original one was (so the other dependencies on "productDS" will not be broken).

[jearles]

Thanks, Jeff. I'll give that a try and report back.

EDIT: Worked like a charm.