Il manque : - une liste de produits/services fin 2007 - une price list pour fin 2007 - le taux de pénétration prévisionnel espéré par cibles pour fin 2008, - la rentabilité attendue d&apos;ici fin fin 2008 - la définition, l&apos;organisaiton et l&apos;animation de la force de vente -
Plomino plone conf2010
Plomino How to
easily build Plone custom applications through the web with small development knowledge Eric BREHAULT – Plone Conference 2010
Plone is so
powerful With no Zope/Plone development knowledge and good Plone usage knowledge, you can build a powerful intranet: ● you can structure the site easily, ● you can manage users access rights and workflows in a very granular way, ● you can extend Plone standard features with a lot of excellent products.
But you might
need a custom app Your intranet is just perfect, but at some point, you need a purchase management application. Of course, you want this application to be integrated into your intranet. What can you do ?
Create a content
type ? Plone is a CMS, a purchase request might be considered as a content-type. Let's go: 1 schema (made with ArchgenXML or Dexterity) + few collections + 1 workflow (made with uworth.northstar) = approximately what you need
Not that easy
Even if you do not necessarily need to be a developer to use the mentionned tools, it will still imply you have a good knowledge of: ● What a schema is. ● How Plone workflows work. ● How to deploy custom products.
Will it fit
the needs ? Theoretiocally, the “Purchase request is just a content-type” approach should work. Practically, you will have to deal with hundreds of small and funny extra-requirements: ● the request form has 2 specific fields when you order furnitures, ● the approval workflow is not the same if you belong to the HR department, unless the manager is in vacation, ● the price list is provided in a monthly updated CSV file stored on a LAN shared disk, ● Etc.
Will it fit
the needs ? So, practically, you will have to heavily tune the basic content-type behaviour. And if you are not a Plone expert, you are lost.
One could oppose
that what has been described here is not a simple application but a quite complex one. If complex applications cannot be easily produced by non Plone experts, that is fair enough. My opinion: ● It is not a complex case, it is just the difference between a theorical case and a real case. ● Most part of time, real applications are not content- types. ● Non Plone experts must be able to produce real business applications. "Let no man ignorant of Plone enter here." Plato
● Plomino allows
to develop, deploy and maintain custom applications entirely from the Plone web interface. ● There is no schema, no data model, the application designer does not have to worry about the persistence, he/she will design forms, data will be saved accordingly. ● Everything can be scripted in order to adapt the behaviour to fit the actual needs. Plomino principles
1.Add a new
Plomino “database” as any Plone content-type, ➔ The database is the root element which support the entire application. 2.Design some “forms” in TinyMCE, ➔ A form offers a layout and a set of fields. 3.Forms allow to create “documents”, or provide useful screens (menu, search, reports, etc.), ➔ Documents are just a set of items. The items may match the form fields, or not. 4.Create some “views” to list / filter / sort the documents in different ways. Create a Plomino application
Forms are created
using TinyMCE. A form is just a freely editable rich text content where the user can insert: ● Fields, ● Actions, ● Hide-when formulas, ● Sub-forms. Create Plomino forms DEMO
A field can
be: ● Editable: the user enters its value and it is stored in the document, ● Computed: a formula computes its value and it is stored in the document, ● Computed for display: a formula computes its value but is not stored, ● Computed on creation: a formula computes its value at creation time. Field modes DEMO
Plomino provides a
set of basic fields: Text, Rich text, Number, Date/time, File attachement, Selection list. And also advanced fields: ● Names: to select Plone members. ● Doclinks: to create links between documents. ● Datagrids: to manage editable dynamic tables. ● Google chart and Google visualization: to create rich charts or maps. Different field types DEMO
Formulas are used
to script the regular Plomino behaviour: ● Compute field values, ● Implement some custom actions, ● Hide some part of a form contextually, ● Process documents, ● Handle events, ● Handle redirections, ● Etc. Formulas are written in Python, and are compiled as Python scripts. Formulas everywhere DEMO
2 applications: ●
Flood alert SMS subscription mechanism Map display, connection to an external realtional database, export to CSV. ● Hydro-sensors maintenance system Visit planing, visit sheet import/export. Business cases DEMO Adour river flood forecasting agency
Contacts database Connexion
with Plone members. Complex queries. Large amount of contacts (> 8000) Business cases DEMO International Council for Science
Business cases ●
Extremely various Plomino applications, built by extremely various people: – Archeologists, – Lawyers, – Real estate managers, – Librarians, – And even Plone experts. ● Any example in the room ?
Is it serious
? ● Alexander Limi said yesterday: “Recruit people”. ● A TTW application builder like that is good for non- experts. ● But can it meet development standard expectations ? Let's see how Plomino handles: ● Deployment, ● Maintenance, ● Debugging, ● Testing, ● Content synchronization.
Deployment and maintenance
● Plomino provides an import/export mechanism. ● The design (the application structure) can deployed over HTTP from a server to another (even from between a Plone 3 and a Plone 4 instance). ● It can be exported as XML (and then imported back somewhere else). ● The resulting XML can be managed in a SVN (or other) repository. ● It allows partial import/export. DEMO
Testing Testing as
usual: ● Selenium ● Doctests With doctests, the principle is to create a blank Plomino db, then import your current XML design version, then run your scenarios. It can be then automated on Hudson.
Testing Import basic-example
db >>> f = open(os.path.join(dir, "samples", "basic-example.xml")) >>> id = folder.invokeFactory('PlominoDatabase', id='basic-example') >>> db = getattr(folder, 'basic-example') >>> db.at_post_create_script() >>> wf_tool = self.portal.portal_workflow >>> wf_tool.doActionFor(db, 'publish') >>> xmlstring=f.read() >>> db.importDesignFromXML(xmlstring) >>> db.refreshDB() >>> f.close()