Ticket #12266 (confirmed PLIP)
add adjustable css class option on portlets
Reported by: | spereverde | Owned by: | |
---|---|---|---|
Priority: | minor | Milestone: | 5.0 |
Component: | General | Version: | |
Keywords: | Cc: | spereverde, dokai, sunew, bosim, mborch |
Description
Proposer: Kim Paulissen
Seconder: Godefroid Chapelle
Motivation
For both static portlet and collection portlet there was previously a dynamic css class added (see also #11593). This works nice when you want to style one specific portlet, since this css class is based on the portlet title. However, since users can fill in any title they want, this doesn't always allow flexible styling. It might be helpful to also add an extra field to the portlet where people could fill in a css class. For example "red" so it's possible to make a set of red portlets. This would allow to style the portlet and still make it possible for the users to fill in any title they like.
Assumptions
None.
Proposal & Implementation
The existing implementation of the css class will remain for backwards compatibility. An exra field will be added to the schema. The template will be adjusted to include the new css class e.g. <dl class="portlet portletStaticText portlet-static-portlettitle red">
Deliverables
Standard items:
- Unit tests
- Localization
- Documentation
Risks
As long as existing functionality is kept, backward compatibility is ensured and there should be no risk.
Participants
Progress
Change History
comment:2 Changed 4 years ago by spereverde
example of implementation code done on:
https://github.com/spereverde/plone.portlet.static/tree/master/plone/portlet/static
and
https://github.com/spereverde/plone.portlet.collection/tree/master/plone/portlet/collection
comment:3 Changed 4 years ago by gotcha
I second this change request. I am not even sure it does require a PLIP as it is a really light change with no associated risk.
comment:4 Changed 4 years ago by andren
Very nice, but could be better if you use a select instead of TextLine (similiar to Plone Text Editor styles). You can define a vocabulary of classes that will appear in all the portlets.
comment:5 Changed 4 years ago by davisagli
- Milestone changed from 4.2 to 4.3
Reassigning to 4.3 -- the feature freeze for 4.2 was in June.
I think that this warrants going through the PLIP process to make sure that we end up with the best solution. For example, I think it might be better to add this as a generic feature of all portlets in plone.app.portlets, rather than adjusting particular portlet type implementations.
comment:6 Changed 4 years ago by spereverde
some packages that have already implemented similar or related functionality:
comment:7 Changed 4 years ago by ldr
I think this is useful but agree with David that this needs to apply to all portlets (or at least all portlets with add/edit forms) for it to be acceptable by the Framework Team. Because of the way portlet assignments work this is a little tricky, but at least in collective.portletclass I was able to work around it. Limiting the classes to a configured vocabulary also seems sensible to me (making it a multiple choice field.)
comment:8 Changed 4 years ago by dokai
- Cc dokai added
Based on the discussion that took place at http://plone.293351.n2.nabble.com/deco-styled-tiles-td7137210.html I have done an initial implementation which provides support for assigning a CSS class (or classes) to portlets based on configurable vocabulary.
The work was done in the following branches:
https://github.com/plone/plone.app.portlets/tree/dokai-styled-portlets
https://github.com/plone/plone.portlet.collection/tree/dokai-styled-portlets
https://github.com/plone/plone.portlet.static/tree/dokai-styled-portlets
The main changes are in plone.app.portlets with p.p.collection and p.p.static adjusted to support the portlet style implementation.
The main changes in p.a.portlets are
- plone.app.registry used for storing available styles within a site with an associated controlpanel entry to manager them. This has brought two new dependencies, plone.app.registry and plone.app.z3cform.
- vocabulary for selecting a style based on the configured values.
- new field, "portlet_style", added for all portlets which already had an add/edit form implemented as a select widget and driven by the vocabulary.
- BBB support for existing portlets by using a class level variable in Assignment.
- Adjusted tests.
I would like to propose this as the PLIP implementation and if the general approach is acceptable I'm willing to do the rest of the work for final inclusion.
comment:9 Changed 4 years ago by rossp
The FWT has voted to approve the PLIP for 4.3 with the changes that it use a vocabulary with a widget for human readable selections and as long as the changes are made to the portlet base classes in such a way that they apply to all portlets. We'll start reviewing the implementation nowish.
comment:10 Changed 4 years ago by toutpt
- Version set to 4.1
This kind of change let user add CSS, but user don't have to know about CSS. Integrators have to know about it. I have many websites where the site manager doesn't know anything about CSS. You should call this "add portlet styles choice in all portlets add/edit form".
This is an integrator need so I would like to go one step more in this way: There are also portlet that let you choose for the renderer (view) you want. I have implemented this for a customer, it works just great. It's like display menu for a content type (available views).
Both are good for integrators but can't leave together (style dropdown + display dropdown are definitly wrong)
Why not just providing this in collective with all default plone's portlets with a 'style dropdown menu' using a dynmaic vocabulary ?
is just nice but I'm not sure this is a good idea to have this in the core of Plone.
comment:12 Changed 4 years ago by sunew
We implemented a solution that do not require changing existing portlets / apply to all portlets:
https://github.com/headnet/plone.app.portlets
Still need to implement using a style vocab (styles/selection are hard coded as is). But look at it as a proof of concept.
comment:13 Changed 4 years ago by alecm
Could you provide a buildout config for this PLIP in the 4.3 coredev buildout: https://github.com/plone/buildout.coredev/tree/4.3/plips
comment:14 Changed 4 years ago by eleddy
Timeline update: we would like to have all development complete by June 30th and everything reviewed by July 11th for the 4.3 release.. Please let the FWT know via here or the mailing list if you don't think things will be ready by that time.
comment:15 Changed 4 years ago by kleist
- Status changed from new to confirmed
- Component changed from Unknown to General
Confirming, just to clean up the report "Untriaged Tickets".
comment:16 Changed 4 years ago by alecm
- Cc sunew added
Any idea when the vocabulary/control panel will be ready for testing or review? Please create a plip buildout and finish the implementation ASAP for inclusion in 4.3.
comment:17 Changed 4 years ago by rossp
FYI, I created a PLIP config for you:
https://github.com/plone/buildout.coredev/commit/731bd307c9989ce9452880372e1e180fc08f0bf7
Please review and make sure it describes *all* the merges necessary if we accept and merge this implementation.
comment:19 Changed 4 years ago by mborch
- Cc mborch added
I think this concept should be generalized:
- For each portlet, if applicable, a settings icon is available on the "Manage portlets" screen.
- By clicking this link, a form is shown with the applicable settings.
- Technically, this could be implemented using named adapters, e.g. portlet assignment -> schema, and we could simply list all such named adapters and either flatten the fields or group into fieldsets (this would require schema tagging to provide fieldset labels).
To make sure that people will understand how to use this extension point, the plone.app.portlets package could implement the style-setting (this PLIP); or perhaps, the show/hide functionality could be moved into a setting instead of the current annotation storage.
comment:20 Changed 4 years ago by sunew
We cleaned up the branch the plip points to.
Currently a settings option is available on the "Manage portlets" screen. ('Meta' - should be renamed to settings).
And currently the setting of a custom portlet css class is implemented. To configure the available css-classes a control panel is added, that stores the configuration (possible css-classes) in site_properties.
But this is a problem - it requires a GS profile. It is a problem to add a gs profile to p.a.portlets - it is not run when creating a new plone site for instance. Currently you need to run the p.a.portlets profile from generic setup to set it up.
So the css class functionality could very well be moved out of p.a.portlets, if a pluggable function for extending the settings is implemented as described by Malthe above.
The adapter should supply a schema and implement retrieval of functionality specific settings (like the vocabulary of css-classes).
Other possible extensions could be: Setting if the portlet is local (already implemented in another branch) Setting tags for exclusion of portlet content by crawlers Geotagging portlets Etc. (implemented in adapters in separate modules)
/sunew
comment:21 Changed 4 years ago by sunew
Alternatively - and simpler to begin with - we could keep this portlet control panel, and add the necessary setup code of the control panel to CMFPlone.
comment:23 Changed 3 years ago by spereverde
- Summary changed from add adjustable css class option on static portlet and collection portlet to add adjustable css class option on portlets
comment:24 Changed 3 years ago by zupo
The beer & wine sprint is coming up tomorrow, lots of people will be online and sprinting. Can we get this one wrapped by the end of this week? I can help.
comment:25 Changed 3 years ago by THijs
Some points after reading everything, I haven't tried installing the PLIP branch so I don't know if it's in there already:
In the light of css frameworks and oocss. Currently styling is often applied by using several classes that combine several css traits.
- This could be applied by several checkboxes adding the checked classes.
- Help text would be possible
- Depending on the skill of the themer/integrator it would give a lot of design freedom
- With design freedom comes a lot of design responsibility, if the styles are not properly additive you can break design
- Might be to much for the users who have to apply the style to the portlet
- This could be applied by allowing spaces in the class in a select box
- The themer/integrator can allow exactly the combinations that you are allowed to use
- No help text possible
- This could be applies by allowing spaces in the class in a select box.
- The themer/integrator can allow exactly the combinations that you are allowed to use
- Help text would be possible
- Not really suitable for a lot different styles
In the light of diazotheming, it might be practical to be able to set a default. If a theme is based on bootstrap for example giving every portlet the class 'well' could make it easier just pulling the portlets over without complexer xsl rules.
comment:26 Changed 3 years ago by ctxlken
Been using collective.portletclass, which vangheezy just updated to work well with Plone 4.2 (at least) in the past couple weeks. Like the idea of a drop-down selection list rather than hand-editing style name. Originally developed by lentinj and lrowe for a series of projects we had a year or so ago. Very handy - will be real nice to have something similar in core portlet functionality that makes Diazo rules so much cleaner/easier.
comment:27 follow-up: ↓ 28 Changed 3 years ago by robzonenet
Originally, I thought that the themer could just use CSS structural pseudo-classes or attribute selectors ( http://coding.smashingmagazine.com/2009/08/17/taming-advanced-css-selectors/ ). But this isn't a simple approach for most themers and there are problems with IE 8 and below.
Something like collective.portletclass ( https://pypi.python.org/pypi/collective.portletclass ) is elegant since you can put multiple classes in that field. A pull down with already known class names would be limiting. This solution is also great since it is backwards compatible.
comment:28 in reply to: ↑ 27 Changed 3 years ago by ldr
Replying to robzonenet:
Something like collective.portletclass ( https://pypi.python.org/pypi/collective.portletclass ) is elegant since you can put multiple classes in that field. A pull down with already known class names would be limiting. This solution is also great since it is backwards compatible.
Content management is all about limiting options to achieve consistency across a site! You really want a control panel managed vocabulary of appropriate portlet classes. Supporting multiple selections might be nice, but you can always work around this with a simple drop down by using spaces in the vocabulary terms, e.g. "big red", "small red", "big blue", "small blue".
comment:29 Changed 3 years ago by bosim
I just distilled the patches we needed to implement this feature into a product:
https://github.com/collective/collective.portletmetadata
I hope at some point to make the CSS classes vocabulary editable through the controlpanel. Feel free to contribute.
/Bo
comment:30 Changed 3 years ago by esteele
- Milestone changed from 4.4 to 5.0
The Framework Team has decided to move on to Plone 5. Updating milestones accordingly.