Expose patternslib #1191
Expose patternslib #1191
Conversation
|
@jcbrand if you're trying to replace the mockup sortable, just be careful, it's used in quite a few other patterns. This is a lot to include and not actually use. I'm not sure how I feel about shipping with something like this. It seems like it would commit Plone to always supporting those packages. I think I prefer people who want to use the additional patterns, to include it themselves. Or we create a collective.patternslib package? |
|
About sortable, I don't think I'll get around to it this sprint still. About exposing all patterns, the main advantage I can see is that people can easily add and use patternslib patterns in their own Plone sites or addons by simpling adding registry entries. People regularly ask me how they can use core Patternslib patterns, and being able to just add a registry entry is a nice simple solution. I'm not sure collective.patternslib makes sense if some patternslib patterns will be in core Plone. We can only selectively expose those patterns being actually used (two candidates for now are toggle and autofocus), but then we lose the ability to easily add other patternslib patterns. |
|
I need other people opinions on this I guess. I'm also worried about adding all this on a point release. |
|
@vangheem I think this is a good example why we need to make it easy to expose Patternslib patterns: https://community.plone.org/t/collapsiblesections-js-is-gone-long-live-pat-collapsible/1047 There are good reasons to start using existing Patternslib patterns, but there is still a lot of confusion. I'd like to be able to tell people to just add registry entry for the pattern they want to use. |
|
I'm a bit concerned about library size. The whole Patternslib library has 6 MB. Including all dependencies it's 42MB. There are a lot of .gitignore statements, which excludes images, but there are no for other dependencies. At ploneconf we agreed that we want to merge duplicate patterns into those in Patternslib and move general useable patterns from mockup to Patternslib. What about moving the whole bower components directory out into a seperate plone core package? That would allow us to update bower dependencies independently from the Plone release cycles and Keep CMFPlone smaller in size. |
That's kind of what @vangheem already suggested, but he mentioned |
I don't think that's terribly controversial. @vangheem and I discussed and agreed on this at PLOG already. However, how to properly do this (with minimal disruption) is a challenge :) |
|
agree, agree. |
|
No need to apologize @thet! :) |
|
We have now created a package plone.patternslib which does include a subset of the Patternslib patterns into Plone 5 and it seems to work without major surprises. The package is here https://github.com/syslabcom/plone.patternslib and I am happy to move it to plone or somewhere else. @vangheem @thet |
|
package was moved meanwhile and is here https://github.com/plone/plone.patternslib |
|
I think this issue can be closed, because the problem is solved with https://github.com/plone/plone.patternslib Reopen this pull-request, if needed. |
For that to happen, core could would have to start relying on (at least some) Patternslib patterns. Since there is overlap between the functionality provided by Mockup patterns and Patternslib patterns, this could be a desirable outcome in the medium term, by deprecating certain Mockup patterns in favor of Patternslib ones. |
Add the patternslib patterns to version control so that they can eventually be exposed via the registry.
@MrTango is working on merging pat-toggle @timitos is working on autofocus and I'm working on sortable.