Are there any example add-ons where to look at when one would like to
1) Create custom action adapters for PloneFormGen
2) Add new field types to PloneFormGen
The Plone collective has several examples:
http://svn.plone.org/svn/collective//Products.PloneFormGen has a directory 'adapters' with two example and 'fields' with one example.
Grepping through an 'svn ls' of the collective gives these results:
collective.civicrm.civicrmpfgadaptor/
collective.documentpfgadapter/
collective.pfg.creditcardfields/
collective.pfg.downloadfield/
collective.pfg.masterselect/
collective.pfg.silverpop/
collective.pfg.sslfield/
collective.pfg.verkkomaksut/
pfg.donationform/
pfg.drafts/
raptus.multilanguagepfg/
sc.pfg.brazilianfields/
uwosh.pfg.d2c/
Of those, I have seen a lot of activity recently on collective.pfg.verkkomaksut.
http://plone.org/products/salesforcepfgadapter has some examples, but probably on the more complex side.
All PFG types, adapters etc. are all based on Archetypes. Related example code can be found in PloneFormGen/content. The saveDataAdapter.py or fields.py files provide reasonable example code...
Related
I'm new to python and I'm comming from the c# world.
Over there it seemed like the repository pattern was the way to go, but I am having trouble finding any tutorials of how to best do this on Python.
edit I understand that it can be implemented, I'm just wondering if there is any reason why I am finding close to nothing for how to go about doing this.
Thanks!
I wasn't immediately familiar with the "repository pattern", so I looked it up. It appears to be the idea of putting a more general API, like a dictionary-like key/value lookup, in front of a database or other data store. It seems that the idea is to add an additional layer of abstraction that can allow multiple types of data sources (like both a relational database and a CVS file) to be accessed transparently via a common API.
Given this definition, I can think of no reason why this design pattern wouldn't be equally applicable to a problem addressed with Python vs any other programming language.
I just need the simple client server direct messaging in django and not getting what is the best and efficient way to do. I don't want to implement django channels as I think this is complex and provides extra functionaly which I don't need.
One article that I found useful was and wanted: https://pypi.org/project/django-directmessages/
But implementing it cause different issues like :
cannot import name 'python_2_unicode_compatible' from 'django.utils.encoding'
I have found that this is not supporting django 3.0.2 which I have. So can anyone explain me some simple way to implement some direct message functionality? Any custom db model?
You may want to check this out. If you want messages to be 'instant' you may check django-channels. If these two don't really help, you may want to create your own structure like I described here.
Why is Kinto using Cliquet and what is the difference between the two ?
Disclaimer: I am one of the authors of both tools. Since this is frequently asked question, I thought it would be relevant to share a proper answer here :)
At Mozilla Services we regularly implement and deploy micro-services.
Since most services share the same production requirements (in terms of monitoring, REST protocols etc.), we decided to develop and package a reusable toolkit using Cornice.
Kinto is one of those services. It uses Cliquet as one of its core libraries.
The Kinto HTTP API is made of several REST endpoints, that all share a set of common properties (filtrable, sortable etc.). The common code base for those REST resources is implemented as a reusable class in Cliquet.
We really like the name Cliquet. However, given the confusion of its scope, we will probably (some day) split it into two packages, called like cornice-mozprod and cornice-crud.
Kinto and Cliquet have now be merged together, and cliquet is no longer a thing.
See all the nifty details at https://mail.mozilla.org/pipermail/kinto/2016-May/000119.html
Let's take an example on which I run a blog that automatically updates its posts.
I would like to keep an entity of class(=model) BlogPost in two different "groups", one called "FutureBlogPosts" and one called "PastBlogPosts".
This is a reasonable division that will allow me to work with my blog posts efficiently (query them separately etc.).
Basically the problem is the "kind" of my model will always be "BlogPost". So how can I separate it into two different groups?
Here are the options I found so far:
Duplicating the same model class code twice (once FutureBlogPost class and once PastBlogPost class (so their kinds will be different)) -- seems quite ridiculous.
Putting them under different anchestors (FutureBlogPost, "SomeConstantValue", BlogPost, #id) but this method also has its implications (1 write per second?) and also the whole ancestor-child relationship doesn't seem fit here. (and why do I have to use "SomeConstantValue" if I choose that option?)
Using different namespaces -- seems too radical for such a simple separation
What is the right way to do it?
Well seems like I finally found the relevant article.
As I understand it, pulling all entities by a specific kind and pulling them by a specific property would make no difference, both will require the same type of work on the background.
(However, querying by a specific full-key, is still faster)
So basically adding a property named "Type" or any other property you want to use to split your specific entities into groups is just as useful as giving it a certain kind.
Read more here: https://developers.google.com/appengine/articles/storage_breakdown
As you see, both EntitiesByKind and EntitiesByProperty are nothing but index tables to the original key.
Finally, an answer.
Why not just put a boolean in your "BlogPost" Entity, 0 if it's past, 1 if it's future? will let you query them separately easily.
i wonder wether there is a solution (or a need for) an ORM with Graph-Database (f.e. Neo4j). I'm tracking relationships (A is related to B which is related to A via C etc., thus constructing a large graph) of entities (including additional attributes for those entities) and need to store them in a DB, and i think a graph database would fit this task perfectly.
Now, with sql-like DBs, i use sqlalchemyÅ› ORM to store my objects, especially because of the fact that i can retrieve objects from the db and work with them in a pythonic style (use their methods etc.).
Is there any object-mapping solution for Neo4j or other Graph-DB, so that i can store and retrieve python objects into and from the Graph-DB and work with them easily?
Or would you write some functions or adapters like in the python sqlite documentation (http://docs.python.org/library/sqlite3.html#letting-your-object-adapt-itself) to retrieve and store objects?
Shameless plug... there is also my own ORM which you may also want to checkout: https://github.com/robinedwards/neomodel
It's built on top of py2neo, using cypher and rest API calls under hood, i.e no dependency on gremlin.
There are a couple choices in Python out there right now, based on databases' REST interfaces.
As I mentioned in the link #Peter provided, we're working on neo4django, which updates the old Neo4j/Django integration. It's a good choice if you need complex queries and want an ORM that will manage node indexing as well- or if you're already using Django. It works very similarly to the native Django ORM. Find it on PyPi or GitHub.
There's also a more general solution called Bulbflow that is supposed to work with any graph database supported by Blueprints. I haven't used it, but from what I've seen it focuses on domain modeling - Bulbflow already has working relationship models, for example, which we're still working on- but doesn't much support complex querying (as we do with Django querysets + index use). It also lets you work a bit closer to the graph.
Maybe you could take a look on Bulbflow, that allows to create models in Django, Flask or Pyramid. However, it works over a REST client instead of the python-binding provided by Neo4j, so perhaps it's not as fast as the native binding is.