[Framework-Team] Thought about Mockup/Plone5/Integration

Ramon Navarro Bosch ramon.nb at gmail.com
Thu May 29 09:06:16 UTC 2014


Some weeks ago we talk about Mockup integration on Plone and I've been
doing some thoughts on that. I tried to resume them so we can talk about
that. First of all I when deep on all mockup code to understand all the
idea/code and I must say: is a great piece of software! Nathan and Rok, you
did a really good job and all the patterns idea is really great !

Customization
=============

It should be a easy way to customize the widgets/structure. In other words
we need to find a way so we can have the template on plone and we can
overwrite, define which buttons we want, beeing able to skin them. Right
now it's not possible to remove one button or skin it. I wonder if Reactjs
is a good decision for that (thinking about the future)

Bootstrap
=========

Mockup is depending on a lot of BS css files and that makes impossible to
use another framework for integrators. The first idea should be that we
change all the classes to a different namespace so we can create a
plone-XXXX classes (like plone-modal) and we can define them using
'reference' keyword on less so we don't import bootstrap by itself.

The main problem is that any change to classes breaks some test that
depends on that and makes really hard to keep track.


Toolbar & Structure
===================

As I see, mockup project is intented to be a framework to be used anywhere
else, in my opinion toolbar and structure patterns should be more tied to
Plone to make them more easy to implement and maintain and integrate. I'm a
bit afraid that adding so general behavior to all this staff adds more
complexity and I don't see the point to do it. For example, it will be easy
to implement and maintain a pattern for toolbar that is tied to plone
structure, so we can test it using the RobotFramework engine and linked to
some browser views that provide the needed information ( as the same for
the structure ). It will be easy to customize.


Translation
===========

I don't see any way that widgets/structure/mockup is going to be
translated, and is a big deal because different labels can break the
design, imagine on structure where we have so much buttons, in some
languages that may be a problem where the label is much bigger.

AMD & Uglify
============

It's hard for developers that are willing to interact with the js on
development to work on the js uglified and minimized. There is the option
to use the mockup repository so you get js by itself, but that means that
we need to download a big repository, download a lot of node modules and
it's hard to do that on the integrator/plone developer point of view. I
would prefer to use the actual jsregistry or some replacement on plone that
can provide the clean js and the merged and cached version as we have now.

When you have mockup installed (dev version) you get the AMD version (
require.js async ) so you get the jquery and other staff after your loaded
js. That is completly not working for some simple use cases that need to
see what's going on. Recently I'm doing a project with faceted navigation
and widgets and it was completly a mess to find out why mockup js was
complaining, I need to add mockup to src, bootstrap, wait and wait, and
after that I coundn't see the problem because it's js was loaded after
faceted.

-----------

So in my opinion I would try to make Mockup smaller and closer to plone so
it's not so hard to think in generic. I would also create specific patterns
for plone without the generic behavior and on the CMFPlone repository and
beeing tested with RF. It can be also an example for people that are going
to create their own patterns. Most of my opinions I know that maybe they
are'nt the best generic solutions, but I'm more worried to have a Plone 5
working and tested out than having a generic pattern.

R

-- 
Ramon a.k.a bloodbare
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.plone.org/pipermail/plone-framework-team/attachments/20140529/b2bbea8c/attachment.html>


More information about the Framework-Team mailing list