Re: modify accordion behavior and appearance

On Tue, Oct 14, 2014 at 1:28 AM, Chuck Theobald <[email protected]> wrote:
> This is great stuff, Jean! Thanks for the pointers.

No problem, feel free to ask.

Even better, compile your list of questions somewhere so that it can
be integrated in the documentation.

> I think the confusing thing for me is where to find what I need to modify.
> For the accordion, the target is in the file system.

It often depends on the use case. Roughly you can:

1. modify the product directly, i.e.
Products/CMFPlomino/browser/javascript/plomino.accordion.js
2. override it in your policy product, e.g.
uoregon/site/jbot/Products.CMFPlomino.browser.javascript.plomino.accordion.js
3. for many views, override it in the ZMI (web UI, Zope Management
Interface) at http://.../portal_view_customizations/registrations.html
4. for many other resources, edit it in the ZMI at
http://.../portal_skins/manage_main (here you can also introduce
resources that override names anywhere in Plone)

You would do 1. only if you were a savage, or if you were working on
the product in question.
Normally these days the civilized way for an admin would be 2.
In some cases where you're a site editor without the ability to deploy
code to the server, you might do 3. or 4. as a stopgap, until such
time as your admin has time to implement your change via 2. (policy
product).

3. and 4. can cause trouble if workarounds or hacks are forgotten
about and left in place beyond their expiry date, which happens
incredibly reliably.

> Other items are less
> clear: modify through the WebUI? in the ZopeDB? This leads to a lot of time
> hunting,

Zope is a very flexible system. For example you can change the
behaviour of some part of a site by dropping a Python Script or Page
Template in some folder via the ZMI. However in the context of Plone
we don't do this any more. You can do all the same things in a policy
product which can be checked into version control, deployed as a
Python egg via buildout, and tested via unit and functional tests.

So the short answer is: just don't edit anything via the ZMI.
You can browse the ZMI for information, but that is also incomplete.
The ZMI has not been updated consistently to provide a complete and
true picture of what's going on under the hood. For many things it's a
great source of information, but it doesn't have all the answers.

Sadly I have to soften my blanket recommendation not to do anything
via the ZMI ... tweaking a workflow by adding a guard condition at
e.g.
http://.../portal_workflow/simple_publication_workflow/transitions/submit/manage_properties
is just so easy compared to doing the same thing via a policy product.
You might do it for expediency's sake. Just remember you need to get
it into a policy product or your future self will hate you.

> exacerbated by the fact that I have no reliable way to search the ZopeDB.

The ZODB is just a big ol' Python dictionary.
Using https://pypi.python.org/pypi/Products.PDBDebugMode together with
https://pypi.python.org/pypi/ipdb you even get tab-completion and
introspection on all methods and attributes on all objects. This lets
you poke around from a debug prompt very handily.
Combine that with an editor and a good tags file to allow you to
browse the source code jumping to class and method definitions.

This way of exploring has a couple of drawbacks:
- it doesn't offer guidance --- it shows APIs at all levels without
distinction. For guidance follow the docs, especially `plone.api`.
- it helps you to explore methods derived from class inheritance.
Increasingly, Plone is making use of a component-based approach where
an object instance is adapted to an interface at runtime, extending
the object with the methods specified by the interface. So these
methods won't show up unless you're doing the adaptation. See e.g.
https://github.com/collective/collective.geo.contentlocations/blob/master/src/collective/geo/contentlocations/README.txt#L22

In a debug session it looks like this:

```
>>> basin
<Basin at /.../basins/lmes/barents-sea>
>>> basin.isGeoreferenceable()
Traceback (most recent call last):
  File "<console>", line 1, in <module>
AttributeError: isGeoreferenceable

>>> from collective.geo.contentlocations.interfaces import IGeoManager
>>> geobasin = IGeoManager(basin)
>>> geobasin
<collective.geo.contentlocations.geomanager.GeoManager object at 0x116edf10>
>>> geobasin.isGeoreferenceable()
True
```

You can see that you'd never find out about the `isGeoreferenceable`
method unless you were interested in
`collective.geo.contentlocations`.

For searching, the `ZopeFind` method is available on Zope folders, and
the Zope catalog can be queried from Python or the ZMI.

The Plone docs are improving fast http://docs.plone.org/ but are still
incomplete and sprawling.
For anything you need to do, take
http://docs.plone.org/external/plone.api/docs/index.html as starting
point.
If you need to do something that is not covered by `plone.api`, raise
it so that it can be considered for inclusion.

Don't forget http://docs.zope.org/zope2/zope2book/index.html to
clarify the basics.

> I attribute this to me being a stranger in a strange land. I've heard the
> learning curve on Plone is about a year long, I can see why.

Too much of that time is spent going up the garden path.
We should focus on keeping newcomers on the well-trodden recommended paths.
So please make a noise when you're floundering, and document your
trails, so that signposts are improved for people following.

Hope this helps!
-- 
jean                                              . .. .... //\\\oo///\\

------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho