Zoho integration for Python and Plone CMS

Zoho is a web application provider competing with Google Docs, Microsoft Office and Live.

Zoho provides a very wide set of browser based applications from text editing and spreadsheets to project management and customer relationship management (highlighted items should ring a bell for small software development companies). Especially the last one, CRM, is a very attractive deal as you get a hosted complex CRM application with API services for very affordable or free price. Small organizations are not necessarily rich enough to go for Salesforce API supported edition which would be 135 € / month / user.

mFabrik has been working on Zoho Python bindings as we use Zoho internally.

Zoho API is HTTP GET/POST based.

• Authentication, which is called a ticket in Zoho language, is HTTP POST with custom plain-text responses. The same authentication mechanism works in-browser (Javascript) and for machine-to-machine communication as far as I know
• Most functions can be performed as HTTP POST or GET. If you need to input compex data (like CRM leads), you’ll do it as HTTP POST of custom XML payload
• Some functions expose the output as JSON for HTTP GET, so that it can be directly consumed inside browser Javascript

mfabrik.zoho is a GPL’ed Python library which provides basic facilities for Zoho API calls. Currently the feature set is very CRM weighted, though it can be easily expanded for other Zoho applications.

mfabrik.plonezohointegration is a Plone CMS add-on product which marry Plone and Zoho together. The add-on provides a control panel where you can enter Zoho API key details for Plone. Forms for CRM lead generation are provided as standalone and as a portlet (you can see them in action on our web and blog site).

The source is hosted on Github, so you can easily start tailoring it for your own organization needs. I happily accept all merge requests, providing that unit tests for new features are included. If you do not feel comfortable with Python programming, but still want to integrate Zoho to your systems, please contact us for further help.

Read our blog  Subscribe mFabrik blog in a reader Follow us on Twitter Mikko Ohtamaa on LinkedIn

Plone Developer Manual, take #0.1

The first public version of  Plone developer manual is available here.

It is still very much draft, but I assure you will find it useful. You will find it even more useful after you put in the answers for your own problems.

In my previous Plone developer documentation rant my flow of though was little abstract and I couldn’t clearly explain how I want the community to maintain this crucial piece of documentation.  This time I made a comic.

* How to get support

** How to update Plone Developer Manual

Helping people and writing Plone developer API manual – killing two birds with one stone

Plone developer API documentation could be better. For this very reason, people ask questions regarding how to do a simple thing or two in Plone code. Asking questions is often the only way to fight through the monstrous codebase. Luckily these questions usually receive answers from the active community in product-developers@ list and IRC.  See also prior mailing list dicussion.

However, asking the same questions again and again, or asking the question in the first place, is undesirable way to proceed. A proper way to fix the problem would be have a proper documentation voiding the need to ask the question in the first place. Since documenting Plone API is a huge task, I propose the following to get things bootstrapped:

1. Wherever and whenever someone asks a question regarding Plone code development do not answer directly

2. Instead, write the example code snippet and commit it to https://svn.plone.org/svn/collective/collective.developermanual/trunk (collective commit access needed)

3. Give the link to the SVN trunk file as an answer This way we should slowly start building up a “developer reference” which covers the most common API use cases.

https://svn.plone.org/svn/collective/collective.developermanual/trunk is a mess. Do not care about this little detail. Just toss in your .txt files. The docteam and I will properly proof-read and structure it in the future. As soon as we code snippets keep flowing in I am happy!

Example

Here is how I helped some unlucky person struggling with DataGridFrield and created some documentation during the process.

Private email question:

I have been using your excellent DataGridField add-on on a projet, where as webmanager I add variable lists of information within an objet.  However now I would like to build a script that would insert new rows and content automatically : let’s say a User calls a specific objet ‘A’ from time to time, I would like to have a DataGridField that will record incrementally these calls (with columns like “when”, “how long”, “what result”) each time they are made, without the User having to do anything.

I tried to find an answer in the code but I’m not fluent enough in Python yet to understand everything I read.  Could you tell me how I could build that script or where shall I look for clues ?

Private email answer:

Please also read some guidelines I tried to come up for documentation.

How do you prefer your documentation?

Lately there have been three long email chains related to Plone development documentation here, here and here (total ~100 messages). This little post tries to summarize the current discussion.

I think the dicussion is mostly fueled by third party developers’ frustration with the current development documentation situation. Developing for Plone is difficult, since finding references, how tos and examples for those little things you need is very hard. This is a turn off for many developers who would otherwise use this great system – high developer learning curve and gaps in the documentation makes the system useless.

Points everyone agree are

• Plone development documentation is not good
• Sphinx is good for API documentation – already happening
• Contributors are needed

Points discussed are

• Should developer documentation be more open ended (Wiki-like). This covers
  • Developer manual
  • How tos and other misc. references
  • API documentation
• Mostly, it is not about generic end user, admin or system integrator or getting started documentation (here, here)

Pro wiki-like documentation stances

• It should be more open ended (here, here, here)
• It’s better to have something messy instead of nothing at all – the current approval process discourages contribution (here)

Con wiki stances

• It should not be open ended, since this results to messy documentation (here, here)
• There should be less plone.org documents (here)
• Wikis are bad (here)
• Incomplete wikis are discouraging (here)

Let’s wait and see where this goes.