Ticket #12266 (confirmed PLIP)

Opened 4 years ago

Last modified 3 years ago

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:1 Changed 4 years ago by spereverde

  • Cc spereverde added

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: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:11 Changed 4 years ago by toutpt

  • Version 4.1 deleted

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.

Last edited 4 years ago by alecm (previous) (diff)

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:18 Changed 4 years ago by bosim

  • Cc bosim added

comment:19 Changed 4 years ago by mborch

  • Cc mborch added

I think this concept should be generalized:

  1. For each portlet, if applicable, a settings icon is available on the "Manage portlets" screen.
  1. By clicking this link, a form is shown with the applicable settings.
  1. 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:22 Changed 4 years ago by eleddy

  • Milestone changed from 4.3 to 4.4

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.

Last edited 3 years ago by zupo (previous) (diff)

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.

Note: See TracTickets for help on using tickets.