[Grok-dev] spotlight on: megrok.traject

[Ethan Jucovy]

Hey,

This is really cool -- both the spotlight and the package.  Thanks so
much for the writeup!

Reading this tonight, I started wondering how hard it would be to hook
up Django models to a Grok project.  It's a very appealing idea to me
because I like Django's model & template systems and its built-in web
interface for administering records, but I don't like writing my own
views in Django -- for custom application functionality I really
prefer Grok's structured interfaces-and-objects approach.

So I tried out a quick test, and I was really surprised (in a good
way!) at how easy it was -- everything literally Just Worked.
Basically:

1) Hook into the Django environment from the Grok environment as
described in e.g. [1]
2) Register a Traject that queries and returns the desired Model instance
3) Register some views against that Model as a context

I put my basic proof-of-concept app.py code in a pastebin in case
anybody wants to try this out: http://pastebin.ca/1753168 -- it makes
the following assumptions:

 * You have a Django project installed at /home/egj/django/greeb/
 ** with its settings.py file at /home/egj/django/greeb/settings.py
 ** and it's installed in a virtualenv at /home/egj/django (ie its
environment is independent from your grok project's environment)
 * Its SQL database is set up and synced -- don't need to know
anything more about it than that
 * Your Django project has an INSTALLED_APP ``myapp``
 ** myapp/models.py defines a model called Foo

I also tried writing a view to modify a Django record from Grok using
django's automatically generated form objects.  You can see that code
snippet here: http://pastebin.ca/1753186 -- again, it all Just Worked
really nicely.

And just by starting up a parallel Django process against the same
database and turning on its web admin interface, it's basically a free
loosely coupled CMS for my Grok app, or maybe a free app framework for
my CMS :)

I think there are a lot of really interesting possibilities here --
for example, I also want to start experimenting with generic views
registered against all django.db.models.Model subclasses, and try to
get them to interact somehow with Grok objects and interfaces.

But for right now I'm starting to get tangled in the details so I
should put this down for a bit.  I'd love to compare notes with anyone
else who's interested in this sort of thing though.

-Ethan

[1] http://www.cotellese.net/2007/09/27/running-external-scripts-against-django-models/

On Fri, Jan 15, 2010 at 8:30 AM, Martijn Faassen <faassen at startifact.com> wrote:
> Spotlight on...
>
> megrok.traject is a package that allows a different way to publish your
> models than the traversal that is most commonly used in Zope
> applications. With megrok.traject you can define explicitly what kind of
> URLs you want to publish your models on, instead of having to construct
> an object hierarchy.
>
> A model can be anything that you want to have views for, and doesn't
> need to be a persistent ``grok.Model``. In fact megrok.traject is most
> suitable for objects that are not stored in the ZODB, as the ZODB makes
> traversal easy.
>
> What kind of models could you publish with megrok.traject then? It
> could be just Python objects you design yourself. In this case you can
> use ``traject.Model``. You tell it under what URL pattern it should
> appear and how it is to be constructed, and you're done.
> ``traject.Model`` is very lightweight: it's just a ``grok.Context`` that
> can be hooked up by a "traject pattern".
>
> Alternatively you may want to treat your models even more lightly: you
> may wish to hook up models that are defined by a package that is not
> under your control at all. You could have for instance an ORM such as
> SQAlchemy define the models in an entirely different package that knows
> nothing about how these models should be presented on the web in your
> application. You can then use ``traject.Traject`` to associate such
> models with a URL pattern in your application.
>
> You can look at the megrok.traject documentation for more information:
>
> http://pypi.python.org/pypi/megrok.traject
>
> The low-level implementation is a reusable library called ``traject``,
> and its documentation can give you more details:
>
> http://pypi.python.org/pypi/traject
>
> If you still don't understand why megrok.traject would be useful for
> *you*, don't worry. Grok's traversal method of publishing objects isn't
> going anywhere, and megrok.traject is just an option. If you have
> questions, we'd very much like to hear them on grok-dev however, so that
> we can improve megrok.traject and its documentation.
>
> Volunteers who would want to write a tutorial oriented towards beginners
> that uses megrok.traject would also be very welcome!
>
>
> _______________________________________________
> Grok-dev mailing list
> Grok-dev at zope.org
> https://mail.zope.org/mailman/listinfo/grok-dev
>