Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Resource registry design makes it very diffucult to combine widgets from different sources #485

Closed
tdamsma opened this issue Oct 25, 2020 · 5 comments

Comments

@tdamsma
Copy link

tdamsma commented Oct 25, 2020

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 Pylons/deformdemo#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.

@stevepiercy
Copy link
Member

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.

@stevepiercy
Copy link
Member

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?

@tdamsma
Copy link
Author

tdamsma commented Oct 31, 2020

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!

@stevepiercy
Copy link
Member

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. 🤞

@stevepiercy
Copy link
Member

Closed by #486.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants