Apr 26, 2011
- make the CRUD more flexible then it is right now (using ZCA for view and subscribers registrations), increase test coverage and make it production ready
- add missing widgets and fix existing one
So if you want to taste classical Italian kitchen, visit UNESCO World Heritage Site and improve Pyramid - join us!
For more details check www.coactivate.org/projects/pyramid-crud-sprint
Apr 15, 2011
In my previous post I was trying to see what could be the benefit for Pylons Community to have a crud. We have a working prototype based on bfg. Now we would like to rewrite it for Pyramid. I've received interesting feedback, but the most promising was pyramid_formalchemy posted by Gael.
What I miss in pyramid_formalchemy
I will start with description of our use case. At the moment we are using our CRUD to handle most of the form generation and CRUD operations. We are using it in several projects, one of them with ca. 100 models. The part of the application that is exposed to anonymous user (like registration) or it's more complex (like wizard multip-step forms) we are handling with formish. For those 100 models we are using heavily ZCA for customizing View/List templates. As far I can see in the pyramid_formalchemy source code:
def formalchemy_admin(config, route_name, factory='pyramid_formalchemy.resources.Models', view='pyramid_formalchemy.views.ModelView', package=None, models=None, forms=None, session_factory=None): ... config.add_view(context='pyramid_formalchemy.resources.ModelListing', renderer='pyramid_formalchemy:templates/admin/listing.pt', attr='listing', request_method='GET', permission='view', **kw)
you can only pass one ModelView for config registration and practically you can't customize any of the templates per model.
What we would actually like to have is a ZCA registration, like:
<view for=".interfaces.IModel" view=".listing" renderer="templates/my_model_listing.pt" permission="list" />
ZCML is of course optional...
Other benefit of this approach is a possibility to register other non-crud views (not only list/add/view/edit/delete) only for specific model (can be helpful for some of the widgets implementation, i.e. autocomplete).
This is our main concern.
At the end we miss some widgets (which should be part of fa.jquery project and can be extended easily). One of the most interesting one is relation widget (with several variations), which right now is missing :-)
Apr 12, 2011
I have proposed a talk "How to build complex web applications having fun?" for this year's EuroPython.
This year, EuroPython is in Florence, Italy, which is ca. 140km from where I live now. It couldn't get easier to attend and propose a talk:
Web development is a complexity challenge nowadays. Growing number of functionalities results in customer expectations increase which makes project design more difficult. Using proper tools that suite your customer needs is essential.
In this talk I would like to present two successful stories using closely together Pyramid and Plone. Basing on these examples I wished to highlight the main reasons for using Plone as a CMS only and letting Pyramid do the rest (vertical application). Moreover, I will underscore good and bad practices during integration process and how to make farsighted architectural decisions in a right moment.
This year, everyone who has bought EuroPython ticket can vote. So If you have one and you'd like to see this talk, vote for it directly from abstract page.
Apr 06, 2011
I'm porting servlet code running on 6.5 Domino Server in XPages.
Servlet comunicate with Domino through DIIOP, and need DIIOP to istantiate Session object:
lotus.Domino.session = NotesFactory.createSession(server,login, password);
Thanks to Karsten Lehmann for its great library:
Now i can initialize a session using:
lotus.Domino.session = DominoAccess.getCurrentSession();
No more DIIOP needed!!