Closed tdamsma closed 3 years ago
First of all, thank you for both proof of concepts. This makes it clearer how difficult the resource registry is to manage.
I'll keep discussion in this issue, and any comments pertaining to code implementation in the PRs.
I will have further comments after I check out #486 and take it for a spin.
I checked it out. This is a nice feature, and I appreciate the care for backward compatibility. Thank you!
Do you need anything from me to get the one failing test to pass, and to bump it up to 100% coverage?
I haven't looked yet what the problem was, think I'll manage. But if you are potentially on board with this I'll try to finish the PR. A sidenote, I read somewhere you were looking to present pyramid/deform somewhere. I'd be happy out!
Yup, this looks good, and scratches that itch.
If you run $TOX
you will see the failing tests right away.
I submitted a lightning talk (5 minutes) for Deform and Deform Demo, a 30-minute talk on Pyramid TBD (possibly a presentation of a use case), and a 4-hour tutorial on Pyramid at PloneConf. We'll see what they accept. 🤞
Closed by #486.
As discussed previously I was working on making a few custom widgets available (in #472), but due to the design of the resource registry the every widget that is imported needs to be added to the same resource registry making (unnecessarily) difficult to combine widgets from multiple sources. I ran into this while working on https://github.com/Pylons/deformdemo/pull/93 to see what I mean.
So I propose to extend the resource registry mechanism, in a backward compatible way. Currently you need to supply two-tuples of
(name, version)
that point to something that is available in the resource registry, that then points to actual files. I would like to extend this so that you can also specify a resource as a dict that links files directly. By allowing such a bypass of the resource registry it is much easier to define independent widgets.Perhaps when many widgets share resources (e.g. jQuery) using a central registry makes sense, but when for the case where a widget relies on js/css that is created specifically for that wiget, I don't see the added value of the resource registry abstraction layer.