Remove reliance on silverstripe-widgets?

[chillu]

I'm wondering if this module could be simplified if we use Element as the base class, and remove the reliance on silverstripe-widgets. I see Element as a better alternative to Widget.

Or put another way, I don't see how the widgets module should be used other than in a mature content blocks solution. The portal-style "sidebar" functionality that widgets was originally developed for has been replaced by responsive design which treats content as linear sequences of content. These sequences can sit side-by-side in more complex designs, but they're not arranged in a "sidebar" widget area next to content coming from the page type, they are the content.

• The mixed terminology between "widget" and "element" is confusing to developers
• Having a "base module" makes API changes and release planning harder
• The Title, Sort and Enabled fields could be migrated from Widget (simlar for WidgetArea)
• WidgetAreaEditor and WidgetPageExtension don't seem to be used, and is a large part of the "surface area" of the widgets module
• It already removes the WidgetContentControllerExtension
• There's not a lot of other dependents on the widgets module which are in widespread use
• Only two of twelve content blocks modules have decided to build on top of widgets

[wilr]

Totally Ingo, building on top of widget is probably outdated so no real reason to do it that way and redundant in 2017. It also makes the template logic a bit messy with Areas, Holders and Template. I think last time myself and John spoke we knew SS Ltd was going to support a content block officially so held off any major changes

[pitchandtone]

There's a bunch of reasons wy the widgets architecture has some good things which even if we remove the dependancy we'd need to move into Element / Element Area

1) Widget and Controller relationship is required for handling forms, other modules have re-implemented this in a very similar way (e.g. https://github.com/sheadawson/silverstripe-blocks/blob/master/src/controllers/BlockController.php ) 2) WidgetHolder rendering vs WidgetContent is helpful so that it's easy to have consistent HTML wrappers on every element, I disagree with Will on this point, I think it's a feature. 3) WidgetAreas are helpful to render widgets and maintain relationships easier than a many_many. It also opens the door to having multiple areas on one page, whereas many_many causes issues here and has to be hacked around using things like 'areas'

On 22 June 2017 at 10:53, Will Rossiter notifications@github.com wrote:

Totally Ingo, building on top of widget is probably outdated so no real reason to do it that way and redundant in 2017. It also makes the template logic a bit messy with Areas, Holders and Template. I think last time myself and John spoke we knew SS Ltd was going to support a content block officially so held off any major changes

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/dnadesign/silverstripe-elemental/issues/81#issuecomment-310227534, or mute the thread https://github.com/notifications/unsubscribe-auth/ABAZU5TWjMZps1bbSS_LgBQj627xcRYWks5sGZ7mgaJpZM4OBm4N .

[pitchandtone]

In progress on the SS4 branch.

[pitchandtone]

Seems to be working well on the SS4 branch, now need to https://github.com/dnadesign/silverstripe-elemental/issues/97