Showing posts with label Guide. Show all posts
Showing posts with label Guide. Show all posts

Saturday, March 22, 2014

Reg for ZCA addicts - Part 1: Adapter

Recently I have been exploring Reg, a library inspired by zope.component written by Faassen, and I found its simplification of ZCA to be pretty interesting. Being really loving ZCA for a while now, I end up trying to figure out how the ZCA patterns fits if I were to use Reg in my future projects. So here are the list of items I discovered so far:

Adapters
This is the most common pattern I use with ZCA, primarily to simplify writing logic by standardizing the interface of objects I work with into a common set of behavior/functions:

In ZCA , adapters are done this way:

from zope import interface
from zope import component

class IDog(interface.Interface):
    def bark():
        pass

class Dog(object):
    interface.implements(IDog)

    def bark(self):
        return 'Woof'

class IDuck(interface.Interface):
    def quack():
        pass

class Duck(object):
    interface.implements(IDuck)

    def quack(self):
        return 'Quack'

class IAnimalSoundAdapter(interface.Interface):
    def make_sound():
        pass

class DogSoundAdapter(grok.Adapter):
    interface.implements(IAnimalAdapter)
    interface.adapts(IDog) 

    def __init__(self, dog):
        self._dog = dog

    def make_sound(self):
        return self._dog.bark()

class DuckSoundAdapter(grok.Adapter):
    interface.implements(IAnimalSoundAdapter)
    interface.adapts(IDuck)

    def __init__(self, duck):
        self._duck = duck

    def make_sound(self):
        return self._duck.quack()

gsm = component.getGlobalSiteManager()
gsm.registerAdapter(DogSoundAdapter, (IDog,), IAnimalSoundAdapter)
gsm.registerAdapter(DuckSoundAdapter, (IDuck,), IAnimalSoundAdapter)

dog = Dog()
duck = Duck()

dog.bark() # Woof
duck.quack() # Quack

IAnimalSoundAdapter(dog).make_sound() # Woof
IAnimalSoundAdapter(duck).make_sound() # Quack

And that is quite a code, which utilizes classes, and large external interfaces libraries and component libraries which might can make many pythonistas cringe. 

In Reg, things are simplified. Similar functionality is done not through interfaces and complex object/class markers, but through simple functions. Reg adapter interfaces are simply functions:

import reg
import reg.implicit


class Dog(object):
    def bark(self):
        return 'Woof'

class Duck(object):
    def quack(self):
        return 'Quack'

@reg.generic
def make_sound(obj):
    raise NotImplementedError

def dog_sound(dog):
    return dog.bark()

def duck_sound(duck):
    return duck.quack()

registry = reg.Registry()
reg.implicit.initialize(registry)

registry.register(make_sound, [Dog], dog_sound)
registry.register(make_sound, [Duck], duck_sound)

dog = Dog()
duck = Duck()

make_sound(dog) # Woof
make_sound(duck) # Quack

Now, ZCA users might shout by now, "I want class based adapters!" (I know I did). This is how it can be implemented in Reg:

import reg
import reg.implicit

class Dog(object):
    def bark(self):
        return 'Woof'

class Duck(object):
    def quack(self):
        return 'Quack'

@reg.generic
def animal_sound_adapter(obj):
    raise NotImplementedError

class DogSoundAdapter(object):

    def __init__(self, dog):
        self._dog = dog

    def make_sound(self):
        return self._dog.bark()

class DuckSoundAdapter(object):

    def __init__(self, duck):
        self._duck = duck

    def make_sound(self):
        return self._duck.quack() 

registry = reg.Registry()
reg.implicit.initialize(registry)

registry.register(animal_sound_adapter, [Dog], DogSoundAdapter)
registry.register(animal_sound_adapter, [Duck], DuckSoundAdapter)

dog = Dog()
duck = Duck()

animal_sound_adapter(dog).make_sound() # Woof
animal_sound_adapter(duck).make_sound() # Quack

Thats it for now, next one I will probably share about multiadapters on Reg.

Tuesday, July 24, 2012

Plone on OpenShift quickstart using the DIY cartridge


TLDR; Plone is now deployable easily on openshift.redhat.com . Check out the repository here: https://github.com/kagesenshi/plone-openshift-quickstart.

Plone on openshift.redhat.com

Yesterday I posted about  deploying Plone using a cartridge in your own private OpenShift Origin VM.

Afterwards that day, I had some chat in the #openshift IRC channel and was informed that it is OK to run buildout in openshift.redhat.com, and last night, I converted the scripts and config from the cartridge so that it fits in the workflow of the DIY cartridge.

Features/Notes:
  • Deploys Plone 4.2 with Dexterity content types easily and quickly on openshift.redhat.com
  • Downloads are cached in ${OPENSHIFT_TMP_DIR}/${OPENDIR_APP_UUID}-cache. However, as this is not shared, it means all new apps will have to redownload the python eggs. While it might be possible to use a shared download cache for this  (OPENSHIFT_TMP_DIR is apparently /tmp), I am not sure whether the SELinux settings in the server allows it or not.
  • Virtualenv and generated eggs are stored in OPENSHIFT_DATA_DIR. Technically though, they are not exactly data. However, as we need them to be persistent, and the DIY cartridge does not provide a folder to store persistent, non-data, automatically generated files, they had to be stored there.
  • The quickstart template is quite generic for any buildout-based deployment. So, technically, you can add support for Grok, BlueBream and any framework that can be deployed using buildout using this template as its base. I'm planning to create a quickstart template for deploying Grok either tonight or later this week.  Will post about it.

Saturday, May 08, 2010

repoze.bfg - Introduction and bootstrapping it on buildout

2 months without a post here .. T_T ... must .. restart .. blogging ...

Anyway, I've been poking around with repoze.bfg since last week and growing to love it by the days. Been thinking to post a blog on getting started on it but was a bit lazy .. until I saw lowkster's post about bfg at planet.foss.org.my a few days ago.

Full documentation at http://docs.repoze.org/bfg

A little review

I love Zope Component Architecture because the modularity/reusability it offers, but Bluebream, Grok and Zope2 feels a bit big for simple web apps or for introducing ZCA to new people. Then I saw BFG.

BFG simplifies many concepts which I'm familiar with in Zope2/Zope3, and it does it without overwhelming developers with other parts of the framework. Not endorsing any type of storage backend, and giving an option between URL routing and traversal or a mix of both is a plus.

The initial base code is simple and straightforward, and there are no need to subclass any parent class when you want to create your initial project.

The starter project is as simple as:

models.py:
class MyModel(object):
pass

root = MyModel()

def get_root(request):
return root


views.py:
def my_view(request):
return {'project':'helloworld'}


A registration of the view in configure.zcml:
  <view
context=".models.MyModel"
view=".views.my_view"
renderer="templates/mytemplate.pt"
/>


And its template file which uses TAL compatible markup.

As the initial requirement is simple, and theres close to no enforcement on how developers supposed to write something on it, it made it easy for new people to quickly learn it and start being productive. BFG too, being something that uses many Zope concepts, can utilize many existing Zope/Z3C components out there, and if a developer know how to utilize ZCA well, what developed on a BFG project may also be componentized and reused in other frameworks.

What to know more on whats cool with BFG? .. read their Sales Pitch ;)

Installation on Buildout

Depending on your distribution, BFG might be available in your distro repository (Fedora have it). However, being a Zope/Plone developer as my main job, whenever it comes to installing python applications from pypi, I tend to prefer to use buildout to create a self-contained environment. So I'll use buildout here too.

First, if you don't have zc.buildout yet, install it using:
$ easy_install zc.buildout


Now lets create the contained environment
$ mkdir -p ~/repozebuildout/src
$ cd ~/repozebuildout


Then create a buildout.cfg file in the directory with this config:
[buildout]
parts =
repoze
develop =
src/*
versions = versions

[repoze]
recipe = zc.recipe.egg
eggs =
repoze.bfg
interpreter = python
entry-points = paster=paste.script.command:run

[versions]
repoze.bfg = 1.2.1



What the buildout config will do is, it will create a buildout with repoze.bfg framework and its dependencies installed, with an interpreter script configured for the buildout environment, and a paster script.

Now initialize the buildout
$ buildout init
$ ./bin/buildout -vv


After the buildout initialization is done, you may start creating the project skeleton.

Creating your first project

There are several templates to choose from: bfg_starter, bfg_routesalchemy, bfg_alchemy, and bfg_zodb.

bfg_starter template simply give a very basic bfg skeleton to get started. Those who are familiar with Pylons/Django might want to look at bfg_routesalchemy and those who are familiar with Zope might want to look at bfg_alchemy and bfg_zodb.

For this example, i'll just create a simple project using bfg_starter template.

cd src/
../bin/paster create -t bfg_starter helloworld
cd ..


then , edit buildout.cfg and add helloworld into the eggs section:

[buildout]
...
[repoze]
...
eggs =
...
helloworld
...


afterward, rerun buildout
./bin/buildout -vvv


Once that is done, you may start the server using:
./bin/paster serve src/helloworld/helloworld.ini


Now you can start developing on BFG!. Read the documentation to get you started in developing on BFG.

Happy hacking :D