[Grok-dev] Re: A Django-like admin in Grok

Robert Gravina robert at gravina.com
Thu Apr 24 22:28:16 EDT 2008

On 25/04/2008, at 7:32 AM, Martijn Faassen wrote:

> Hey,
> Robert Gravina wrote:
> [snip]
>>> How hard is it to use Django templating outside of Django? Is it a
>>> seperate library?
>> While I'm new to Django, it seems apparently, it can be done. If  
>> you look at the last section of this page it describes what you  
>> need to do to use it outside of Django:
> > http://www.djangoproject.com/documentation/templates_python/
> Cool. I wonder whether they package it up somewhere onto PyPI.
>>> If so, it wouldn't be too hard to integrate this
>>> into a Grok extension, as we have a pluggable templating language
>>> system. We could throw in this adaptation bit too. :)
>> :)... Django tempalates differ from ZPT in that they are not XML- 
>> based... so your output may not be valid, or even XHTML at all (can  
>> be used as a general text processor). Not sure how this effects  
>> Grok...
> No problem at all; Grok (and Zope 3) can work with text-based  
> processors just as well as XML based. In the end what comes out will  
> be strings, after all.
> [snip]
>>> I think having this would be great, as I've heard people say good
>>> things about the Django templating language. Having this would also
>>> make it easier for people familiar with Django to learn Grok.
>> Yes they have been easier to work with than XML-based templates in  
>> my experience... according to the Django people, designers have  
>> been able to use them effectively.
> Yeah, some people really prefer text-based templating. I lean  
> towards XML-based templating myself, but I'm pretty agnostic really  
> and I can see benefits to both approaches.
>> Well, it seems that I've missed my chance with Grok on this  
>> project, and was entirely my fault because I didn't check it out or  
>> consult here properly before diving into working on the site in  
>> Django..
> Actually I'm very glad you came here and talked about this, no  
> matter what stage of development were in! This kind of feedback is  
> what we need to get to see what things are important in Grok. It  
> already pleases me quite a bit people are even considering Grok in  
> the first place. :)
> Anyway, I think the general message is clear: create something that  
> helps people put up CRUD-style UIs in a hurry.
>> Django *does* have a nice admin, and application-level plugins,
> What are application-level plugins?

By that I mean reusuable applciations others have written and shared  
that are frequently used for websites - tagging, polls, blogs,  
threaded comments, etc. Pretty much analogous to Plone products.

There's a good list of them for Django here:

>> which I would happily trade for a unit-tested, interface-adapting  
>> framework but  didn't think I could replicate all that in the time  
>> we have :(.
> I'm quite sure it'd have been quite a struggle if you'd have gone  
> for Grok, actually. Not because it'd be particularly hard by itself,  
> but because our learning curve needs to be improved. Django's story  
> for learning it, at this point, is still better than Grok's. I  
> believe we're slowly catching up, though.

I think that Grok would be faster to pick up due to the component  
architecture - but I haven't developed anything serious in it yet :).  
I have spent a bit of time with Nevow, a Twisted-based web framework,  
which makes heavy use of zope.interface and components (they use  
twisted's component registry, but interfaces/adapters work in the same  
way). I find working with Nevow and basically any code that makes use  
of interfaces/adapters a joy - it doesn't guarantee good design and  
decoupled classes of course but it does encourage it. Basically, there  
are less surprises, things work as you expect, and it's easier to  
create solid, well tested code.

I'm considering using Grok over Nevow because it has security,  
workflow, skins/themes and viewlets. There is a Twisted-based  
application server, called Mantissa, which is built on Nevow which may  
provide more functionality than Nevow for writing web applications,  
which I'm also considering.

Actually as an aside, if you're interested to see how others have  
applied the Zope component architecture outside of Zope, have a look  
at what the Divmod guys have created. e.g. They have an ORM based on  
SQLite called Axiom, which has "persistent adapters" that you can  
attach to a persistent object to give it some more attributes and  
functionality... and query the database for these objects.. it's  
really quite cool. I'm quite impressed with their work:

> In addition, a system that already *has* a feature is just way ahead  
> of a system that doesn't have the feature yet. So if you're looking  
> for that feature or set of features, it makes a lot of sense to pick  
> the system that has it instead of developing it yourself. So, when  
> you're looking for, say, a CMS that is close to what, say, Plone  
> does, then you're probably better off using Plone than trying to  
> reproduce it all in Grok.

Actually the whole reason I am moving to Django and hopefully Grok or  
Nevow in the future is to get away from Plone! I work as a programmer  
for a design agency... the sites the designers come up with are often  
very unique and represent months of work, and I (and other Plone  
developers we have hired over the last two years) have found it  
extremely difficult to adapt Plone to our needs... It could just be  
that we don't understand Plone well enough, but I'm finding it  
incredibly difficult to get simple things done in Plone, mainly  
because of Zope 2. I know about Five, but unless Plone was rewritten  
as a Zope 3 application, I think a lot of this cruft will stay. I  
could be wrong here, and I'd love to hear what any Plone/Zope3 people  
have to say.

And we have been finding that what our clients really want from a CMS  
is the ability to maintain their content - CRUD basically - and most  
of the other Plone features in the admin get in the way for them. Most  
of them don't like the way content needs to be put in various folders  
either. One tried the Django admin out yesterday, and loves it,  
because they select the content type/object they want to edit (e.g. a  
news article) and they then can see all their news articles, search  
through them, edit the one they want etc. I can then display the news  
articles on various parts of the site in various ways based on object  
attributes or relationships rather than the folder they are located in.

I think this simple CRUD admin works well, and is enough of a CMS for  
your average content author. I would rather have a clean slate like  
Grok or Nevow with this built on top, rather than try and work with  
Plone to get it to work like this... If I'm misunderstanding Plone,  
please correct me!

> There are of course a lot of opportunities in building features that  
> *aren't* well supported by other systems yet. So by that route I'm  
> sure Grok will eventually build up enough of a feature-mass on top  
> of it to attract all sorts of developments.
>> Martjin's megrok:bread or Sebastions ProtonCMS could be a really  
>> good base to get Grok into the mainstream web development world...  
>> if frustrates me that Django is so popular despite it's (IMNSHO)  
>> very bad design. Python needs a well designed, flexible web  
>> framework with basic content management! I can see basically two  
>> frameworks that could actually do this if they have the content  
>> editing sorted - Grok, and Nevow... Nevow doesn't have workflow and  
>> a few other features ,but the Twisted guys sure know how to code  
>> too :)
> We're working on it. A bit of time.

I understand, and appreciate everyone's efforts.

>> I might have to pass on Grok for this project but I'd like to  
>> contribute in some way to this effort if I can...
> You already are contributing a lot! If you're interested in  
> contributing more I'd be quite interested in seeing a plugin that  
> uses Django's template language. We already have Genshi support  
> around as well, so having both would make the road to Grok from  
> TurboGears/Pylons and Django lot easier (and the other way around  
> too, but we don't mind. :)

Thanks! Has Kelvin points out in the following post in this thread,  
Jinja is probably a better option, because the Django templates are  
not cleanly separated from the rest of Django. From the snippet of  
template code on he Jinja site, they look (syntax-wise) just like  
Django templates.


More information about the Grok-dev mailing list