Closed ToddHossack closed 7 years ago
Todd, the reason why I'm not subclassing ModelAdmin was exactly that, separating coming and past events - and to have freedom to build the UI the way I wanted. But I completely agree that there are inherent issues in this approach. It's never been easy to build custom admin interfaces in SilverStripe, and I was finally happy to have found that approach. That being said, if you succeed to separate coming and past events in ModelAdmin, I'd be happy to merge that change back into the module. That definitely improves the future upgradeability of the module.
@ToddHossack, I'm looking at moving the admin to ModelAdmin subclass as well. Maybe we can compare notes?
I've added a pull request for the change to ModelAdmin. I've taken a simple approach and combined the coming events and past events into a single form with two tabs and grid fields. The admin UI defaults to displaying coming events on load as before, and the event import specs have been retained. The managed models also are constrained by the configuration.
Great! I guess we can close this one now?
Testing this now, and I'm not getting the admin interface to load properly. It is still displaying the previous left column with the three buttons, and no gridfield at all in the right section. The buttons return errors.
I've done a /dev/build?flush=1 and cleared browser cache, but I suppose it could still be something local I'm overlooking.
Hi Anselm, After adding/editing models in the admin interface the UI always defaults back to events. This makes it difficult to add multiple items consecutively, for instance when creating categories. Additionally categories do not have an import form. Is there a reason why CalendarAdmin does not subclass ModelAdmin? The two problems mentioned above would be solved by using ModelAdmin as the parent class. Also, the admin UI would more closely match the standard UI. As far as I can see in the code, the main reason for not using ModelAdmin is to separate the coming events and past events. Are there any other reasons? Presently, I'm trying to solve the issue of separating coming and past events while still subclassing ModelAdmin. I just need your input. Thanks. Cheers, Todd