Note: if this function is not visible in your Plone site, go to ZMI / portal_actions / document_actions / print, check Visible, and save. The Print action will be displayed in the bottom-right corner of the content area.

The Plone print function allows to print the current page and as Plone provides some print-specific CSS, the rendering is correct (navigation, portlets, background, etc., are all removed, so the printed document only contains the content itself).

Nevertheless in some cases, you might need to change the document content itself for printing (for instance, if some parts of the Plomino documents are dynamic, or you prefer to hide some of the fields, etc.).

To do so, you need to create a Plomino form that will produce the print-specific layout. You can create it from scratch (and then just make sure you create fields having the very same ids as the fields from the original form), or you can just copy/paste your original form (go to your database contents tab, and then copy/paste the form) and then change its layout and/or its fields settings.

Let's assume your regular form is frmEmployee, and your print-specific form is frmEmployeePrint.

If you open an employee document using its regular url, like this:

http://www.plomino.net/samples/printable-documents/plomino_documents/eric-brehault

it is displayed using the form it has been created with, in our case: frmEmployee.

If you want to display it with the frmEmployeePrint form, you can use the openwithform url parameter:

http://www.plomino.net/samples/printable-documents/plomino_documents/eric-brehault?openwithform=frmEmployeePrint

As you can see, it does display the same document but the layout is the one implemented by frmEmployeePrint.

So, to provide access to the printable version of a document, we need to generate such alink into the frmEmployee form.

We do it using a computed for display rich text field having the following formula:

html="""<a href="%s?openwithform=frmEmployeePrint" target="_new">Print</a>""" % context.doc_url()
return html

Note: we add target="_new" so the resulting page is opened in a new tab in the user web browser.

And now you just need to make sure the web browser print function is called as soon as the user open this page.

You do it by adding a computed for display rich text field in frmEmployeePrint:

html="""<script>
this.print();
</script>"""
return html

Note: the resulting print uses the Plone print-specific CSS, but if you do not want that, you can use the /OpenBareDocument directive that will only return the Plomino form layout only:

http://www.plomino.net/samples/printable-documents/plomino_documents/eric-brehault/OpenBareDocument?openwithform=frmEmployeePrint

This way you can control entirely the print layout independently from Plone.

The sample can be downloaded here.

Here is an example:

result = db.getCache('my_cache_key')
if not result:
    result = make_something_which_cost_CPU(stuff)
db.setCache('my_cache_key', result)

The first time the formula will be called, the make_something_which_cost_CPU function will executed, and the result will be put into the cache.

Next time the formula is called, the result is directly read from the cache.

As the cache key is a constant ('my_cache_key'), it will be the same in all the cases (for all the users, in all the pages, etc.).

But of course, the make_something_which_cost_CPU function might return a different value depending on the context. If so, you need the produce a cache key that will reflect this context accurately.

For instance, if the result is different according the use, an accurate cache key could be:

cache_key = "result_for_"+context.getCurrentUser().getMemberId()

or depending on the document:

cache_key = "result_for_"+context.id

or anything you might need.

Another use case is the repeated usage of a same formula in the same page: sometimes, when rendering a document using a form, several computed fields make the same computing (typical example: you display a table of values, and also a bar chart based on those values).

The code itself can be factorized using a script library in the /resources folder, but it will be run twice anyway when rendering the page.

And it might impact the performances.

Unfortunately, setCache and getCache might not be relevant because you want the formula to be re-evaluated everytime a user displays the page. In that case, you can use setRequestCache and getRequestCache, so the cache will be associated with the current request, and will only last as long as the request will:

result = db.getRequestCache('my_cache_key')
if not result:
    result = make_something_which_cost_CPU(stuff)
db.setRequestCache('my_cache_key', result)

• either by using the Plomino API to export the content of any PlominoView,
• either by producing your own CSV content using a PlominoAgent.

Let's consider a database where documents have the following items: employee name, country, and age.

If you call /exportCSV or /exportXLS on view's URL, you get the actual content of the view as CSV or XLS.

If you want to provide a button to your users, just create a Redirect action into the view to produce the URL:

context.absolute_url()+"/exportCSV"

Now, let's imagine you want to process the data before producing the output. For instance, instead of exporting the age value, you want to export "Senior" or "Junior" depending on the age is higher or lower than 40.

To do that, we create an agent which will collect the data into an array, and then return the array content as CSV:

db = context.getParentDatabase()
all = db.getAllDocuments()
results = []
for doc in all:
 age = doc.age
 if age >= 40:
 age_range = "Senior"
 else:
 age_range = "Junior"
 results.append([doc.employee, doc.country, age_range])

context.REQUEST.RESPONSE.setHeader('content-type', 'text/csv; charset=utf-8')
context.REQUEST.RESPONSE.setHeader("Content-Disposition", "attachment; filename=my_special_export.csv")
context.REQUEST.RESPONSE.setBody(array_to_csv(results))

To produce an XLS export, do not return a CSV content but an HTML table, and just change the content-type header to 'application/vnd.ms-excel; charset=utf-8', to pretend it is an actual Excel content, so your browser will launch the appropriate application to display it (that is basically what the exportXLS Plomino method does: see source code)

Note: of course in that very simple case, we could also have create an extra view with a column displaying Senior or Junior, and then export that view.

And here again you can provide a redirect acgion to call the agent url more easily:

context.getParentDatabase().absolute_url()+"/export_csv/runAgent"

We want to do a dynamic search form like that.

Let's assume we have built a basic database to post job descriptions. Our frmJob form contains the following fields:

• job_title (text)
• job_location (a selection list)
• job_skills (a selection list)
• job_description (text)

Let's make sure they are indexed so we can query the Plomino index on those fields.

Principle

To provide our search feature, we will not create a single Dynamic page form containing the criteria fields, a submit button and a computed field to display the results.

We need to split it in two different forms:

• the search form (named 'dynamicSearch' in the sample db), containing the editable criteria fields,
• the result form (named 'filtredResults' in the sample db), able to read the submitted criteria and to produce the results.

And, most importantly, we will add some JQuery code into the search form in order get the current values of the criteria, submit them to the result form, extract the produced results and insert them dynamically into the search form.

The result form

The result form contains only one field named 'results'. It is a computed for display rich text field.

Its formula reads the criteria values submitted in the request, performs the search and format the results as HTML:

db = context.getParentDatabase()

query = {'Form': 'frmJob'}

# read submitted criteria
any_criteria = False
job_location = context.REQUEST.get("job_location")
if job_location:
  any_criteria = True
  query['job_location']=job_location

job_skills = context.REQUEST.get("job_skills")
if job_skills:
  any_criteria = True
  query['job_skills']=job_skills

# perform the search
if any_criteria:
  search_results = db.getIndex().dbsearch(query)
else:
  return """Please select at least one criteria..."""
search_results_cnt = len(search_results)

# format the output
html = u''
html += """ %(found)d result(s) found...<br />""" % { 'found': search_results_cnt}
html += "<ul>"
for result in search_results:
  doc = result.getObject()
  html += """<li><a href="%(link)s">%(title)s</a> (%(location)s)
<p><span class="discreet">%(description)s</span></p>
<p>Skills: %(skills)s</p></li>
""" % {'link': doc.absolute_url_path(),
'title': doc.getItem('job_title'),
'description': doc.getItem('job_description'),
'location': doc.getRenderedItem('job_location'),
'skills': doc.getRenderedItem('job_skills'),
}
html += "</ul>"
return html

So if we call an url like this:

http://www.plomino.net/samples/jquery-example/filteredResults?job_location=Africa

we get the list of all jobs located in Africa.

But, actually, we are not interested in the entire Plone layout (navigation, portlets, etc.), and as we plan to load this page via an AJAX call just to extract the results list, we might prefer to load a smaller page.

An url like that will be more accurate:

http://www.plomino.net/samples/jquery-example/filteredResults/OpenBareForm?job_location=Africa

Note: direct access to /filteredResults makes an implicit call to /filteredResults/OpenForm, here we explicitly calls /filteredResults/OpenBareForm.

The search form

The search form contains editable fields for criterias (in the sample: job_skills and job_location).

It also contains a computed for display rich text field, named 'display_results' producing two elements:

• an empty <div id="result_list"> tag which content will be loaded by a JQuery call,
• a <script> tag containing the javascript code.

This javascript code defines a function which serializes the form's inputs current values to produce the accurate query on /filteredResults/OpenBareForm (using JQuery.serialize()), then calls the resulting url, extracts the content, and inserts it in the target div tag (using JQuery.load()).

Then we bind the form's onChange event to this function. We also insert the spinner.gif image into the target div, so the user knows the results are loading.

searchurl = context.getParentDatabase().absolute_url_path() +"/filteredResults/OpenBareForm?"
html="""
<script>
function get_results() {
    criteria = jq('#plomino_form').serialize();
    jq('#result_list').load("%s"+criteria+" #plomino_form");
}
jq(document).ready(function() {
  jq('#plomino_form input').change(function() {
  jq('#result_list').html("<img src='spinner.gif' />");
  get_results();
  });

  get_results();
});
</script>
<div id="result_list"></div>
""" % searchurl

return html

The entire sample can be downloaded here so you can import into your own Plone site (or on plomino.com) and play with it.

One part of this reference id being an auto-increment chrono, how to generate it ?

A basic approach could be to count the existing documents and add one to the result, but if some documents are deleted, it migh produce identical ids.

Another basic approach is to get the last numbered document, extract its chrono value, and add one.

But the cleaner approachto implement an auto-increment chrono is to create a specific form that will be use to create a unique document where we will store the current chrono value.

Let's create a form named frmChrono containing a number field named 'chrono'. You create only one doc with this form, and you enter the value 0 in the field.

Then, in your main form (where you need to handle the auto-incremented value), you create a Computed on creation number field (named ReferenceID for instance) with the following formula:

db=plominoDocument.getParentDatabase()
searchchrono=db.getIndex().dbsearch({"Form": "frmChrono"})
chronodoc=searchchrono[0]
currentvalue=chronodoc.chrono
newvalue=currentvalue+1
# store back the new chrono in the chrono doc
chronodoc.setItem("chrono", newvalue)
# return the reference id properly formatted
return "A0-ACME-%03d" % newvalue

Note: if you use Plomino <1.11, line 3, you need to call getObject() to get the actual document:

chronodoc=searchchrono[0].getObject()

If the data stored in the database must be translate, the immediate and obvious solution is to produce several distinct databases (one per language).

But if the data has not to be translated (figures, names, phone numbers, etc.), it is not an ideal solution because it  requires much more work to maintain an update the data.

In that case, the best way is to build a unique database and make sure the produced screens are translated.

There are several approaches.

Distinct forms

You can create distinct forms (one per language) where the layout will contain the appropriate labels and text according the language.

To open documents with the proper form, you use the Form formula in your views:

lang = context.restrictedTraverse("@@plone_portal_state/language")()
return "frmhotel"+lang

or you use ?openwithform parameter in Redirect actions formulas (or anywhere else you produce URLs):

lang = context.restrictedTraverse("@@plone_portal_state/language")()
return context.doc_url()+"/EditDocument?openwithform=frmhotel"+lang

Unique form

You can also create one unique form, and in its layout replace all labels and text with computed for display fields which will produce the appropriate labels:

label = {'en': u"Title", 'es': u"Titulo", 'fr': u"Titre", 'nl': u"Titel"}
lang = context.restrictedTraverse("@@plone_portal_state/language")()
return label.get(lang, label['en'])

Part 2

Part 2

Thanks to Lloyd Person IV for contributing this screencast.

But a custom Plomino field type can be declared to Plomino from a custom package in order to extend the Plomino behavior.

Example:

 from zope.formlib import form
 from zope.interface import implements
 from zope import component
 from zope.pagetemplate.pagetemplatefile import PageTemplateFile

 from zope.schema import getFields
 from zope.schema import Text, TextLine

 from Products.Five.formlib.formbase import EditForm

 from Products.CMFPlomino.interfaces import IPlominoField
 from Products.CMFPlomino.fields.dictionaryproperty import DictionaryProperty

 from Products.CMFPlomino.fields.base import IBaseField, BaseField

A Zope schema defines the field setting parameters.

 class IRomanNumberField(IBaseField):
     """
     Roman number field schema
     """
     color = TextLine(title=u'Color',
                 description=u'Font color to apply to roman number display.',
                 required=False)
           

A class derivated from BaseField will implement this interface.

It must mandatorily contain:

• plomino_field_parameters: it declares the field main parameters,
• read_template: the PageTemplate in charge of rendering the field in read mode,
• edit_template: the PageTemplate in charge of rendering the field in edit mode.

It can also overwrite the different methods of BaseField, like processInput (in charge of converting the submitted value into the actual item value, or validate (in charge of validating the submitted value before saving).

 class RomanNumberField(BaseField):
     """ This field stores integers as roman numerals
     """
     implements(IRomanNumberField)
     
     plomino_field_parameters = {'interface': IRomanNumberField,
                                 'label': "RomanNumber",
                                 'index_type': "FieldIndex"}
     
     read_template = PageTemplateFile('roman_read.pt')
     edit_template = PageTemplateFile('roman_edit.pt')
     
    def validate(self, strValue):
         """
         """
         errors=[]
         fieldname = self.context.id
         try:
             v = int(submittedValue)
         except:
             errors.append(fieldname + " must be an integer.")
         return errors
     
     def processInput(self, strValue):
         """ convert int to roman (example based on vegaseat code snippet)
         """
         number = int(strValue)
         numerals = { 1 : "I", 4 : "IV", 5 : "V", 9 : "IX", 10 : "X",
                      40 : "XL", 50 : "L", 90 : "XC", 100 : "C", 400 : "CD",
                      500 : "D", 900 : "CM", 1000 : "M" }
         result = ""
         for value, numeral in sorted(numerals.items(), reverse=True):
             while number >= value:
                 result += numeral
                 number -= value
         return result

The plugin field must be provided as an utility so Plomino can find it (the utility name must be in upper case):

 component.provideUtility(RomanNumberField, IPlominoField, 'ROMANNUMBER')

And the SettingForm must built based on the field's schema: (no customization needed here)

 for f in getFields(IRomanNumberField).values():
     setattr(RomanNumberField, f.getName(),
             DictionaryProperty(f, 'parameters'))

 class SettingForm(EditForm):
    """
    """
    form_fields = form.Fields(IRomanNumberField)

Then in configure.zcml, declare the field as adapter for PlominoField: (assuming that previous code is in romannumber.py)

<adapter
         for="Products.CMFPlomino.interfaces.IPlominoField"
         provides=".romannumber.IRomanNumberField"
         factory=".romannumber.RomanNumberField"         /> 

and declare the settings form as a browser page (its name must be xxx+'settings' where xxx is the utility name in lowercase)

<browser:page
         name="romannumbersettings"
         for="Products.CMFPlomino.interfaces.IPlominoField"
         class=".romannumber.SettingForm"
         permission="plomino.DESIGN_PERMISSION"         />

The 2 page templates can be based on the following examples:

roman_read.pt:

<tal:block tal:define="v options/fieldvalue"
 tal:content="python:str(v)">XXII</tal:block>

roman_edit.pt:

<span>
    <input type="text"
       tal:attributes="name options/fieldname;
 value options/fieldvalue" />
</span>

This field would be named "employee" for instance

Note: if you want it to store the id of the user who creates the document just make it Computed on creation, with the following formula:

plominoDocument.getCurrentUser().getMemberId()

To restrict access to the document, we will use the onOpenDocument event: if this event formula returns anything false (False, None, 0, ""), the document opening is allowed, but if it returns a non-empty string, the opening is not allowed and the returned string is display to the user as error message.

So edit your form, and go to Events tab, and enter a formula like this in the On open document event:

if plominoDocument.getCurrentUser().getMemberId()==plominoDocument.employee:
  return None
else:
  return "You are not allowed to view this document." 

If you also want to allow users having a given role (let's say [controller]), you would use a formula like this:

if plominoDocument.getCurrentUser().getMemberId()==plominoDocument.employee:
  return None
roles=plominoDocument.getCurrentUserRoles()
if "[controller]" in roles:
  return None
return "You are not allowed to view this document."