[Feedback requested] Django Debug Toolbar: Removal of automatic setup

[Matthias Kestenholz]

Hi everyone,

I wanted to solicit some feedback on the removal of automatic setup before 
moving forward with it. There's a pull request[1] by Jon Dufresne which 
removes the feature, and if anyone feels strongly about it now would be the 
time to speak up. The documentation encourages users to use the explicit 
setup, and automatic setup is only kept for backwards compatibility[2] 
therefore this change shouldn't be too surprising, at least for those 
reading the documentation.

Thanks,
Matthias


[1]: https://github.com/jazzband/django-debug-toolbar/pull/851
[2]: 
http://django-debug-toolbar.readthedocs.io/en/stable/installation.html#automatic-setup


-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/9640168a-7b34-428f-9ee5-5a1d96c6b1f2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [feincms] [ANN]: FeinCMS v1.7

[Matthias Kestenholz]

On Wed, Feb 27, 2013 at 8:16 AM, Andi Albrecht <albrecht.a...@gmail.com>wrote:

> Hi Matthias,
>
> first of all thanks for the new release and all the work (this goes to
> all developers of course!).
>
> On Tue, Feb 26, 2013 at 10:00 PM, Matthias Kestenholz <m...@feinheit.ch>
> wrote:
> >
> >
> > Compatibility with Django and other apps
> > 
> >
> > FeinCMS 1.7 requires Django 1.4.
>
> Should that be read as requires at least Django 1.4? IOW is FeinCMS
> 1.7 tested with Django 1.5?
>
>
Yes, of course! I'll fix the docs to point that out. The release notes were
written when 1.5 wasn't released yet.

Thanks,
Matthias

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[ANN]: FeinCMS v1.7

[Matthias Kestenholz]

Hello everyone

This might seem like perfect timing, and nobody'll believe that it wasn't.

Anway, FeinCMS v1.7 has been released and is available at the usual places.
Thanks to everyone who supported this release with suggestions, prodding
and/or code.

Best,
Matthias

-- 8< --


=
FeinCMS 1.7 release notes
=

Welcome to FeinCMS 1.7!


Extensions-mechanism refactor
=

The extensions mechanism has been refactored to remove the need to make
models
know about their related model admin classes. The new module
:py:mod:`feincms.extensions` contains mixins and base classes - their
purpose
is as follows: :ref:`extensions`.


View code refactor
==

Made views, content type and request / response processors reusable.

The legacy views at :py:mod:`feincms.views.legacy` were considered unhelpful
and were removed.


Backwards-incompatible changes
==


Page manager methods behavior
-

Previously, the following page manager methods sometimes returned inactive
objects or did not raise the appropriate (and asked for)
:py:class:`~django.http.Http404` exception:

- ``Page.objects.page_for_path``
- ``Page.objects.best_match_for_path``
- ``Page.objects.for_request``

The reason for that was that only the page itself was tested for activity
in the manager method, and none of its ancestors. The check whether all
ancestors are active was only conducted later in a request processor. This
request processor was registered by default and was always run when
``Page.objects.for_request`` was called with ``setup=True``.

However, request processors do not belong into the model layer. The
necessity
of running code belonging to a request-response cycle to get the correct
answer
from a manager method was undesirable. This has been rectified, those
manager
methods check the ancestry directly. The now redundant request processor
``require_path_active_request_processor`` has been removed.


Reversing application content URLs
--

The support for monkey-patching applicationcontent-awareness into Django's
:py:func:`django.core.urlresolvers.reverse` has been removed.


Removal of deprecated features
--

* The old media library content type module
  :py:mod:`feincms.content.medialibrary.models` has been replaced with the
  contents of :py:mod:`feincms.content.medialibrary.v2`. The model field
  ``position`` has been renamed to ``type``, instead of ``POSITION_CHOICES``
  you should use ``TYPE_CHOICES`` now. The code has been simplified and
  hacks to imitate ``raw_id_fields`` have been replaced by working stock
  code. The ``v2`` module will stay around for another release and will be
  removed in FeinCMS v1.8. The now-unused template
  ``admin/content/mediafile/init.html`` has been deleted.


New deprecations


* ``Page.setup_request()`` does not do anything anymore and will be removed
  in FeinCMS v1.8.


Notable features and improvements
=

* A lazy version of
:py:func:`~feincms.content.application.models.app_reverse`
  is now available,
  :py:func:`~feincms.content.application.models.app_reverse_lazy`.

* Because of the extensions refactor mentioned above, all
  ``register_extension`` methods have been removed. Additionally, the model
  admin classes are not imported inside the ``models.py`` files anymore.

* The setting ``FEINCMS_USE_PAGE_ADMIN`` can be set to false to prevent
  registration of the page model with the administration. This is especially
  useful if you only want to reuse parts of the page module.

* Various classes in :py:mod:`feincms.module.page` do not hardcode the page
  class anymore; hooks are provided to use your own models instead. Please
  refer to the source for additional information.

* ``Page.redirect_to`` can also contain the primary key of a page now, which
  means that the redirect target stays correct even if the page URL changes.

* Before, page content was copied automatically when creating a translation
  of an existing page. This behavior can be deactivated by unchecking a
  checkbox now.

* Work has begun to make the page forms, model admin classes and managers
  work with an abstract page model so that it will be easier to work with
  several page models in a single Django site.


Bugfixes


* It should be possible to store FeinCMS models in a secondary database, as
  long as the base model and all content types are stored in the same
  database.

* Changing templates in the item editor where the templates do not share
  common regions does not result in orphaned content blocks anymore.

* :py:func:`feincms.utils.get_object` knows how to import modules, not only
  objects inside modules now.

* The order and priority values for pages have been fixed when generating
  sitemaps.

* Various ``save`` and ``delete`` methods now come with 

Re: Choosing a Django-based CMS

[Matthias Kestenholz]

Hi Sean

On Tue, Aug 7, 2012 at 5:52 AM, Sean O'Brian  wrote:
> Thanks all.
> As I get, I should try both Mezzazine and FeinCMS.
> May be they're have another advantages and disadvantages.
>

(Disclaimer: I'm one of the main developers of FeinCMS.)

The best place to ask questions about FeinCMS would be the
django-feincms mailing list. It's true that development isn't very
active this month (yet), a lot happened since the last release though.
You can see the breakdown here:

http://feincms-django-cms.readthedocs.org/en/next/releases/1.7.html

Development happens on the `next` branch in the github repository.
`master` normally does not get much activity since `master` tracks the
official maintenance branch (v1.6.x at the moment).


Thanks,
Matthias

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

[ANN]: FeinCMS v1.6.0

[Matthias Kestenholz]

Hello everyone

FeinCMS v1.6.0 has been released this noon and is available from
usual places.


What is FeinCMS anyway?
===

FeinCMS is one of the most advanced Content Management Systems built on top
of Django. FeinCMS not only includes a page module with many bundled content
types (plugins), a media library and up-to-date documentation but also the
tools to build your own CMS if our view of how a page CMS is supposed to
act like does not fit your requirements.

Website: http://www.feincms.org/

PyPI: http://pypi.python.org/pypi/FeinCMS/
Github: https://github.com/feincms/feincms/
Docs: http://feincms-django-cms.readthedocs.org/

Please report any issues you find in the issue tracker of github:
https://github.com/feincms/feincms/issues


This release would not have been possible without the contributions by the
community. Thanks for all the patches, bug reports and ideas which went into
this release.



=
FeinCMS 1.6 release notes
=

Welcome to FeinCMS 1.6!


Backwards-incompatible changes
==


Reversing application content URLs
--

The default value of ``FEINCMS_REVERSE_MONKEY_PATCH`` has been changed to
``False``. Support for monkey-patching the ``reverse()`` method to support
the old ``'urlconf/viewname'`` notation will be removed in the 1.7 release.


Improvements to the bundled file and image contents
---

* ``ImageContent``, ``FileContent`` and ``VideoContent`` now have pretty
  icons out-of-the-box.

* ``ImageContent`` now accepts optional ``FORMAT_CHOICES`` for use with
  FeinCMS' bundled thumbnailers, as well as ``caption`` and ``alt_text`` fields.

  .. note::

 If you are upgrading from an earlier version of FeinCMS, you'll have to
 add the new database columns yourself or use a migration tool like South
 to do it for you. Instructions for MySQL and the page module follow::

 ALTER TABLE page_page_imagecontent ADD COLUMN `alt_text`
varchar(255) NOT NULL;
 ALTER TABLE page_page_imagecontent ADD COLUMN `caption`
varchar(255) NOT NULL;

 If you want to use ``FORMAT_CHOICES``::

 ALTER TABLE page_page_imagecontent ADD COLUMN `format`
varchar(64) NOT NULL;

* ``FileContent`` now displays the size of the file in the default template,
  and uses ``span`` elements to allow styling of the title / size.


Removal of deprecated features
--

* Deprecated page manager methods have been removed. You should use
  ``Page.objects.for_request`` instead of the following manager methods:

  * ``Page.objects.page_for_path_or_404()``
  * ``Page.objects.for_request_or_404()``
  * ``Page.objects.best_match_for_request()``
  * ``Page.objects.from_request()``

* Deprecated page methods have been removed:

  * ``Page.active_children()``: Use ``Page.children.active()`` instead.
  * ``Page.active_children_in_navigation()``: Use
``Page.children.in_navigation()`` instead.
  * ``Page.get_siblings_and_self()``: You probably wanted
``self.parent.children.active()`` or
``self.get_siblings(include_self=True).active()`` anyway.

* The shortcuts ``Page.register_request_processors()`` and
  ``Page.register_response_processors()`` to register several request
or response
  processors at once have been removed in favor of their counterparts which
  only allow one processor at a time, but allow for replacing FeinCMS' included
  processors, ``require_path_active_request_processor`` and
  ``redirect_request_processor``.

* It is not possible anymore to access the request and response processors as
  methods of the ``Page`` class. The processors are all in
  ``feincms.module.page.processors`` now.

* The deprecated support for prefilled attributes has been removed. Use
  Django's own ``prefetch_related`` or ``feincms.utils.queryset_transform``
  instead.

* The deprecated ``feincms.views.base`` module has been removed. The code has
  been moved to ``feincms.views.legacy`` during the FeinCMS v1.5 cycle.


New deprecations


* The view decorator ``feincms.views.decorators.add_page_to_extra_context``
  has been deprecated as it was mostly used with function-based generic views,
  which have been deprecated in Django as well. Use Django's class-based generic
  views and the ``feincms.context_processors.add_page_if_missing`` context
  processor if you need similar functionality instead.

* The content type ``feincms.content.medialibrary.models.MediaFileContent`` has
  been deprecated since FeinCMS v1.4. The whole module has been deprecated now
  and will be replaced with the contents of ``feincms.content.medialibrary.v2``
  in FeinCMS v1.7. The ``v2`` module will stay around for another release or
  two so that code using ``v2`` will continue working with FeinCMS v1.8 (at
  least).

* The template tag ``feincms_navigation`` has been superseded by ``feincms_nav``
  which fixes 

[ANN]: Plata v1.1 (django-based shop no. 42)

[Matthias Kestenholz]

Hi fellow Djangonauts

I'm very proud to announce the release of Plata v1.1. Plata is the
BSD licensed Django-based shop by the makers of FeinCMS.
(It does not have any FeinCMS-dependencies though.)

Like many other shop projects such as django-shop, cartridge etc. it
grew out of the frustration of working with big shop frameworks which
strive to do everything with lost and lots of settings instead of
giving the programmer a tool with which it's easy to quickly build
a customized solution for customers (which is the primary reason
for working with Django, not with a turnkey CMS system).

Plata solves a few hard problems:

- Order management with multiple currencies, tax rates and discounts
- Payment (Payment modules for cash on delivery, paypal and ogone are
  bundled)
- Exact, transactional stock tracking for shops which sell goods which
  are often and/or quickly sold out

... but does not try to solve everything. Because of that it does not
come with a product model (which should differ for almost every
installation anyway to keep things simple for the webshop owner) and
keeps everything else mostly stupid but extensible.


Github: https://github.com/matthiask/plata/
RTD: http://readthedocs.org/docs/plata-django-shop/
PyPI: http://pypi.python.org/pypi/Plata/

Examples:
https://github.com/matthiask/plata/tree/master/examples
http://readthedocs.org/docs/plata-django-shop/en/latest/examples.html





===
Plata 1.1 release notes
===

Welcome to Plata 1.1!


Backwards-incompatible changes
==

Order status addition
-

The order status "confirmed" was confusingly named; what it really meant
all the time is that the order can be considered paid. Whether an order is
confirmed or not depends on the shop owner's definitions.

Because of this the existing ``Order.CONFIRMED`` status has been renamed
to ``Order.PAID``, ``Order.CONFIRMED`` has been added as a new order status
coming after ``Order.PAID``. Plata only knows about ``Order.PAID`` and never
changes an order to ``COMPLETED`` itself.

To update your installations to Plata v1.1, you'll have to make the following
changes:

* The method ``order.is_completed()`` has been removed. Either check for
  ``not order.balance_remaining`` (which only looks at the balance, not at the
  order status) or check for ``order.status >= order.PAID`` yourself. For
  consistency, the method ``order.is_confirmed()`` has been removed too.

* ``order.is_paid()`` has been deprecated and will be removed in the next
  release. Use ``order.status >= order.PAID`` or ``not order.balance_remaining``
  directly to clearly communicate your intentions instead.

* The shop signal ``order_completed`` has been renamed to ``order_paid``. Signal
  handlers receive the same arguments as before.

* The email template used in the ``SendInvoiceHandler`` has been renamed to
  ``order_paid.txt``.

* If you wrote your own payment modules, the method you'll want to call at the
  end is now named ``order_paid``, not ``order_completed`` anymore. Apart from
  the renaming the signature of the function has not changed.


Stock tracking
--

* The stock transaction app has been converted to south too now. The
  initial migration should be applied with ``--fake`` if you are already
  using stock tracking::

  ./manage.py migrate stock 0001 --fake

* Stock transactions have been made more useful on their own; if possible,
  the name, sku and line item price fields are filled in automatically.
  The south schemamigration for adding all additional fields is provided.

* Previously, stock transactions of type ``PAYMENT_PROCESS_RESERVATION``
  influenced the ``items_in_stock`` field on products even after the
  reservation period was over. This happened because the stock is not
  automatically recalculated when 15 minutes have passed. Plata is smarter
  now and only takes the payment process reservation stock transactions
  into account when validating the order (respectively the cart) during
  the checkout process. A few stock transaction manager methods have been
  removed during the refactoring because their functionality does not
  match Plata's own behavior anymore:

  * ``StockTransaction.objects.stock()``
  * ``StockTransaction.objects.expired()``
  * ``StockTransaction.objects._expired()`` (this method was meant for
internal use only anyway)

  If you need their functionality, you should have a closer look at
  ``StockTransaction.objects.items_in_stock`` first (especially the
  new argument, ``include_reservations``).


Language-aware orders
-

The order model has a new field ``language_code``. When the order is
created in ``shop.order_from_request(request, create=True)`` this field
is filled with the current language for your convenience. The PDF
generation code and the e-mail notification handlers automatically
activate the language set on the order; if you provide your own
signal 

Re: Query Set to search for a combination of model fields?

[Matthias Kestenholz]

On Fri, Mar 16, 2012 at 04:29, Shawn Milochik  wrote:
> Look at how the Q objects are being used in the example and it's clear why
> that is. It's using the pipe (|) to do an "or" query.
>
> If you want to change how the search works you'll have to add more code:
>
> 1. Split the search parameters on whitespace.
> 2. Create Q objects for searching in either or both fields for the values
> and use pipe (|) and ampersand (&) to "or" or "and" them as needed.
>

Maybe this code will help you forward:

https://github.com/matthiask/towel/blob/master/towel/managers.py

It supports grouping ("term1 term2"), inclusion ("term" or "+term")
and exclusion ("-term") too.


Matthias

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Seeking sample template code for iterating nested QuerySet

[Matthias Kestenholz]

On Fri, Mar 2, 2012 at 08:04, brycenesbitt  wrote:
> The documentation at:
> https://docs.djangoproject.com/en/1.3/topics/db/queries/
>
> Speaks of "Spanning multi-valued relationships", with an QuerySet
> returning all Entries (and their Blogs) where the Blog matches a
> pattern.
>
> What does the view code look like?
>
>
>
> When I do something similar:
>
> facets= models.Category.objects.
>    filter(facetquestion__facetanswer__subject='test').
>    select_related()
> {% for category in answers %}
>        {% for q in category.facetquestion_set.all %}
>            {% for a in q.facetanswer_set.all %}
>            {% endfor %}
>        {% endfor %}
> {% endfor %}
>
> Each '_set.all" returns the entire set, not just those entries that
> matched a pattern.
>
>
>
> Back to the django documentation: how would I write the view for the
> example given:
> Blog.objects.filter(entry__headline__contains='Lennon',entry__pub_date__year=2008)
> Where I want the view to print:
>
>   Blog1
>    Entry1 "Lennon On Ice"
>    Entry2 "Lennon In Love"
>  Blog4
>    Entry9 "Lennon is Killed"
>

You are mainly listing entries here, not blogs. Because of that it's
easier to write the code like this:

blogs = SortedDict()
for entry in Entry.objects.filter(headline__contains='Lennon',
...).select_related('blog'):
blogs.setdefault(entry.blog, []).append(entry)


Your example might be better written in a similar way too:


categories = SortedDict()
for answer in 
FacetAnswer.objects.filter(subject__icontains='test').select_related('question__category'):
category = categories.setdefault(answer.question.category, SortedDict())
category.setdefault(answer.question, []).append(answer)

I hope something like this gets you started.

Btw, the BIG advantage of the approach outlined above is that you only
need one SQL query to fetch all results you need instead of dozens.


Matthias

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

[ANN]: FeinCMS v1.5.0

[Matthias Kestenholz]

Hello everyone

FeinCMS v1.5.0 has been released this noon and is available from
usual places. The differences to v1.5.0.rc1 are very small, only
an update of the AUTHORS file and a few fixes to the thumbnail
template filters.



What is FeinCMS anyway?
===


FeinCMS is one of the most advanced Content Management Systems built on top
of Django. FeinCMS not only includes a page module with many bundled content
types (plugins), a media library and up-to-date documentation but also the
tools to build your own CMS if our view of how a page CMS is supposed to
act like does not fit your requirements.


PyPI: http://pypi.python.org/pypi/FeinCMS/
Github: https://github.com/feincms/feincms/
Docs: http://www.feinheit.ch/media/labs/feincms/

Please report any issues you find in the issue tracker of github:
https://github.com/feincms/feincms/issues


This release would not have been possible without the contributions by the
community. Thanks for all the patches, bug reports and ideas which went into
this release.




=
FeinCMS 1.5 release notes
=


Explicit reversing of URLs from ``ApplicationContent``-embedded apps


URLs from third party apps embedded via ``ApplicationContent`` have
been traditionally made reversable by an ugly monkey patch of
``django.core.urlresolvers.reverse``. This mechanism has been deprecated
and will be removed in future FeinCMS versions. To reverse an URL
of a blog entry, instead of this::

# deprecated
from django.core.urlresolvers import reverse
reverse('blog.urls/blog_detail', kwargs={'year': 2011, 'slug': 'some-slug'})

do this::

from feincms.content.application.models import app_reverse
app_reverse('blog_detail', 'blog.urls', kwargs={'year': 2011,
'slug': 'some-slug'})

If you do not want to use the monkey patching behavior anymore, set
``FEINCMS_REVERSE_MONKEY_PATCH = False`` in your settings file.

The new method is accessible inside a template too::

{% load applicationcontent_tags %}

{# You have to quote the view name and the URLconf as in Django's
future {% url %} tag. #}
{% app_reverse "blog_detail" "blog.urls" year=2011 slug='some-slug' %}


Inheritance 2.0
===

It's possible to use Django's template inheritance from third party
applications embedded through ``ApplicationContent`` too. To use this
facility, all you have to do is return a tuple consisting of the
template and the context. Instead of::

def my_view(request):
# ...
return render_to_response('template.html', {'object': ...})

simply use::

def my_view(request):
# ...
return 'template.html', {'object': ...}

.. note::

   ``template.html`` should extend a base template now.


Better support of ``InlineModelAdmin`` options for content types


The ``FeinCMSInline`` only differs from a stock StackedInline in
differing defaults of ``form``, ``extra`` and ``fk_name``. All inline
options should be supported now, especially ``raw_id_fields`` and
``fieldsets``.




Minor changes
=

* The main CMS view is now based on Django's class-based generic
  views. Inheritance 2.0 will not work with the old views. You don't
  have to do anything if you use ``feincms.urls`` (as is recommended).

* Request and response processors have been moved out of the
  ``Page`` class into their own module, ``feincms.module.page.processors``.
  They are still accessible for some time at the old place.

* ``django.contrib.staticfiles`` is now a mandatory dependency for
  the administration interface.

* The ``active`` and ``in_navigation`` booleans on the ``Page``
  class now default to ``True``.

* The minimum version requirements have changed. Django versions older than
  1.3 aren't supported anymore, django-mptt must be 0.4 upwards.

* The mptt tree rebuilders have been removed; django-mptt offers tree
  rebuilding functionality itself.

* ``django-queryset-transform`` has been imported under ``feincms.utils``
  and is used for speeding up various aspects of the media library. The
  prefilled attributes have been deprecated, because
  ``django-queryset-transform`` can be used to do everything they did,
  and better.

* ``PageManager.active_filters`` has been converted from a list to a
  ``SortedDict``. This means that replacing or removing individual
  filters has become much easier than before. If you only used the
  public methods for registering new filters you don't have to change
  anything.

* The same has been done with the request and response processors.

* The ``TemplateContent`` has been changed to use the ``filesystem`` and
  the ``app_directories`` template loaders directly. It can be used
  together with the cached template loader now.

* The tree editor has received a few usability fixes with (hopefully)
  more to come.

* 

Re: [ANN]: FeinCMS v1.5.0.rc1

[Matthias Kestenholz]

On Thu, Feb 16, 2012 at 07:52, Mark Renton  wrote:
> Great news! Happy to see the new version comes out ASAP. However, with the
> deprecate of old style patch of 3rd app URL reverse, is that means I must
> rewrite views and template codes of my app to fit this upgrade? And should I
> to do so if I wanna use others' app?
>

Yes, that's correct. It's recommended to set
"FEINCMS_REVERSE_MONKEY_PATCH = False" as soon as possible
(especially in new projects.)

Btw, if we want to upgrade several (old) FeinCMS sites we are runnning this
will cause a lot of pain for us too. On the other hand we finally have explicit
instead of fragile behavior, so I think the pain is still worth it
(besides being
a better citizen in the Django ecosystem, because now we do not rely on any
monkey-patching of Django proper anymore.)


Best regards
Matthias

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

[ANN]: FeinCMS v1.5.0.rc1

[Matthias Kestenholz]

Hello everyone

The first release candidate of FeinCMS v1.5 has just hit the streets,
late as always.

The release is available at the following places:

PyPI: http://pypi.python.org/pypi/FeinCMS
Github: https://github.com/feincms/feincms

Documentation:
http://readthedocs.org/docs/feincms-django-cms/en/next/

The release notes draft follows:


FeinCMS 1.5 release notes (upcoming)



Explicit reversing of URLs from ``ApplicationContent``-embedded apps


URLs from third party apps embedded via ``ApplicationContent`` have
been traditionally made reversable by an ugly monkey patch of
``django.core.urlresolvers.reverse``. This mechanism has been deprecated
and will be removed in future FeinCMS versions. To reverse an URL
of a blog entry, instead of this::

# deprecated
from django.core.urlresolvers import reverse
reverse('blog.urls/blog_detail', kwargs={'year': 2011, 'slug': 'some-slug'})

do this::

from feincms.content.application.models import app_reverse
app_reverse('blog_detail', 'blog.urls', kwargs={'year': 2011,
'slug': 'some-slug'})

If you do not want to use the monkey patching behavior anymore, set
``FEINCMS_REVERSE_MONKEY_PATCH = False`` in your settings file.

The new method is accessible inside a template too::

{% load applicationcontent_tags %}

{# You have to quote the view name and the URLconf as in Django's
future {% url %} tag. #}
{% app_reverse "blog_detail" "blog.urls" year=2011 slug='some-slug' %}


Inheritance 2.0
===

It's possible to use Django's template inheritance from third party
applications embedded through ``ApplicationContent`` too. To use this
facility, all you have to do is return a tuple consisting of the
template and the context. Instead of::

def my_view(request):
# ...
return render_to_response('template.html', {'object': ...})

simply use::

def my_view(request):
# ...
return 'template.html', {'object': ...}

.. note::

   ``template.html`` should extend a base template now.


Better support of ``InlineModelAdmin`` options for content types


The ``FeinCMSInline`` only differs from a stock StackedInline in
differing defaults of ``form``, ``extra`` and ``fk_name``. All inline
options should be supported now, especially ``raw_id_fields`` and
``fieldsets``.




Minor changes
=

* The main CMS view is now based on Django's class-based generic
  views. Inheritance 2.0 will not work with the old views. You don't
  have to do anything if you use ``feincms.urls`` (as is recommended).

* Request and response processors have been moved out of the
  ``Page`` class into their own module, ``feincms.module.page.processors``.
  They are still accessible for some time at the old place.

* ``django.contrib.staticfiles`` is now a mandatory dependency for
  the administration interface.

* The ``active`` and ``in_navigation`` booleans on the ``Page``
  class now default to ``True``.

* The minimum version requirements have changed. Django versions older than
  1.3 aren't supported anymore, django-mptt must be 0.4 upwards.

* The mptt tree rebuilders have been removed; django-mptt offers tree
  rebuilding functionality itself.

* ``django-queryset-transform`` has been imported under ``feincms.utils``
  and is used for speeding up various aspects of the media library. The
  prefilled attributes have been deprecated, because
  ``django-queryset-transform`` can be used to do everything they did,
  and better.

* ``PageManager.active_filters`` has been converted from a list to a
  ``SortedDict``. This means that replacing or removing individual
  filters has become much easier than before. If you only used the
  public methods for registering new filters you don't have to change
  anything.

* The same has been done with the request and response processors.

* The ``TemplateContent`` has been changed to use the ``filesystem`` and
  the ``app_directories`` template loaders directly. It can be used
  together with the cached template loader now.

* The tree editor has received a few usability fixes with (hopefully)
  more to come.

* ``Page.setup_request`` can be called repeatedly without harm now.
  The return value of the first call is cached and returned on
  subsequent calls which means that request processors are run
  at most once.

* Extensions such as ``translations`` and ``datepublisher`` which were
  only usable with the page module have been made more generic and are
  available for other FeinCMS-derived models too.

* Media files from the medialibrary can be exported and imported in
  bulk.

* When creating a new translation of a page, content is only copied
  from the original translation when the new page does not have any
  content yet. Furthermore the user is notified that some 

Re: Selecting an E-commerce Application

[Matthias Kestenholz]

On Mon, Jan 16, 2012 at 17:31, Lenz Hirsch  wrote:
> Servus,
>
> i would give plata a try because its from the creators of feincms wich
> is IMO the best django based CMS. As feincms is more a "cms framework"
> which ships with a very good "default implementation" i assume the
> same is true for plata. Plata is very new so maybe you are missing a
> lot of features. A "out of the box feature rich ready to go" solution
> is Kai´s LTFS. Maybe Kai can give us some insides if LTFS´s models
> (not product properties - that sure can be done very easily) are
> extendable in an easy way (no forking and under 10 lines of code) too.
>
> Depending on the requirements i would choose one of those two.
>

Thanks :-)

There is no stable release of Plata yet, but it is in use in several
shops right now, a few of them have been built by Feinheit, but I know
of two other companies which use it for their webshops.

The core hasn't changed much in months, and the basic ideas haven't
changed for even longer. I'd say even though there is no version 1.0
yet it is ready to build your shops on.

The current development version (https://github.com/matthiask/plata
branch master) comes without a product model -- the idea is that you
write your own because only you know which fields and which behavior
is needed. Models for contact information, discounts / vouchers,
carts, orders and payment tracking are included as are payment modules
for paypal, postfinance and cash-on-delivery. The checkout process is
fully managed by Plata, multi-currency shops are supported etc.

All of this means that yes, Plata isn't the best option if you want a
solution which works fine out of the box. If you anticipate you'll
have to customize the shop in several ways, choosing a lightweight
option with a small LOC count which solves the hard problems in a
reusable way (order tracking, payments, total calculation with taxes
and discounts), Plata might be the right choice for you.

Best regards
Matthias

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

[ANN]: FeinCMS 1.5.0.pre1

[Matthias Kestenholz]

Hello everyone

I'm finally starting the release process for FeinCMS v1.5 (sorry for
waiting so long).

The release is available at the following places:

PyPI: http://pypi.python.org/pypi/FeinCMS
Github: https://github.com/feincms/feincms

Documentation:
http://readthedocs.org/docs/feincms-django-cms/en/next/

The release notes draft follows:



FeinCMS 1.5 release notes (upcoming)



Explicit reversing of URLs from ``ApplicationContent``-embedded apps


URLs from third party apps embedded via ``ApplicationContent`` have
been traditionally made reversable by an ugly monkey patch of
``django.core.urlresolvers.reverse``. This mechanism has been deprecated
and will be removed in future FeinCMS versions. To reverse an URL
of a blog entry, instead of this::

# deprecated
from django.core.urlresolvers import reverse
reverse('blog.urls/blog_detail', kwargs={'year': 2011, 'slug': 'some-slug'})

do this::

from feincms.content.application.models import app_reverse
app_reverse('blog_detail', 'blog.urls', kwargs={'year': 2011,
'slug': 'some-slug'})

If you do not want to use the monkey patching behavior anymore, set
``FEINCMS_REVERSE_MONKEY_PATCH = False`` in your settings file.

The new method is accessible inside a template too::

{% load applicationcontent_tags %}

{# You have to quote the view name and the URLconf as in Django's
future {% url %} tag. #}
{% app_reverse "blog_detail" "blog.urls" year=2011 slug='some-slug' %}


Inheritance 2.0
===

It's possible to use Django's template inheritance from third party
applications embedded through ``ApplicationContent`` too. To use this
facility, all you have to do is return a tuple consisting of the
template and the context. Instead of::

def my_view(request):
# ...
return render_to_response('template.html', {'object': ...})

simply use::

def my_view(request):
# ...
return 'template.html', {'object': ...}

.. note::

   ``template.html`` should extend a base template now.


Better support of ``InlineModelAdmin`` options for content types


The ``FeinCMSInline`` only differs from a stock StackedInline in
differing defaults of ``form``, ``extra`` and ``fk_name``. All inline
options should be supported now, especially ``raw_id_fields`` and
``fieldsets``.




Minor changes
=

* The main CMS view is now based on Django's class-based generic
  views. Inheritance 2.0 will not work with the old views. You don't
  have to do anything if you use ``feincms.urls`` (as is recommended).

* Request and response processors have been moved out of the
  ``Page`` class into their own module, ``feincms.module.page.processors``.
  They are still accessible for some time at the old place.

* ``django.contrib.staticfiles`` is now a mandatory dependency for
  the administration interface.

* The ``active`` and ``in_navigation`` booleans on the ``Page``
  class now default to ``True``.

* The minimum version requirements have changed. Django versions older than
  1.3 aren't supported anymore, django-mptt must be 0.4 upwards.

* The mptt tree rebuilders have been removed; django-mptt offers tree
  rebuilding functionality itself.

* ``django-queryset-transform`` has been imported under ``feincms.utils``
  and is used for speeding up various aspects of the media library. The
  prefilled attributes have been deprecated, because
  ``django-queryset-transform`` can be used to do everything they did,
  and better.

* ``PageManager.active_filters`` has been converted from a list to a
  ``SortedDict``. This means that replacing or removing individual
  filters has become much easier than before. If you only used the
  public methods for registering new filters you don't have to change
  anything.

* The same has been done with the request and response processors.

* The ``TemplateContent`` has been changed to use the ``filesystem`` and
  the ``app_directories`` template loaders directly. It can be used
  together with the cached template loader now.

* The tree editor has received a few usability fixes with (hopefully)
  more to come.

* ``Page.setup_request`` can be called repeatedly without harm now.
  The return value of the first call is cached and returned on
  subsequent calls which means that request processors are run
  at most once.

* A few bugs have been fixed.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Django ORM - Am I trying to do the impossible?

[Matthias Kestenholz]

On Fri, Oct 21, 2011 at 9:20 AM, Paolo  wrote:
> An additional requirement for assignments is to keep status history, so we
> can see "assignment 1 was active mon-wed, standby thu-fri then active again"
> etc.
> As for the query, yes that was my initial idea but I thought it was going to
> be inefficient for times when I wanted to query for all assignments in a
> current status.  So essentially we have:
> 'Load all assignments into Django. Loop through each one doing a "select top
> record from assignment_update where assignment_id = this assignment", add it
> to a list of matched_assignments then pass back to the caller to display"
> Where what I'm trying to ask the database for is:
> "Group all assignment updates by assignment and select the one with the
> latest date and status X, giving me the assignment id from this record back
> so I can load it into a list of filtered assignments without looking at each
> one in turn".
> Does that make sense? Mountain out of molehill you think? Interesting
> anyway, right? ;)

I think you should store _all_ fields you need both on the Assignment
and the AssignmentUpdate. In AssignmentUpdate.save, you do something
like this:

def save(self, *args, **kwargs):
super(AssignmentUpdate, self).save(*args, **kwargs)
self.assignment.field1 = self.field1
self.assignment.field2 = self.field2
self.assignment.field3 = self.field3
self.assignment.save()


If you need the current values, you don't have to know anything about
the AssignmentUpdate table, and it's quite easy to write efficient
code for searching and showing all these values.

If you need the history, sort the AssignmentUpdate instances by their
creation time and compare all fields' values for differences, f.e.
like this: http://dpaste.com/hold/638491/

(Note: You have to create the first AssignmentUpdate when creating the
Assignment itself, otherwise you'll be unable to compare the first
update to the initial values of all Assignment's fields.)


Hope it helps,
Matthias



--
https://github.com/feincms/  Want to build your own CMS?

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: FieldError on ManyToMany after upgrading to Django 1.3

[Matthias Kestenholz]

On Mon, Sep 26, 2011 at 12:36 PM, Matthias Kestenholz <m...@spinlock.ch> wrote:
> On Mon, Sep 26, 2011 at 12:34 PM, Philip Mountifield
> <pmountifi...@formac.net> wrote:
>> I also have a great deal of dynamically generated models. Interestingly in
>> my case I find the issue when using the development server with DEBUG =
>> TRUE, I've not yet tried it in deployment.
>>
>> I'll take a look at your github, thanks for sharing the link.
>>
>> Out of interest, with respect to David's comment about postgres versions, do
>> you use version 8.1 or another?
>>

(Sorry for pressing send too early.)


We don't use postgresql at all (unfortunately, but that's a different
topic) on the site in question.


Matthias

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: FieldError on ManyToMany after upgrading to Django 1.3

[Matthias Kestenholz]

On Mon, Sep 26, 2011 at 12:34 PM, Philip Mountifield
 wrote:
> I also have a great deal of dynamically generated models. Interestingly in
> my case I find the issue when using the development server with DEBUG =
> TRUE, I've not yet tried it in deployment.
>
> I'll take a look at your github, thanks for sharing the link.
>
> Out of interest, with respect to David's comment about postgres versions, do
> you use version 8.1 or another?
>

We don't (unfortunately, but that's a different topic) on the site in question.


Matthias

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: FieldError on ManyToMany after upgrading to Django 1.3

[Matthias Kestenholz]

Hi Philip

On Fri, Sep 23, 2011 at 3:40 PM, Philip  wrote:
> FieldError: Cannot resolve keyword 'email_config_set' into field.
> Choices are: id, name, site, type
>
> Any ideas/solutions/pointers/tips would be most welcome.

Yes, I've seen similar problems in two sites I'm running. I suspect it
has to do with dynamically created models and startup timing effects
in our case. I'm not sure when it started and it's really hard to test
because it only happens in production (mod_wsgi / DEBUG=False) and I
don't have a consistent view of when the problem happens yet.

What we are doing in FeinCMS against it is trying to remove the caches
on Model._meta when new models are being created; this works for us,
but isn't all that nice. I'm running the following code in production
and will be waiting a few hours / days for the problem to manifest
itself again, hoping it wont:
https://github.com/matthiask/feincms/commit/f2de708a09f8b6cf4fdbca6b3583747b6ebbc2e2


Matthias

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

[ANN]: FeinCMS v1.4.1 final

[Matthias Kestenholz]

Hello everyone

I failed big time when creating the v1.4.0 release and created the
package from the wrong version...

Anyway, we're back on track now. v1.4.1 is available at the usual
places with the contents v1.4.0 should have had.

I'm sorry for any problems caused by this blunder.


Best regards
Matthias

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

[ANN]: FeinCMS v1.4.0 final

[Matthias Kestenholz]

Hello everyone

FeinCMS v1.4.0 has been released this morning and is available from
usual places. The differences to v1.4.0.rc1 are a small (cosmetic)
bugfix and documentation updates. Please note that the official
repository has been moved to the feincms organization on github and
does not live in my personal account anymore.

Development of 1.5 has started already. FeinCMS 1.4 will be the last
release supporting Django 1.2.




What is FeinCMS anyway?
===


FeinCMS is one of the most advanced Content Management Systems built on top
of Django. FeinCMS not only includes a page module with many bundled content
types (plugins), a media library and up-to-date documentation but also the
tools to build your own CMS if our view of how a page CMS is supposed to
act like does not fit your requirements.


PyPI: http://pypi.python.org/pypi/FeinCMS/
Github: https://github.com/feincms/feincms/
Docs: http://www.feinheit.ch/media/labs/feincms/

Please report any issues you find in the issue tracker of github:
https://github.com/feincms/feincms/issues


This release would not have been possible without the contributions by the
community. Thanks for all the patches, bug reports and ideas which went into
this release.




=
FeinCMS 1.4 release notes
=

* FeinCMS supports more than one site from the same database with
  ``django.contrib.sites`` now. Thanks to Bojan Mihelac and Stephen Tyler
  for the work and insistence on this issue.

* It is possible to customize the administration model inline used for
  content types. This means that it's possible to customize more aspects
  of content type editing and to reuse more behaviors from Django itself,
  such as ``raw_id_fields``.

* FeinCMS has gained support for ``django-reversion``.

* Reusing the media library in your own content types has become much
  easier than before. When using a
  ``feincms.module.medialibrary.fields.MediaFileForeignKey`` instead of
  the standard ``django.db.models.ForeignKey`` and adding the media file
  foreign key to ``raw_id_fields``, you get the standard Django behavior
  supplemented with a thumbnail if the media file is an image. This requires
  the next feature too, which is...

* Custom ``InlineModelAdmin`` classes may be used for the content types now
  by adding a ``feincms_item_editor_inline`` attribute to the content type
  specifying the inline class to be used.

* New projects should use ``feincms.content.medialibrary.v2.MediaFileContent``
  instead of ``feincms.content.medialibrary.models.MediaFileContent``. The
  argument ``POSITION_CHOICES`` and the corresponding field have been
  renamed to ``TYPE_CHOICES`` and ``type`` because that's a more fitting
  description of the intended use. The old and the new media file content
  should not be mixed; the hand-woven ``raw_id_fields`` support of the
  old media file content was not specific enough and interferes with
  Django's own ``raw_id_fields`` support.

* FeinCMS has gained a preview feature for pages which shouldn't be
  accessible to the general public yet. Just add the following line
  above the standard FeinCMS handler::

  url(r'', include('feincms.contrib.preview.urls')),

  Another button will be automatically added in the page item editor.


Apart from all these new features a few cleanups have been made:

* FeinCMS 1.2 removed the CKEditor-specific rich text content in favor of a
  generalized rich text content supporting different rich text editors.
  Unfortunately the documentation and the available settings only reflected
  this partially. This has been rectified. Support for ``TINYMCE_JS_URL``,
  ``FEINCMS_TINYMCE_INIT_TEMPLATE`` and ``FEINCMS_TINYMCE_INIT_CONTEXT`` has
  been completely removed. The two settings ``FEINCMS_RICHTEXT_INIT_CONTEXT``
  and ``FEINCMS_RICHTEXT_INIT_TEMPLATE`` should be used instead. See the
  :ref:`contenttypes` documentation for more details.

* The two settings ``FEINCMS_MEDIALIBRARY_ROOT`` and
  ``FEINCMS_MEDIALIBRARY_URL`` have been removed. Their values always
  defaulted to ``MEDIA_ROOT`` and ``MEDIA_URL``. The way they were used
  made it hard to support other storage backends in the media library.
  If you still need to customize the storage class used in the media
  library have a look at ``MediaFile.reconfigure``.

* Support for the ``show_on_top`` option for the ``ItemEditor`` has been
  completely removed. This functionatliy has been deprecated since 1.2.

* A few one-line Page manager methods which were too similar to each other
  have been deprecated. They will be removed in the next release of FeinCMS.
  This concerns ``page_for_path_or_404``, ``for_request_or_404``,
  ``best_match_for_request`` and ``from_request``. The improved
  ``for_request`` method should cover all bases.

* A few page methods have been deprecated. This concerns ``active_children``,
  ``active_children_in_navigation`` and ``get_siblings_and_self``. The useful
  bits are already 

[ANN]: FeinCMS v1.4.0.rc1

[Matthias Kestenholz]

Hello everyone

The first release candidate of FeinCMS v1.4 hit the streets yesterday
and is available at the usual places. Please note that the official
repository has been moved to the feincms organization on github and
does not live in my personal account anymore.

Development of 1.5 has started already. FeinCMS 1.4 will be the last
release supporting Django 1.2.




What is FeinCMS anyway?
===


FeinCMS is one of the most advanced Content Management Systems built on top
of Django. FeinCMS not only includes a page module with many bundled content
types (plugins), a media library and up-to-date documentation but also the
tools to build your own CMS if our view of how a page CMS is supposed to
act like does not fit your requirements.


PyPI: http://pypi.python.org/pypi/FeinCMS/
Github: https://github.com/feincms/feincms/
Docs: http://www.feinheit.ch/media/labs/feincms/

Please report any issues you find in the issue tracker of github:
https://github.com/feincms/feincms/issues


This release would not have been possible without the contributions by the
community. Thanks for all the patches, bug reports and ideas which went into
this release.





FeinCMS 1.4 release notes (upcoming)


* FeinCMS supports more than one site from the same database with
  ``django.contrib.sites`` now. Thanks to Bojan Mihelac and Stephen Tyler
  for the work and insistence on this issue.

* It is possible to customize the administration model inline used for
  content types. This means that it's possible to customize more aspects
  of content type editing and to reuse more behaviors from Django itself,
  such as ``raw_id_fields``.

* FeinCMS has gained support for ``django-reversion``.

* Reusing the media library in your own content types has become much
  easier than before. When using a
  ``feincms.module.medialibrary.fields.MediaFileForeignKey`` instead of
  the standard ``django.db.models.ForeignKey`` and adding the media file
  foreign key to ``raw_id_fields``, you get the standard Django behavior
  supplemented with a thumbnail if the media file is an image. This requires
  the next feature too, which is...

* Custom ``InlineModelAdmin`` classes may be used for the content types now
  by adding a ``feincms_item_editor_inline`` attribute to the content type
  specifying the inline class to be used.

* New projects should use ``feincms.content.medialibrary.v2.MediaFileContent``
  instead of ``feincms.content.medialibrary.models.MediaFileContent``. The
  argument ``POSITION_CHOICES`` and the corresponding field have been
  renamed to ``TYPE_CHOICES`` and ``type`` because that's a more fitting
  description of the intended use. The old and the new media file content
  should not be mixed; the hand-woven ``raw_id_fields`` support of the
  old media file content was not specific enough and interferes with
  Django's own ``raw_id_fields`` support.


Apart from all these new features a few cleanups have been made:

* FeinCMS 1.2 removed the CKEditor-specific rich text content in favor of a
  generalized rich text content supporting different rich text editors.
  Unfortunately the documentation and the available settings only reflected
  this partially. This has been rectified. Support for ``TINYMCE_JS_URL``,
  ``FEINCMS_TINYMCE_INIT_TEMPLATE`` and ``FEINCMS_TINYMCE_INIT_CONTEXT`` has
  been completely removed. The two settings ``FEINCMS_RICHTEXT_INIT_CONTEXT``
  and ``FEINCMS_RICHTEXT_INIT_TEMPLATE`` should be used instead. See the
  :ref:`contenttypes` documentation for more details.

* The two settings ``FEINCMS_MEDIALIBRARY_ROOT`` and
  ``FEINCMS_MEDIALIBRARY_URL`` have been removed. Their values always
  defaulted to ``MEDIA_ROOT`` and ``MEDIA_URL``. The way they were used
  made it hard to support other storage backends in the media library.
  If you still need to customize the storage class used in the media
  library have a look at ``MediaFile.reconfigure``.

* Support for the ``show_on_top`` option for the ``ItemEditor`` has been
  completely removed. This functionatliy has been deprecated since 1.2.

* A few one-line Page manager methods which were too similar to each other
  have been deprecated. They will be removed in the next release of FeinCMS.
  This concerns ``page_for_path_or_404``, ``for_request_or_404``,
  ``best_match_for_request`` and ``from_request``. The improved
  ``for_request`` method should cover all bases.

* A few page methods have been deprecated. This concerns ``active_children``,
  ``active_children_in_navigation`` and ``get_siblings_and_self``. The useful
  bits are already available through Django's own related managers.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this 

Re: Looking for recommendations for Custom Forms from Admin

[Matthias Kestenholz]

On Sat, Jun 25, 2011 at 3:00 PM, Venkatraman S  wrote:
> Hi,
>
> Was looking for possible django apps that help one build custom forms "on
> the fly" from the admin screens.
>

You might want to have a look at form_designer:

https://github.com/matthiask/form_designer

It contains a FeinCMS content type (form_designer.models.FormContent),
the rest of it isn't FeinCMS-specific. A FeinCMS installation isn't
needed either.

If you want to write a view yourself, the code should be structured
similarly to the render() method of FormContent.


Matthias

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Best django ecommerce aplication?

[Matthias Kestenholz]

On Thu, May 19, 2011 at 1:00 AM, podio  wrote:
> I was thinking to migrate my page to python, I choose Django and know
> need a shop aplication I was thinking in http://satchmoproject.com/.
>
> There some other else better?

I wouldn't use the term "Better". Maybe there are others more suitable
to what you want to do, but I cannot say for sure without further
information. We weren't too happy with Satchmo for what we wanted to
do and needed something a bit more flexible (and did not need half the
things Satchmo offers at all), so we wrote Plata.

In any case, have a look here for alternatives:

http://djangopackages.com/grids/g/ecommerce/


Matthias

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

FeinCMS 1.3.0 final has been released!

[Matthias Kestenholz]

Hello everyone

FeinCMS 1.3.0 has just been released and is available at the usual places.



What is FeinCMS anyway?
===


FeinCMS is one of the most advanced Content Management Systems built on top
of Django. FeinCMS not only includes a page module with many bundled content
types (plugins), a media library and up-to-date documentation but also the
tools to build your own CMS if our view of how a page CMS is supposed to
act like does not fit your requirements.


PyPI: http://pypi.python.org/pypi/FeinCMS/
Github: https://github.com/matthiask/feincms/
Docs: http://www.feinheit.ch/media/labs/feincms/

Please report any issues you find in the issue tracker of github:
https://github.com/matthiask/feincms/issues


Changes since the last announcement mail (1.3.0.rc1):

* The test runner has been converted to the class-based test runner API
* Several last-minute bugfixes



This release would not have been possible without the contributions by the
community. Thanks for all the patches, bug reports and ideas which went into
this release.




=
FeinCMS 1.3 release notes
=


FeinCMS 1.3 includes many bugfixes and cleanups and a number of new features.
The cleanups and features caused a few backwards incompatible changes. The
upgrade path is outlined below.

Highlights
==

* FeinCMS pages use the standard Django permalink mechanism inside the
  ``get_absolute_url`` implementation. This means that you have to update the
  URL definition if you did not include ``feincms.urls`` directly.

  Change this::

  url(r'^$|^(.*)/$', 'feincms.views.base.handler'),

  to this::

  url(r'', include('feincms.urls')),

  Defining the URL patterns directly is still possible. Have a look at
  ``feincms.urls`` to find out how this should be done.

* FeinCMS requires at least Django 1.2 but already has support for Django 1.3
  features such as staticfiles. The FeinCMS media file folder has been moved
  from ``feincms/media/feincms`` to ``feincms/static/feincms`` - if you use
  ``django.contrib.staticfiles`` with Django 1.3 (and you should!), FeinCMS'
  media files for the administration interface will automatically be made
  available without any further work on your part.

* Content types can specify the media files (Javascript and CSS files) they
  need to work correctly. See :ref:`contenttypes-extramedia` for information
  on how to use this in your own content types.

* The content type loading process has been streamlined and requires much
  less database queries than before. The performance hit on sites with deep
  page hierarchies, inheritance and many regions is several times smaller
  than before.

* The content type interface has been extended with two new methods, available
  for all content types which need it: ``process`` is called before rendering
  pages and is guaranteed to receive the current request instance. Each and
  every content type (not only application contents as before) has the
  ability to return full HTTP responses which are returned directly to the
  user. ``finalize`` is called after rendering and can be used to set
  HTTP headers and do other post-processing tasks. See
  :ref:`contenttypes-processfinalize` for more information.


(Backwards incompatible and other) Changes
==

* The default ``ContentProxy`` has been rewritten to load all content type
  instances on initialization. The instances stay around for the full
  request-response cycle which allows us to remove many quasi-global variables
  (variables attached to the ``request`` object). The new initialization is
  much more efficient in terms of SQL queries needed; the implementation is
  contained inside the ``ContentProxy`` class and not distributed all over
  the place.

* The ``ContactFormContent`` has been updated to take advantage of the
  new content type interface where content types can influence the
  request-response cycle in more ways.

* The ``ct_tracker`` extension has been rewritten to take advantage of the
  new ``ContentProxy`` features. This means that the format of ``_ct_inventory``
  could not be kept backwards compatible and has been changed. The inventory
  is versioned now, therefore upgrading should not require any action on
  your part.

* ``feincms_site`` is not available in the context anymore. It was undocumented,
  mostly unused and badly named anyway. If you still need this functionality you
  should use ``django.contrib.sites`` directly yourself.

* The ``_feincms_appcontent_parameters`` has been folded into the
  ``_feincms_extra_context`` attribute on the current request. The
  ``appcontent_parameters`` template tag is not necessary anymore
  (the content of ``_feincms_extra_context`` is guaranteed to be available in
  the template context) and has been removed.

  In your appcontent code, change all references of
``_feincms_appcontent_parameters``
  to ``_feincms_extra_context``, e.g.

[ANN]: FeinCMS 1.3 release candidate

[Matthias Kestenholz]

date(_ct_inventory=None)

* ``feincms_site`` is not available in the context anymore. It was undocumented,
  mostly unused and badly named anyway. If you still need this functionality you
  should use ``django.contrib.sites`` directly yourself.

* The ``_feincms_appcontent_parameters`` has been folded into the
  ``_feincms_extra_context`` attribute on the current request. The
  ``appcontent_parameters`` template tag is not necessary anymore
  (the content of ``_feincms_extra_context`` is guaranteed to be available in
  the template context) and has been removed.

  In your appcontent code, change all references of
``_feincms_appcontent_parameters``
  to ``_feincms_extra_context``, e.g.

  params = getattr(request, '_feincms_appcontent_parameters', {})

  becomes

  params = getattr(request, '_feincms_extra_context', {})

* As part of the effort to reduce variables attached to the request object
  (acting as a replacement for global variables), ``request.extra_path``
  has been removed. The same information can be accessed via
  ``request._feincms_extra_context['extra_path']``.

* The ``feincms.views.applicationcontent`` module has been removed. The
  special casing it provided for application content-using pages aren't
  necessary anymore.

* The page's ``get_absolute_url`` method uses URL reversion for determining the
  URL of pages instead of returning ``_cached_url``. This means that you need
  to modify your URLconf entries if you added them to your own ``urls.py``
  instead of including ``feincms.urls``. Please make sure that you have two
  named URL patterns, ``feincms_home`` and ``feincms_handler``::

  from feincms.views.base import handler

  urlpatterns = patterns('',
  # ... your patterns ...

  url(r'^$', handler, name='feincms_home'),
  url(r'^(.*)/$', handler, name='feincms_handler'),
  )

  If you want the old behavior back, all you need to do is add the following
  code to your ``settings.py``::

  ABSOLUTE_URL_OVERRIDES = {
  'page.page': lambda page: page._cached_url,
  }

* The copy/replace and preview mechanisms never worked quite right. They were
  completely dropped from this release. If you still need the ability to create
  copies of objects, use the standard Django ``ModelAdmin.save_as`` feature.



-- 
Matthias Kestenholz - Dipl. Umwelt-Natw. ETH - Konzept & Programmierung
FEINHEIT GmbH - Molkenstrasse 21 - CH-8004 Zürich - www.feinheit.ch

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Slow query. Any way to speed things up?

[Matthias Kestenholz]

On Tue, Mar 29, 2011 at 2:27 PM, Fabian Büchler
 wrote:
> I've analyzed the query using pgAdmin and it seems the most time is being
> spent with a the GroupAggregate.
> This is because of so many columns being listed in the GROUP BY clause.
> Creating two-column indexes over event_id and date or some other
> combinations I've tried did not gain any perforamance.
>
> Thus I've tried to get rid of some by just selecting some columns via
> "only(...)". Strangely this does not have any effect on the GROUP BY clause.
>

only() does not affect the generated query in any way -- it would be a
bug if it did.


> On the other hand, if I use "values(...)" the GROUP BY clause shrinks to
> only the named columns (but still being listed twice each).
>

There's already a ticket for the duplicated GROUP BY columns in the
Django ticket tracker:

http://code.djangoproject.com/ticket/15709


> The QuerySet.only() method not limiting the GROUP BY clause to the named
> columns seems like a "bug" (or inefficiency) in the ORM to me. Is that valid
> at any rate?
>

Not sure about that. I'd say it isn't a bug because this could
potentially cause different results depending on the table and table
content.


Matthias



-- 
Django CMS building toolkit: http://www.feinheit.ch/labs/feincms-django-cms/

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Is there any Open Source Django Newspaper CMS?

[Matthias Kestenholz]

On Wed, Mar 23, 2011 at 12:31 PM, Mika Sjöman  wrote:
> django-cms.org
>

That wasn't very helpful.

He could tell it himself, but you should really read the messages you
are replying to.

Quoting Rehmetjan:

> I am heard about Django is comes from a Newspaper group, but never found
> a Newspaper CMS. (Not meant Django-CMS)


Regards

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

[ANN]: FeinCMS 1.3 preview release

[Matthias Kestenholz]

Today is a good day for rolling another release. FeinCMS 1.3.0.pre1
was released today and is ready for testing and feedback. Please keep
in mind that this isn't a final release yet.

PyPI: http://pypi.python.org/pypi/FeinCMS/1.3.0.pre1
Github: https://github.com/matthiask/feincms/tree/v1.3.0.pre1
Docs: http://www.feinheit.ch/media/labs/feincms/

Please report any issues you find in the issue tracker of github:
https://github.com/matthiask/feincms/issues


Again, this release would not have been possible without the
contributions by the community. Thanks for all the patches, bug
reports and ideas which went into this release.




FeinCMS 1.3 release notes (upcoming)



FeinCMS 1.3 includes many bugfixes and cleanups and a number of new features.
The cleanups and features caused a few backwards incompatible changes. The
upgrade path is outlined below.

Highlights
==

* Content types can specify the media files (Javascript and CSS files) they
  need to work correctly. See :ref:`contenttypes-extramedia` for information
  on how to use this in your own content types.

* The content type loading process has been streamlined and requires much
  less database queries than before. The performance hit on sites with deep
  page hierarchies, inheritance and many regions is several times smaller
  than before.

* The content type interface has been extended with two new methods, available
  for all content types who need it: ``process`` is called before rendering
  pages and is guaranteed to receive the current request instance. Each and
  every content type (not only application contents as before) has the
  ability to return full HTTP responses which are returned directly to the
  user. ``finalize`` is called after rendering and can be used to set
  HTTP headers and do other post-processing tasks. See
  :ref:`contenttypes-processfinalize` for more information.


(Backwards incompatible and other) Changes
==

* The default ``ContentProxy`` has been rewritten to load all content type
  instances on initialization. The instances stay around for the full
  request-response cycle which allows us to remove many quasi-global variables
  (variables attached to the ``request`` object). The new initialization is
  much more efficient in terms of SQL queries needed; the implementation is
  contained inside the ``ContentProxy`` class and not distributed all over
  the place.

* The ``ContactFormContent`` has been updated to take advantage of the
  new content type interface where content types can influence the
  request-response cycle in more ways.

* The ``ct_tracker`` extension has been rewritten to take advantage of the
  new ``ContentProxy`` features. This means that the format of ``_ct_inventory``
  could not be kept backwards compatible. Because of this you have to empty
  the ``_ct_inventory`` fields yourself on upgrading::

  $ ./manage.py shell
  >>> from feincms.module.page.models import Page
  >>> Page.objects.all().update(_ct_inventory=None)

* ``feincms_site`` is not available in the context anymore. It was undocumented,
  mostly unused and badly named anyway. If you still need this functionality you
  should use ``django.contrib.sites`` directly yourself.

* The ``_feincms_appcontent_parameters`` has been folded into the
  ``_feincms_extra_context`` attribute on the current request. The
  ``appcontent_parameters`` template tag is not necessary anymore
  (the content of ``_feincms_extra_context`` is guaranteed to be available in
  the template context) and has been removed.

  In your appcontent code, change all references of
``_feincms_appcontent_parameters``
  to ``_feincms_extra_context``, e.g.

  params = getattr(request, '_feincms_appcontent_parameters', {})

  becomes

  params = getattr(request, '_feincms_extra_context', {})

* As part of the effort to reduce variables attached to the request object
  (acting as a replacement for global variables), ``request.extra_path``
  has been removed. The same information can be accessed via
  ``request._feincms_extra_context['extra_path']``.

* The ``feincms.views.applicationcontent`` module has been removed. The
  special casing it provided for application content-using pages aren't
  necessary anymore.

* The page's ``get_absolute_url`` method uses URL reversion for determining the
  URL of pages instead of returning ``_cached_url``. This means that you need
  to modify your URLconf entries if you added them to your own ``urls.py``
  instead of including ``feincms.urls``. Please make sure that you have two
  named URL patterns, ``feincms_home`` and ``feincms_handler``::

  from feincms.views.base import handler

  urlpatterns = patterns('',
  # ... your patterns ...

  url(r'^$', handler, name='feincms_home'),
  url(r'^(.*)/$', handler, name='feincms_handler'),
  )

  If you want the old 

Re: Problem with FileField (file upload) and generic views

[Matthias Kestenholz]

Hey Simon

On Thu, Mar 10, 2011 at 11:49 AM, Simon <simon.j.bu...@gmail.com> wrote:
> I'm writing an app to allow users in a school to upload newsletters to our
> website, but I'm having problems using models.FileField in a generic view.
> I've set
> MEDIA_ROOT = '/data/school/media/'
> and MEDIA_URL is also set to a valid location. I've checked and re-checked
> permissions on the directories: www-data (apache user) has full RWX
> permissions. The model:
> class Newsletter(models.Model):
>     issue_date        = models.DateField()
>     issue_number      = models.IntegerField()
>     table_of_contents = models.TextField(null=True, blank=True)
>     pdf_file          = models.FileField(upload_to='newsletters', null=True,
> blank=True)
> In urls.py:
>     # Create newsletter detail
>     (r'^new/$',
>         CreateView.as_view(
>             model=Newsletter,
>             template_name='newsletter/edit.html',
>         )),
> If I set the pdf_file field so that a file is required, it fails every time
> with the error "This field is required", even though a file has been
> selected. If I set it to "null=True, blank=True" (as above) it takes no
> notice of the file I have selected in the "pdf_file" upload field.
> I'm not sure if I've missed something obvious. Searching around turns up an
> old bug which gives the same problem but was fixed years ago.
> Any suggestions would be appreciated, TIA.

Which enctype do you use when submitting the form? It does not work
with the default POST enctype, you have to use the following:




Matthias



-- 
Matthias Kestenholz - Dipl. Umwelt-Natw. ETH - Konzept & Programmierung
FEINHEIT GmbH - Molkenstrasse 21 - CH-8004 Zürich - www.feinheit.ch

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: necessary of python

[Matthias Kestenholz]

On Sat, Feb 12, 2011 at 5:20 PM, pra <pdp2...@gmail.com> wrote:
> I just want to ask that whether learning python is necessary to
> develop applications in django.
> As I am totally novice user of it . Please be fast it's too urgent
>

Yes, it is necessary.

Many people learn Python at the same time as Django (it's not
necessary to know Python beforehand), but you still have to learn
Python if you want to be any good with Django.

There's no way around it.


Matthias




-- 
Matthias Kestenholz - Dipl. Umwelt-Natw. ETH - Konzept & Programmierung
FEINHEIT GmbH - Molkenstrasse 21 - CH-8004 Zürich
Django CMS building toolkit: http://www.feinheit.ch/labs/feincms-django-cms/

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: E-commerce site

[Matthias Kestenholz]

On Tue, Feb 8, 2011 at 2:53 PM, Arun K.Rajeevan <the1.a...@gmail.com> wrote:
> Hi all,
> I was a java programmer before I started to code in python.
> For the last 1yr I use python and loves it.

Great, a warm welcome to you!


> I'm new to django, but tried django tutorial and used web2py before for a
> few websites.
> Now, I had a bid for an e-commerce site.
> I don't want to go for magneto or the like, because I don't know PHP nor do
> I like to use that language.
> The one e-commerce solution I found and looks promising is Stachmo
>  http://www.satchmoproject.com/
> which is django based.
> How stable that project is? Or do you recommend the use of it?
> Is there any other python  based solutions?
> If I choose to go for stachmo, I'm most likely sure that I'll end up with
> lots of problems because I'm not that familiar with django, can I hope to
> get some good support from you guys (I heard a lot about django-users group
> is very supportive) so that I will not end up in bad customer reputations?
> !!

Satchmo is a mature (nearly) out-of-the-box shop solution which is
well suited to many shops. It has a history of being a bit hard to
install, but I hear that has changed in the last months. Its community
is helpful too.

Nevertheless, its sheer size might be a bit too much for a beginner,
and if you do not need everything Satchmo offers you might be happier
with a simpler app such as Plata:

http://readthedocs.org/docs/plata-django-shop/en/latest/index.html
https://github.com/matthiask/plata/

(Yay, promoting my own projects. I eat my own dogfood, though)


> I need:
> * an e-commerce site (not complex, we may have a max of 20 different
> products),
> * a forum with support, downloads/updates, product registration, Personal
> account page/shipping details/preferences/etc,
> * a blog

You'll find a lot of blog applications around. Some only allow posting
entries, others offer full trackback integration etc but lose a bit on
the reusable-app side.


> * social media integration

You might want to take a look at django-social-auth or
django-registration-facebook.


> Please suggest a starting point, and django applications that can be
> integrated to create this product in a rapid manner.
> Also, if you suggest the use of an ide, please mention which one. currently
> I'm happy with geany (a text editor + some more)

Whatever suits you. IDEs are a topic for religious wars, I won't give
advice here.


> Don't worry about the fact I'm new to django, I'm fast to adapt.
>


HTH
Matthias


-- 
Matthias Kestenholz - Dipl. Umwelt-Natw. ETH - Konzept & Programmierung
FEINHEIT GmbH - Molkenstrasse 21 - CH-8004 Zürich
Django CMS building toolkit: http://www.feinheit.ch/labs/feincms-django-cms/

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: What's the best way to develop an app that is similar the django admin?

[Matthias Kestenholz]

On Mon, Sep 20, 2010 at 3:13 PM, Federico Capoano
 wrote:
> Hi all,
>
> I try to explain it clearly.
>
> I have to develop an application that will implement similar
> functionality and look of the django admin, but in the frontend.
>
> So this application will have files management, clients management,
> and much more similar stuff, with add new, edit, delete, file upload
> and so on.
>
> Is there a way you would advice to do this?
>

There are a few implementations around which try to do something like
that. One of them is my django_modelviews project -- it's unreleased,
undocumented, but I use it on several sites in production. Short usage
instructions:

http://github.com/matthiask/modelviews/

1. Add django_modelviews to INSTALLED_APPS
2. Create a ModelView instance somewhere in your views.py, f.e. for
your Client model:

from yourapp.models import Client
from django_modelviews import generic
client_views = generic.ModelView(Client)

3. Create a URL entry:

from yourapp.views import client_views
urlpatterns = patterns('',
url(r'^clients/', include(client_views.urls)),
)



If the code does not work for you or does not fit your needs, maybe it
can still serve as an inspiration for your own project.




Matthias


-- 
Django CMS building toolkit: http://www.feinheit.ch/labs/feincms-django-cms/

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Filter based on result of model method

[Matthias Kestenholz]

On Sat, Jul 3, 2010 at 7:20 PM, Wiiboy  wrote:
> Is there a way to filter based on the result of a model instance
> method?
>
> I've got a Permission model with a one-to-one relationship with an
> Article.  The Permission model stores the different groups that the
> Article author said could read their article.  There's about 6 groups
> though, so I wrote an instance method that calculates whether a given
> user can view an Article.
>
> I want to filter based on whether that instance method returns true or
> not. I could do something like the following, but it seems very
> inefficient.
>

As other have already written, it's not possible to filter on the
result of a model method.

There's at least one thing you can do differently to speed up this method a bit.

> def myview(request):
>   q = Article.objects.all()
>   for item in q:
>       if not item.permission.can_view_article(request.user):
>           q = q.exclude(item.pk)
>

Everytime you call exclude (btw, this should be q =
q.exclude(pk=item.pk), no?), a new queryset instance is constructed.
This is probably not neccessary. You could do this instead, assuming
permission is another database model linked with a foreign key:

articles = [article for article in
Article.objects.all().select_related('permission') if
article.permission.can_view_article(request.user)]

At least you'll hit the article table only once this way.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: QuerySet Behaviour Question (Django 1.1)

[Matthias Kestenholz]

Hi

On Mon, Jun 28, 2010 at 4:37 PM, Jeff  wrote:
> Hi,
>
> I have a question concerning some queryset behaviour in Django 1.1.
>
> In this example, I have an article model that can contain 1 or more
> authors who are users registered through Django's auth system.
>
> I get the following output when playing around with an article in a
> shell where I have three authors:
>
 article.authors.all()
> [, , ]
 article.authors.all()[0]
> 
 article.authors.all()[1]
> 
 article.authors.all()[2]
> 
 article.authors.all()[0:1]
> []
 article.authors.all()[1:2]
> []
 article.authors.all()[2:3]
> []
>
> I'm curious why article.authors.all()[0] does not return 
> and instead returns . I'm also curious as to why  jeff> appears twice when slicing queries and it doesn't when
> requesting all results.
>
> Thank you in advance for your time!
>

Simple... User does not have a default ordering, therefore the
database is free to return the results in random order (the order may
even be different for subsequent queries as you have seen)

You should add an .order_by() clause if you need a stable ordering of
Users, f.e. User.objects.order_by('username')

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Open source CMS (if based on Django better)

[Matthias Kestenholz]

On Wed, May 5, 2010 at 9:52 PM, Jonatan.mv  wrote:
> What would be you recommended CMS?. Could you please give some reasons
> (pro and cons)?.
>
> I'm investigating on these:
>
> - PyLucid v0.8.x stable, v0.9 alpha
> - FeinCMS v1.1.0 stable
> - django-simplecms
> - django-cms-2.0 2.0.2 stable , 2.1 alpha
> - google-sites
>

Disclaimer: I'm the primary author of FeinCMS, so my view is obviously
biased. I won't give a recommendation and will let others speak up.
That being said, there's still some advice I'd like to give.

Some of these packages have different goals than other:

FeinCMS and Django-CMS are primarily page oriented CMS. Both have
plugins, which can be used to integrate other types of content than
only rich text / plain text content snippets.

On the other hand, simplecms and PyLucid offer more modules for
structured content (like articles, blog entries etc) and therefore do
more, but you might not need all functionality they offer. Using those
might give you a head start compared to Django-CMS or FeinCMS though,
but I'm not sure about that because I've never taken a deeper look at
them.

google-sites ... this is a list concerning Django, so google sites is
off-topic, and I'm not sure whether you can use google sites for your
own webpages at all, at least if you have requirements for styling,
functionality which do not align well with what google sites is
currently offering.

Btw, did you take a look at the following page on the Django wiki?

http://code.djangoproject.com/wiki/CMSAppsComparison



Thanks,
Matthias

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Multi-table inheritance, post_save and fixtures

[Matthias Kestenholz]

On Thu, Apr 8, 2010 at 1:04 PM, Phui Hock  wrote:
> Given the following block of code:
> --- models.py ---
> from django.db import models
> from django.db.models.signals import post_save
>
> class Animal(models.Model):
>    category = models.CharField(max_length=20)
>
> class Dog(Animal):
>    color = models.CharField(max_length=10)
>
> def echo_category(sender, **kwargs):
>    print "category: '%s'" % sender.category
>
> post_save.connect(echo_category, sender=Dog)
>
>
> and the following fixture:
> --- initial_data.json ---
> [
> {
>    "pk": 1,
>    "model": "animal.animal",
>    "fields": {
>        "category": "omnivore"
>    }
> },
> {
>    "pk": 1,
>    "model": "animal.dog",
>    "fields": {
>        "color": "brown"
>    }
> }
> ]
>
> Executing manage.py syncdb throws "AttributeError: type object 'Dog'
> has no attribute 'category'" from inside of echo_category callback.
> This is weird because I can access category from the Dog instance if
> it is an instance from a query, say Dog.objects.get(pk=1).
>
> How come the Dog instance received by echo_category is different
> compared to the Dog instance from a query? Can't I do post_save on a
> sub-model?
>

Please note that sender != instance. The Dog type object (=class) does
not have a category instance itself; a Dog instance however does have
one, since it is inherited from Animal.

You should change your signal handler to something like this:

def echo_category(sender, instance, **kwargs):
print u"category: %s" % instance.category






-- 
FeinCMS Django CMS building toolkit: http://spinlock.ch/pub/feincms/

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: django-paypal

[Matthias Kestenholz]

On Tue, Apr 6, 2010 at 8:12 PM, Ramdas S  wrote:
>
> Hey Thanks!
>
> Should I exempt all the views
>

I don't know django-paypal that well, but you should only exempt those
which are supposed to receive POST requests from external domains
(paypal) and which are secured against CSRF attacks in some other way,
f.e. with a hash or something.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: django-paypal

[Matthias Kestenholz]

On Tue, Apr 6, 2010 at 8:05 PM, Ramdas S  wrote:
> Hi,
>
> I am trying to use using django-paypal. Everything works fine, expect that
> the IPN doesn't reach the site.
>
> I followed the code a per instructions in the
> http://github.com/johnboxall/django-paypal
>
> I am able to send and receive money. But without IPN the goods which is
> primarily information sent over email cannot be delivered.
>
> Relevant portions of the code is included here.
>
> http://dpaste.com/180100/
>
> When I try testing the notify_url it was giving an error 403 forbidden  from
> sandbox.paypal.com. I am not sure what is the problem.
>
> Can someone advise?
>

Maybe the CSRF protection kicks in? django-paypal hasn't seen an
update in months, and I suspect that the CSRF middleware does not let
the IPN POST request from paypal through. Try decorating the paypal
IPN view with the @csrf_exempt decorator:

http://docs.djangoproject.com/en/dev/ref/contrib/csrf/#exceptions


Matthias






-- 
FeinCMS Django CMS building toolkit: http://spinlock.ch/pub/feincms/

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: 'template_key' that is missing from the form

[Matthias Kestenholz]

Hi Egon

On Sat, Apr 3, 2010 at 12:35 PM, Egon Frerich  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> [...]
>
> Exception Type: ImproperlyConfigured at /
> Exception Value: 'PageAdmin.fieldsets[1][1]['fields']' refers to field
> 'template_key' that is missing from the form.
>
>
> Any hints?
>


This is a known problem, please have a look at this issue and the
linked issues and threads:

http://github.com/matthiask/feincms/issues#issue/47

Especially this thread:


This problem has nothing to do with Django itself, it's a FeinCMS
issue and is therefore better discussed on the django-feincms list:

http://groups.google.com/group/django-feincms


Thanks
Matthias

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Website themes in django

[Matthias Kestenholz]

On Wed, Feb 3, 2010 at 7:46 AM, Waqqas Jabbar  wrote:
> Hi,
>
> I am thinking of making a "theme" application. The idea is to change the
> theme of the site easily from a list of available them (like in gmail).
> The theme selection can be based on
> - User (every user can choose her own theme)
> - Site (every site can have its own theme)
> - Browser specific
> - Random (new theme on every page:) )
>
> From my understanding, a theme is basically
> - Template file(s)
> - CSS file and images
>
> if the "rendering" function is passed a theme-name, it can fetch the
> corresponding template files. The choice of theme-name selection can be
> defined by the code.
>
> I want to get the feedback from the django gurus before I dive into this ...
>

I'd not include different template files in themes, just CSS and
images. If you create a polished HTML structure which lends itself to
themeing via CSS, you can create astonishing results without changing
the generated HTML code. If you need inspiration, take a look at CSS
Zen Garden: http://www.csszengarden.com/



Matthias

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Dealing with polyhierarchical data

[Matthias Kestenholz]

Hi

On Wed, Jan 27, 2010 at 11:29 PM, Olivier Guilyardi  wrote:
> Hi,
>
> I'm working with a polyhierarchical thesaurus, and trying to handle that in
> Django. By polyhierarchical, I mean : nodes can have both multiple parents and
> children.
>
> Actually, this is a geographical thesaurus, and yes a location can have 
> multiple
> parents (being across countries, etc..).
>
> I have read about the Nested set paradigm [1], and would love to use that, 
> maybe
> through django-mptt or django-treebeard. But unless someone shows me how, 
> nested
> sets aren't suitable for polyhierarchical data.
>
> Currently I have a simple recursive many-to-many mapping. This allows to
> establish the poly-relations, but is completely unusable for real use cases.
>
> For instance, I have a table of "items", with a "location" field which points 
> to
> a location in the thesaurus.
>
> Now I need to list all items which are located in a given country.
>
> I just can't filter by country, there's no such field in the items table. And 
> a
> location can be of any level of precision, such as country, region, city,
> village, etc..
>
> The nested set would be perfect for this, but apparently can't handle multiple
> parents.
>
> Do you see a fast and elegant way to handle this ?
>
> [1] http://dev.mysql.com/tech-resources/articles/hierarchical-data.html
>

Maybe you could take a look at this project?
http://bitbucket.org/cmutel/django-directed-acyclic-graph/


Matthias

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Saving several copies of an object

[Matthias Kestenholz]

2010/1/5 Tomasz Zieliński :
>
>
> On 5 Sty, 18:16, pjmorse  wrote:
>>
>> This is done by looping over the list of languages and saving a
>> NewsTrans in each language. The source language is marked as already
>> translated, the other two are not (that is, they still need
>> translating).
>>
>> The problem is that this is done with ns.save() (where ns is a
>> NewsTransForm with the submitted data), and what's actually happening
>> is that one NewsTrans is created, then it is updated twice, ending in
>> the third language.
>>
>> I thought I could fix this with ns.save(force_insert=True) but that
>> throws errors instead: "save() got an unexpected keyword argument
>> 'force_insert'".
>>
>
> Take a look at this:
>
> http://docs.djangoproject.com/en/1.0/ref/models/instances/#how-django-knows-to-update-vs-insert
>
> - after first ns.save() 'ns' receives primary key (id), which in turn
> causes any subsequent
> ns.save() to UPDATE previously created row. I'm not sure why
> 'force_insert' is an unexpected
> argument, but it doesn't make sense anyway to use it.
> You can try ns.id = None; ns.save() instead.
>

This won't do it, because ns is a Form, not a Model object. Something
like this might work though:

obj = ns.save(commit=False)

for language in languages:
obj.id = None
obj.language = language
obj.save()




Matthias
-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Creating dynamic models?

[Matthias Kestenholz]

On Thu, Nov 26, 2009 at 9:56 AM, Kevin Renskers  wrote:
> Just a small update: the DynamicModels way as described on the wiki
> doesn't work (it also says that it only works in Django 0.96, so
> yeah..).
>
> If anyone has any idea how to do this, I would be very thankful!
>
>
> On Nov 24, 2:35 pm, Kevin Renskers  wrote:
>> Hi all,
>>
>> In my Django project I want to have a model that is dynamically
>> created. I tried using the __init__ function for this,  something like
>> so:
>>
>> fields = ['field_a', 'field_b', 'field_c']
>>
>> class MyModel(models.Model):
>>     def __init__(self, *args, **kwargs):
>>         for field in fields:
>>             setattr(self, field, models.DecimalField(decimal_places=4,
>> max_digits=10))
>>
>> Sadly, this doesn't work. The columns don't get created when you run
>> the syncdb command, and even something like
>> MyModel._meta.get_all_field_names() doesn't return the dynamic fields.
>>
>> So, is there a way I can create a "dynamic" model? I did come 
>> acrosshttp://code.djangoproject.com/wiki/DynamicModelsbut I don't really
>> get that. It looks so much different then normal models, it seems like
>> I would loose a lot of functionality or would have to change a lot of
>> code somewhere else in my application?
>>
>> Hopefully there is an easy way to do this :)
>>

I can see two ways to achieve what you seem to want:

1. Add fields after the model has been created

This method uses an only unofficially documented feature[1] of
Django's model field classes.

class MyModel(models.Model):
# a few fields

for field in fields:
MyModel.add_to_class(field, models.DecimalField(decimal_places=4,
max_digits=10))



2. Construct a new type dynamically

class Meta:
verbose_name = _('my model')

attrs = {
'__module__': 'mymodule',
'Meta': Meta,
'method1': method1,
# ... more fields and methods
}

for field in fields:
attrs[field] = models.DecimalField(...)

MyModel = type('MyModel', (models.Model,), attrs)




Of course, the usual caveats apply. It might make your code harder to
read and understand, and harder to debug too, because it is not clear
what model fields exist by simply looking at the model code (that
applies especially to method 1)


Matthias

[1]: It's documented in Marty Alchin's excellent Pro Django book. I
think we can assume that this method won't go away without very good
reasons(tm).

--

You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Recursion without breaking MVC!

[Matthias Kestenholz]

Hey,

On Tue, Sep 29, 2009 at 12:50 AM, Nuno Machado  wrote:
>
> Hi djangoers,
>
> I've a simple category Model:
>
> class Category(models.Model):
>    name = models.CharField(max_length=63)
>    children = models.ManyToManyField('self', symmetrical=False,
> related_name='parent')
>
> I need to create a webpage to display all the categories with proper
> indentation, something like:
>
> Hobbies
>   Music
>      Piano
>      Flute
>   Cinema
>
> In order not to break the MVC/MTV pattern I want to create a list/
> dictionary with the category tree so I can iterate through it in the
> Template.
>
> Can you point me in the right direction on how to do it?
>

Have a look at django-mptt, and especially the tree_info template tag
for a much better way to do this:

http://code.google.com/p/django-mptt/



Matthias

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Custom form validation request or user-based

[Matthias Kestenholz]

On Wed, Sep 2, 2009 at 10:38 AM, Enrico
Sartorello wrote:
>> if you need this only for the administration site you'd hvae other
>> hooks that you could override. Either take a look at the documentation
>> or at django/contrib/admin/options.py
>>
>
> If you mean overriding the ModelAdmin.form object, that doesn't solve the
> problem as far as i can see, cause i can't provide arguments there (in that
> case, the user).

That's correct, but luckily there are more customization hooks available.

Matthias

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Custom form validation request or user-based

[Matthias Kestenholz]

On Wed, Sep 2, 2009 at 9:15 AM, Enrico
Sartorello wrote:
> Up.
>

Already?


> On Tue, Sep 1, 2009 at 11:06 AM, Enrico Sartorello
>  wrote:
>>
>> Wait a moment: this solution doesn't solve my problem.
>> Remember that the form I need has to be used on the admin site, so I can't
>> deal with it directly (in fact, I can't instantiate it and provide
>> additional arguments).
>>

if you need this only for the administration site you'd hvae other
hooks that you could override. Either take a look at the documentation
or at django/contrib/admin/options.py


Matthias

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Custom form validation request or user-based

[Matthias Kestenholz]

On Fri, Aug 28, 2009 at 10:34 AM, Enrico
Sartorello wrote:
> Hi,
> i'm developing a Django application where i need to differentiate the
> validation of an admin-site model form between different users: some user
> must respect some particular restrictions (imposed via "clean_*" methods)
> while others should do what they want without them.
>
> The problem arises because during form validation i cannot access any
> request object (so i can't build a permission-based criteria), and checking
> everything in other places (like Model_admin.save_model() method or with
> signals) can't do the job because there i can't raise form's validation
> errors.
>
> I've searched on the net but seems i cannot find any solution for that
> problem.
>
> Any hints?
>

Simple: Pass the current user to the form:

class MyForm(forms.ModelForm):
def __init__(self, *args, **kwargs):
self.saved_user = kwargs.pop('user')
super(MyForm, self).__init__(*args, **kwargs)

Somewhere else in the code:

form = MyForm(request.POST, user=request.user)

resp.

form = MyForm(user=request.user)



Of course that isn't the only possibility to achieve what you want,
but it's quite straightforward to do it like this.


Matthias


-- 
FeinCMS Django CMS building toolkit: http://spinlock.ch/pub/feincms/

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Django POST data errors

[Matthias Kestenholz]

On Mon, Aug 31, 2009 at 3:12 AM, Greg wrote:
>
> Hi all,
>
> I have a large-ish form (40-odd fields) on a pretty busy site, and I'm
> constantly getting "ManagementForm data is missing or has been
> tampered with" or "IOError: request data read error" errors. I can't
> reproduce it, and it always seems to be IE users (sigh)
>
> Does anyone have any ideas on what might be causing this? The form has
> one image upload field, otherwise it's just select boxes and text
> inputs.
>
> Thanks in advance,
>

I'm seeing this too, in a satchmo store administration interface. I've
no idea what causes this either except that it seems related to
Internet Explorer in some way (as you noticed too).

I'd be interested in a way to debug this too, or gather hopefully
helpful information about what's causing this.


Matthias



-- 
FeinCMS Django CMS building toolkit: http://spinlock.ch/pub/feincms/

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: need help: unique_together in both directions

[Matthias Kestenholz]

On Sat, Aug 29, 2009 at 7:51 PM,
ckar...@googlemail.com wrote:
>
> Really no ideas?
>
> Chris
>

Is there any way you could define a stable ordering for the
SinglePoint model? You could ensure that the "smaller" SinglePoint
gets stored in p1 and the "bigger" SinglePoint in p2 in a custom save
method.

If that isn't an option, you might want to implement a check in your
save method. I don't know how you could implement a database UNIQUE
index which would reject reversed relationships.


Matthias


-- 
FeinCMS Django CMS building toolkit: http://spinlock.ch/pub/feincms/

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Execute code after sending a http response?

[Matthias Kestenholz]

On Fri, Aug 28, 2009 at 8:10 AM, Shadow wrote:
>
> Hi,
>
> Is it possible to execute code after sending the actual http response?
>
> For my website, users can optionally give an email address, and if
> they do, the site sends a confirmation email. But I was thinking it's
> more logical to spend time sending the email after the signup
> confirmation page is sent to the user. Since sending the email doesn't
> affect the http reponse at all?
>
> Is this possible?
>

As Daniel said, you could use a queueing service or a database table
to store the fact that an email should be sent later.

Wouldn't you want to show the user an error message if sending the email failed?

Btw, the time needed to send an email is not so long normally. I think
the benefits (possibility of showing an error message, less
complexity) outweigh the downsides (a bit longer processing time)


Matthias


-- 
FeinCMS Django CMS building toolkit: http://spinlock.ch/pub/feincms/

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: redirect in django

[Matthias Kestenholz]

On Thu, Aug 27, 2009 at 12:38 PM, ankit rai wrote:
> Nobody knows the answer to this question i think so
>

Did you really expect an answer within an hour of sending the email to
the list? A little bit of patience would really be in order here.

If you need answers _fast_, IRC would be a better medium. There's no
guarentee you'll get help either way, though.


> On Thu, Aug 27, 2009 at 2:59 PM, ankit  wrote:
>>
>> I am new to django.I having to app in my admin.Know I want to know
>> that how can i redirect user to one app listpage if clicks save on
>> second app.say from app2 to app1
>>

You can do this by overriding the ModelAdmin response_change or
response_add method (or both, depending on your needs) you are
registering your model with.

Something like this:

class MyModelAdmin(admin.ModelAdmin):
def response_change(self, ...):
...

admin.site.register(MyModel, MyModelAdmin)


I've never seen the need to do such a thing up to now, but this code
snippet should be enough to get you started.



Matthias



-- 
FeinCMS Django CMS building toolkit: http://spinlock.ch/pub/feincms/

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Closures, Django Request Object, Django architecture

[Matthias Kestenholz]

On Tue, Aug 25, 2009 at 8:35 PM, Dennis Fogg wrote:
> PS: more succinctly: status notifications can happen in many places and
> passing the session to all these places just for the status notification
> does not make the code any clearer.  Thus, I just want to access the session
> as a global variable -- how can I do that?
>

Sending messages to an user is very much tied to the current request
-- only the current request can tell you which user is active
currently, so whatever way you choose to store and retrieve
notifications (database, sessions etc) you always need the request
object in one way or the other. Really, there is a reason why Django
does not provide global (or thread local) request / user objects. If
you still want do do it, google for "threadlocals user", but I'd
advise against doing that. In the end, it's your decision though.

Btw, I've used this thread locals hack in the past, and it served me
well for some time. It came back to bite me though, and I wish I
hadn't used it; it really makes writing a testsuite a pain; dumpdata
does not work because the manager of a single model depends on a
thread local request object with an authenticated user etc. It's much
better to cope with the need of having to pass the request around than
pick up the pieces afterwards when choosing the simple path now.


Matthias



-- 
FeinCMS Django CMS building toolkit: http://spinlock.ch/pub/feincms/

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Closures, Django Request Object, Django architecture

[Matthias Kestenholz]

On Tue, Aug 25, 2009 at 7:32 PM, Dennis wrote:
>
> I seem to need the Django HttpRequest object in functions that are
> called by view functions.
> I could pass the request, but I'm thinking of trying to create a
> closure in middleware so that
> I can access the request object (and maybe other objects) from
> anywhere.
> This seems like it's stretching the django architecture a bit -- not
> sure if I do this or if I should do this.
> I'm still new to python and django, so I thought I'd solicit advice
> first.
>
> I'm thinking that the django middleware will access the request object
> and create a closure.
> I think I can use a classmethod for the closure so I can access it
> from anywhere.
> This will create a new object for every request -- I'm assuming that
> it will not impact
> performance but I'm not sure.
>

What you are describing is not really different from storing the
request object in a thread local variable, which in turn does have the
same problems as storing a variable globally. It makes it non-obvious
what's going on, and the functions work differently depending on
external factors instead of depending only on the arguments you pass.

In other words, it is bad style, makes it harder to write tests and
generally makes the code non-obvious.

If you need the whole request object inside a function, pass it
explicitly. If you only need aspects of the request (f.e. the current
path), only pass in the current path. It seems like more work for now,
but will lead to cleaner, better and more maintainable code in the
future.

Remember, "Explicit is better than implicit."


Matthias



-- 
FeinCMS Django CMS building toolkit: http://spinlock.ch/pub/feincms/

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Documenting Django with sphinx: autodoc doesn't pick up field definitions

[Matthias Kestenholz]

On Tue, Aug 25, 2009 at 4:44 PM, Benjamin  Wohlwend wrote:
>
> Hi,
>
> I'm trying to generate documentation for my django project with sphinx
> [1] and autodoc[2]. It's mostly working, but I can't get sphinx to
> pick up my model field definitions (with the exception of related
> fields like m2m or ForeignKey). I asked in the IRC channel of sphinx
> (#pocoo on freenode), and they told me that it generally should work
> and that it's probably an issue with my configuration.
>
> My configuration is quite simple: I have all my apps and dependencies
> in a virtualenv and export DJANGO_SETTINGS_MODULE before running "make
> html" in the doc folder. Sphinx can import everything and doesn't
> throw any errors or warnings.
>
> So, did anybody here manage to get autodoc to recognize model fields?
> If yes, could you share how you set up your sphinx environment?
>
> Just to make sure I'm not doing something completely stupid (which,
> I'm told, does indeed happen from time to time), here's an example of
> my model
>
> http://dpaste.com/hold/85108/
>
> and my rst source:
>
> http://dpaste.com/85109/
>

It's quite easy to find out why this happens. The ForeignKey adds an
actual descriptor to the class, CharFields however do not add
top-level attributes to the class itself.

Sphinx does not that it should look into Page._meta.fields to find all
defined fields and therefore does not find most Django fields, only
the fields adding descriptors.

You might want to find out how to modify sphinx / add a new sphinx
extension which knows how Django models should be handled.


IPython session transscript:

In [1]: from feincms.module.page.models import Page

In [2]: Page.parent
Out[2]: 

In [3]: Page._cached_url
---
AttributeErrorTraceback (most recent call last)

/home/mk/tmp/feincms/example/ in ()

AttributeError: type object 'Page' has no attribute '_cached_url'




Matthias

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Image Location

[Matthias Kestenholz]

On Sun, Aug 23, 2009 at 3:54 PM, When ideas
fail wrote:
>
> Hello, i'm having a problem getting images to display so I was
> wondering if someone would be kind enough to help?
>
> I have my settings.py set up as follows (content is the folder where
> my static images are stored):
>
> MEDIA_ROOT = '/home/mysite/content/'
> MEDIA_URL = 'http://www.mysites.net/content/'
>
> Then my template is like so:
>
> 
>
> where object.post_img = imgs/newMessage.jpg
>
> but if i load the page up it doesn't appear. I checked the error log
> it says:
>
> File does not exist: /home/mysite/public_html/content, referer:
> http://www.mysite.net
>
> so it has added public_html to the path, how can i solve this issue?
>

By using the documented way to output the URL of a FileField / ImageField:



Look here for more information:
http://docs.djangoproject.com/en/dev/ref/models/fields/#filefield



Matthias

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: From a relative noob

[Matthias Kestenholz]

Robb,

On Sat, Aug 22, 2009 at 6:06 PM, Robb Bossley wrote:
> In the course of writing this program, I have run into a challenge with
> regard to the way that things are retrieved and displayed.  The problem is
> as follows:
>
> #"var3" is passed in from the following
> def Someprog(request, var1, var2, var3)
>  #My first attempt to handle this
>  var3 = int(var3)
>  var4 = var3 - 6   #Subtract six from the value passed in to compare to
> another value
>  #The issue deals with "var4" in this line
>  Some.object.filter(id = var1).filter(value =
> var2).extra(where=['Cost>%s'], params=['var4'])
>
> I am getting an error from Microsoft SQL server because it doesn't like the
> variable being passed - it complains about having to convert this variable
> and it cannot (or doesn't want to)
>
> Any thoughts of another way to pass this integer or make this work?

Is there a reason why you cannot simply do the following?

Some.object.filter(id = var1).filter(value = var2).filter(Cost__gt=var4)




HTH
Matthias



-- 
FeinCMS Django CMS building toolkit: http://spinlock.ch/pub/feincms/

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Dynamically add a line to an inlineformset

[Matthias Kestenholz]

On Sat, Aug 22, 2009 at 7:53 AM, Andew Gee wrote:
>
> Thank you for your help.
>
> I have managed to get the inlineforms to reproduce on my page, however
> when I submit the form the extra inlines are ignored. I have printed
> the formset when it hits the view and the new lines that I have added
> have no values in them, the values that I enter in are not being
> passed back by the request. Is this something that someone has seen
> before?
>

Yes, I've seen. It either means you are not correctly incrementing
TOTAL-FORMS (and therefore the formset code won't look at the added
parameters) or -- less probable -- you are not altering the name and
id attributes when creating new form rows. The second point is less
probable because you said that you can see the new fields on the
server side, even though you only see them as empty.

Another thing to check would be whether the said input fields exist
twice inside your form, and the later overwrite the former when the
browser is collecting the form fields' values.


Matthias

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: How to run a static html page as a section of django website?

[Matthias Kestenholz]

On Thu, Aug 20, 2009 at 10:42 PM, Bins wrote:
>
> I've a django powered blog, say http://example.com. I desire to make a
> section http://example.com/htmlpage/ and run a simple static html page
> at the url.
>
> How to I do it?
>
> I tried putting my file folder into my /django/website on webserver
> but no gain.
>
> I admit I know no more than 5-10% of django. Can some hint me what to
> do?

Follow the instructions here for your (local) development setup:

http://docs.djangoproject.com/en/dev/howto/static-files/


You should not use this method for serving static files on the
production server; take a look at the server software documentation to
find out how to do it there. (The method used on the production server
is the same as if you were not using Django at all.) It's hard to give
tipps when knowing nothing about the server environment you use in
production.


Matthias

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: how to return an html snippet using ajax $.post()?

[Matthias Kestenholz]

On Thu, Aug 20, 2009 at 11:53 PM, Margie wrote:
>
> Ah - thank you!  Yes, sorry, in the process of my debugging the issue
> and trying to simplify it, I unintentionally introduced even more
> errors, and then when posting it, even more!  But you somehow despite
> that, managed to identify my real error, which was that I hadn't put
> the single quotes around {% get_my_url %}.
>
> I was clearly doing a spiral downward - thanks very much for your
> save!
>

No problem! I don't know if you know about it, but if you are doing
lots of ajax with forms, you should take a look at the jquery form
plugin[1]; I use it (nearly) all the time. (No disclaimer, it's not my
project and I'm not affiliated with it in any way.)


Matthias

[1]: http://malsup.com/jquery/form/

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: how to return an html snippet using ajax $.post()?

[Matthias Kestenholz]

On Thu, Aug 20, 2009 at 11:34 PM, Margie
Roginski wrote:
>
> Could someone give me a hand with a very simple ajax problem?  I want
> to post some data and have the server just return a small snippet of
> html, which I then want to insert into my dom at a particular id.
>
> Let's say the html snippet to be returned is just a string: hello
> world.
>
> Does my views.py function just return it like this?
>
>    return HttpResponse("hello world")
>
> I have some jquery on client side that is just trying trying to have
> the callback function throw the returned snippet up in an alert box,
> like this:
>
>            
>
> I find that I never hit my callback function (the alert(data)).
> Instead the browser just replaces my with a page containing
>
> hello
>
> Could someone give me a pointer as to what I'm doing wrong?
>

I'd say you get a javascript error in your onclick handler, this does
not look like a server error at all. You should probably add quotes
around the {% get_my_url %} stuff; or does this template tag add the
quotes itself?

After reading the snippet for a second time, I've got to say it looks
quite messed up. This won't work. Try something like that:

 

(Parentheses in $.post removed, # added in $('#id_comment'), added
quotes around {% get_my_url %} )


Matthias


-- 
FeinCMS Django CMS building toolkit: http://spinlock.ch/pub/feincms/

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Dynamically add a line to an inlineformset

[Matthias Kestenholz]

On Thu, Aug 20, 2009 at 7:27 AM, Andew Gee wrote:
>
> Does anyone know how to add a new line to anlineformset dynamically? I
> have a page that contains an inlineformset and I need to be able to
> click a button and add a new line which will then be saved when the
> form is submitted, is that possible?

Sure it is. Clone the HTML of the last line (or any empty line),
modifiy the id and name attributes (increment the counters by one) and
increment the TOTAL-FORMS hidden input field. There is no builtin
support for doing that in Django, because it is javascript framework
agnostic, but it's quite easy to do it anyway.

Maybe you find some inspiration how to do it in the admin-ui GSoC
branch? There, jQuery is used to provide exactly what you want.

Matthias


-- 
FeinCMS Django CMS building toolkit: http://spinlock.ch/pub/feincms/

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Template Filters

[Matthias Kestenholz]

On Thu, Aug 20, 2009 at 4:11 AM, WilsonOfCanada wrote:
>
> Hellos,
>
> I was wondering if there is a filter that can remove these '\' that
> python added when strings are appended to a list or dictionary.  I
> cannot use cut because I still need one of the '\'
>
> ex.  C:\\moo
>
> Code:
>
> arrPlaces = []
> intPoint =0
>
> while (len(testline)):
>        testline = fileName.readline()
>        print testline
>        arrPlaces[intPoint].append(testline)
>        intPoint += 1
>
> d["places"] = arrPlaces
> return render_to_response('rentSearch.html', d)
>
>> C:\moo
>> C:\supermoo
>
> the HTML using Django has:
>
> {{ places|safe }} but returns ['C:\\moo', 'C:\\supermoo'].  I was
> wondering of there is a filter for the template that would return ['C:
> \moo', 'C:\supermoo'] instead.
>

Indeed there is. It's not a filter but the correct way to do it:

[{% for place in places %}'{{ place }}'{% if not forloop.last %}, {%
endif %}{% endfor %}]

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Raw Strings with Variables

[Matthias Kestenholz]

On Wed, Aug 19, 2009 at 2:51 AM, WilsonOfCanada wrote:
>
> However, when I send the list over as a dictionary for HTML:
>
> d["places"] = arrPlaces
>
> return render_to_response('rentSearch.html', d)
>
> the HTML using Django has:
>
> {{ places }} but returns ['C:\\moo', 'C:\\supermoo']
>

And what's unexpected about that exactly?

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Admin dashboard : hide and merge modules

[Matthias Kestenholz]

On Tue, Aug 18, 2009 at 6:10 AM, JF Simon wrote:
>
> Hi men,
>
> I'm using Django + Grappelli and I'd like to know if there is a simple

I don't know about grappelli, but I'd expect it to be at least as
configurable as the standard django admin interface.


> way to make some improvements to the dashboard (index) of the admin
> such as :
>
> - hide modules (like Django_Evolution)

You can create a user and assign them permissions only for certain
apps/models. Just don't give them superuser permissions. The apps
where users do not have any permissions will be hidden.

> - merge modules (Auth entries with my User module)
> - rename existing modules (not for now, just to know)

I think these aren't possible currently.


Matthias




-- 
FeinCMS Django CMS building toolkit: http://spinlock.ch/pub/feincms/

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Master / Slave Database Replication Scenario

[Matthias Kestenholz]

On Sun, Aug 16, 2009 at 11:44 AM, Haes wrote:
>
> Hi,
>
> we are using master / slave database replication, no partitioning,
> just replicating the complete database to several slaves for
> performance reasons. This is making some problems with a newly
> developed Django project, which makes use of an existing database.
>
> Is there an (easy) way to use a different database for the admin
> application (master db) than for the remaining apps (slave db)?
>
> If I'd need more fine grained control about what database connection
> I'd like to use in a view, would I need to write a custom db backend
> for that? Or is there a way to set up two database connections and
> switch them manually (django.db.connection = )?
>

Take a look at django-multidb on github[1]. Django's own Multi-DB-API,
which is being developed by Alex Gaynor as part of the Google Summer
of Code is not ready yet, but seems to come along nicely.


[1]: http://github.com/mmalone/django-multidb/tree/master




-- 
FeinCMS Django CMS building toolkit: http://spinlock.ch/pub/feincms/

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Django, CMS, CSS newbie question

[Matthias Kestenholz]

On Thu, Aug 13, 2009 at 11:55 PM, eldonp2 wrote:
>
> Thanks.
>
> I've gone through the book and done the tutorial on djangoproject.com
>
> Basically, my qyestion is still not answered - how do I start with a
> CSS template and bring Django and Django-CMS in afterward? The problem
> is with learning Python, HTML and Django, it will take a long time
> before I get to know CSS.
>

Trying  to start with Django-CMS (or any comparable software package
for that matter) before you know how to work with CSS files inside
Django is akin to trying to run before you can walk. You'll have to do
lots of reading and some coding before you'll be able to do what you
want to do. Django isn't a turn-key solution. It's a programmers tool.
And nobody can teach you to program using lots of emails, you have to
learn it yourself. And yes, it will take a long time[0].

If you have a more specific question I (and others) will be happy to
try to answer it. One could write a book trying to answer your
question and still not succeed. And there _are_ good books which will
bring you there. www.djangobook.com is one of these.

I do not want to offend or discourage you, but I doubt that you really
went through the book if you still need to ask how to get started with
Django and CSS. Really, try to start with the basics, that is, set up
a simple site with Django, and only then start thinking about working
with prebuilt CMS systems.



[0]: http://norvig.com/21-days.html : Teach Yourself Programming in Ten Years

-- 
FeinCMS Django CMS building toolkit: http://spinlock.ch/pub/feincms/

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Psyco

[Matthias Kestenholz]

On Thu, Aug 13, 2009 at 5:35 PM, Jonas Obrist wrote:
>
> Torsten Bronger wrote:
>> Hallöchen!
>>
>> Jonas Obrist writes:
>>
>>
>>> Is anyone using psyco in django? Does it work and is it useful (as
>>> in: do you get great speed improvements)?
>>>
>>
>> I've once seen a benchmark indicating considerable improvements of
>> Django performance with psyco, but only on 32 bit systems.  On 64
>> bit, psyco was a slight drawback.
>>
>> Tschö,
>> Torsten.
>>
>>
> As far as I knew psyco is 32bit only anyway...
>
> Also: does anyone know if I have to put 'import psyco; psyco.full()'
> into every file or if there's a central place where I can enable it for
> the whole django and my whole app? I'm on a 32bit system and have
> performance issues...
>

Are you using WSGI? runner.wsgi (or whatever your wsgi script is
named) might be a good point to put the psyco import. I'm not sure if
it works as expected though.

I'm asking myself a bit whether it is really the python code which is
running too slow on your system. Have you profiled your website /
webapplication? Maybe the reason for the slowness lies elsewhere? F.e.
complicated Javascript code, too many DB queries or something else?


Matthias




-- 
FeinCMS Django CMS building toolkit: http://spinlock.ch/pub/feincms/

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: More Than Two Models With inlineformset_factory

[Matthias Kestenholz]

On Wed, Aug 12, 2009 at 7:36 PM, Geraldo wrote:
>
> No, I mean two or more different forms.  I'd like Parent, Child1 AND
> Child2 all in the same formset.  What you've suggested though, should
> get me where I want to go.
>

Well, you can easily show the input fields from Formset1 and Formset2
intertwined. You need to output the mangement forms and the individual
fields by hand. It's very similar to outputting form elements by hand
instead of using the as_ul/as_table convenience methods.


Hope it helps,
Matthias




-- 
FeinCMS Django CMS building toolkit: http://spinlock.ch/pub/feincms/

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: More Than Two Models With inlineformset_factory

[Matthias Kestenholz]

On Wed, Aug 12, 2009 at 12:51 AM, Geraldo wrote:
>
> Excellent, Matthias...  That should work nicely.  It does appear,
> however, that there is no way to have more than 2 forms in a single
> formset.  If inlineformset_factory had an append method things might
> be a bit cleaner.
>

I presume you mean more than two forms of the same type (Child1 or
Child2)? That's easily possible, and we use it all the time. Take a
look at the max_num and extra parameters to the factory function.


Matthias



-- 
FeinCMS Django CMS building toolkit: http://spinlock.ch/pub/feincms/

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: More Than Two Models With inlineformset_factory

[Matthias Kestenholz]

On Tue, Aug 11, 2009 at 10:04 PM, Geraldo wrote:
>
> Hi,
>
> I'm new to Django and am putting together a page for my new site.  I
> want to be able to edit data that is contained in 3 models, organized
> as follows:
> Parent
>  --> Child 1 (always one to one)
>  --> Child 2 (one or more)
>
> I understand I can do the following:
>
> class Parent(models.Model):
>    name = models.CharField(max_length=100)
>    parent_type = models.CharField(max_length=10)
>
> class Child1(models.Model):
>    name = models.ForeignKey(Author)
>    address = models.CharField(max_length=100)
>
> class Child2(models.Model):
>    name = models.ForeignKey(Author)
>    gender = models.CharField(max_length=8)
>
> # so I can do this to get a formset with Parent and Child1
> Formset1 = inlineformset_factory(Parent, Child1)
> dad = Parent.objects.get(name=u'Popeye')
> formset = Formset1(instance=dad)
>
> # or this to get a formset with Parent and Child2
> Formset2 = inlineformset_factory(Parent, Child2)
> dad = Parent.objects.get(name=u'Popeye')
> formset = Formset2(instance=dad)
>
> What I don't understand is how I get both child1 and child2 in my
> formset?
>

You can pass a prefix parameter when constructing the formsets (not
the formset classes):

Formset1 = inlineformset_factory(Parent, Child1)
Formset2 = inlineformset_factory(Parent, Child2)

if request.method == 'POST':
child1_formset = Formset1(request.POST, ..., prefix='child1')
child2_formset = Formset2(request.POST, ..., prefix='child2')
else:
child1_formset = Formset1(..., prefix='child1')
child2_formset = Formset2(..., prefix='child2')


This prefix will be added to all formset fields automatically. The
browser and Django will be able to differentiate between the two
formsets now.

Matthias

-- 
http://spinlock.ch/pub/feincms/

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: is Django a good choice for a LAN app?

[Matthias Kestenholz]

On Tue, Aug 11, 2009 at 10:00 PM, Peterle wrote:
>
> Perhaps Zope-Plone is more suitable for that purpose.

Perhaps not.

Do you have anything to back this statement? (I'm not saying it's
untrue, I'm just trying to point out that this contribution wasn't
particularly helpful.

A bit more on topic: I've built an intranet application (sort of a
CRM) on Django, and I think it works great for this purpose.


Matthias

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: django-cms-2.0 problem

[Matthias Kestenholz]

On Tue, Aug 11, 2009 at 1:01 AM, odonnell wrote:
>
> I'll try starting with the example project this time, maybe something
> in there is different than starting a project with django-admin.py
> startproject.
>

The standard django project skeleton does not have
django.core.context_processors.request in its
TEMPLATE_CONTEXT_PROCESSORS list.

The traceback you sent in the other thread never touches the
django-cms2 code itself. It seems that you overwrote
TEMPLATE_CONTEXT_PROCESSORS with a list containing only the request
context processor, and left out the auth context processor which is
required by the admin interface (it's not the only one that's
required...)


Matthias




-- 
http://spinlock.ch/pub/feincms/

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: javascript variable in url resolver template tag

[Matthias Kestenholz]

On Sun, Aug 9, 2009 at 5:43 PM, Sven Richter wrote:
> Hi all,
>
> i wanted to know if it is possible to pass a Javascript variable to
> the url template tag?
>
> Like:
> 
> ...
> 

Re: Javascript with built-in templates tags

[Matthias Kestenholz]

On Sat, Aug 8, 2009 at 6:34 PM, WilsonOfCanada wrote:
>
> I am not sure; I am just trying to pass the variable from the
> dictionary using render_to_response to a javascript function.  The
> function is stored as a .js file.  This is a part of the code I am
> using it for:
>
> {{ selectCity|safe }}
>
>  onchange = "changeArea({{ mooman | safe | escapejs}});">
> 
>
> The {{ selectCity|safe }} works but the {{ mooman | safe | escapejs}}
> does not.  I was wondering if the syntax is incorrect or they cannot
> be used between " ".  Please show an example.
>

Why don't _you_ show us the generated HTML code and point out what's
unexpected about it? It will be much easier for us to help you.

A stab in the dark, since I have no idea what the content of mooman
might be: Maybe you want onchange="changeArea('{{ mooman|safe|escape
}}');" ? (Note the additional quotes around your {{ }} expression)


Matthias

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: annotate() and subsets or related records

[Matthias Kestenholz]

On Mon, Aug 3, 2009 at 11:17 PM, Javier Guerra wrote:
>
> Hi all,
>
>
> I've just upgraded to 1.1 (congrats everybody!), and want to put the
> aggregation/annotation features to use.  but it doesn't seem to be a
> way to annotate the records with counts of different subsets of
> related records.
>
> my problem:  i have  'Order' and 'Item' models, and the items can be
> on several states or processing:
>
> class Order (models.Model):
>        order_no = models.Integerfield()
>        date = models.DateTimeField()
>        client = models.ForeignKey (Client)
>
> class Item (models.Model):
>        order = models.ForeignKey (Order)
>        description = models.CharField (max_length=50)
>        price = models.DecimalField (max_digits=7, decimal_places=2)
>        quantity = models.IntegerField()
>        status = models.SmallIntegerField()
>
> and I want to show a list of all the orders, with columns showing how
> many items are on each state:
>
> | order  | client       | not yet | processing | ready |
> 
> | 01 | Jon Doe      |    5    |     4      |   0   |
> | 02 | Jane Smith   |    2    |     7      |   3   |
> 
>
> so far, i only found how to add a column with the total number of items:
>
> Order.objects.annotate(Count('item'))
>
> but i can't count subsets of items.  Is there any way to do that in
> the DB, or I have to do it in Python?


You currently cannot do this in one step, but maybe something like
this might give you ideas:

# orders is a queryset or a list of Order objects
Item.objects.filter(order__in=orders).values('order',
'status').annotate(Sum('quantity'))

... and then you post-process the returned values in some way. At
least you can use the database capabilities for a significant part of
what you are interested in.


Matthias

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: view/form with fields from multiple models

[Matthias Kestenholz]

On Fri, Jul 24, 2009 at 10:46 AM, Benjamin  Wohlwend wrote:
>
> On Jul 24, 10:37 am, Benjamin  Wohlwend  wrote:
>
>>
>> if all(f.is_valid() for f in (form1, form2, form3)):
>>     # ok, save
>>
>
> Oops, forgot to mention that I had to implement my own version of all
> (), which doesn't short cut:
>
> def really_all(iter):
>    all_true = True
>    for val in iter:
>        if not val:
>            all_true = False
>    return all_true


There is a function in Django proper which does exactly that:
django.forms.formsets.all_valid

Since is_valid works the same for forms and formsets you can use this
for plain forms too.


Matthias

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: urls.py import() usage?

[Matthias Kestenholz]

On Thu, Jul 23, 2009 at 5:33 PM, Joshua Russo<josh.r.ru...@gmail.com> wrote:
> On Thu, Jul 23, 2009 at 2:18 PM, Matthias Kestenholz
> <matthias.kestenh...@gmail.com> wrote:
>>
>> On Thu, Jul 23, 2009 at 4:51 PM, Joshua Russo<josh.r.ru...@gmail.com>
>> wrote:
>> >
>> > Is there any difference between using import() versus not in the url
>> > pattern list?
>> >    (r'^accounts/login/$', 'django.contrib.auth.views.login'),
>> >    (r'^admin/doc/', include('django.contrib.admindocs.urls')),
>>
>> Are you asking about import or include? Where would your imports be?
>
>
> Sorry, I meant include.

Well, there is a big difference between the two. include() takes the
python path to an URLconf file while the other form takes a view.

You should read the documentation on this page if you haven't done this already:
http://docs.djangoproject.com/en/dev/topics/http/urls/#topics-http-urls


Matthias

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: urls.py import() usage?

[Matthias Kestenholz]

On Thu, Jul 23, 2009 at 4:51 PM, Joshua Russo wrote:
>
> Is there any difference between using import() versus not in the url
> pattern list?
>    (r'^accounts/login/$', 'django.contrib.auth.views.login'),
>    (r'^admin/doc/', include('django.contrib.admindocs.urls')),

Are you asking about import or include? Where would your imports be?


Matthias

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Current user in model.save() context

[Matthias Kestenholz]

On Mon, Jul 20, 2009 at 9:26 AM, Bartłomiej Górny wrote:
> [...]
>> there is a cookbook recipe for achieving this sort of thing:
>>
>> http://code.djangoproject.com/wiki/CookBookThreadlocalsAndUser
>
> Yep, that's exactly what I did :)
>
>>
>> That's deep in the category of 'give them rope to hang themselves
>> with' though. You should understand the implications and design
>> decisions involved before hacking your way around it.
>
> I give +1 to Joshua's request - plz explain.
>

thread locals have all the problems which are generally associated
with global variables. They might be overwritten by other code, they
make testing extremely difficult because the behavior of methods may
depend on non-obvious circumstances and it's not clear from the method
signatures which variables are really used -- in short, it makes code
maintenance much harder than it needs to be.

I'll try giving a few examples:

- You have a field on your model called last_modified_by, and you
automatically assign request.user in the save() method. You made this
piece of code much harder to test in an unittest than it needs to be,
because now you have to provide the complete environment including the
variables from the threadlocals space in your testsuite. More code is
needed, and the probability that the code and the testsuite (and
eventual documentation) get out of sync gets bigger and bigger.

- Something which I've done for a CRM system which we've developped
for internal use together with another company was giving Tasks access
levels, so that we were able to make certain tasks viewable only by
the management. I built a manager which uses the user information from
thread local space to filter the queryset automatically according to
the profile of the currently authenticated user. With this seemingly
simple move I've made it impossible to use loaddata/dumpdata, because
no user exists, and I made it very non-obvious that the list of
viewable tasks depends on the user. You would not get the idea that
filtering is going on in the templates or even in a big part of the
code. This is not a big problem when developping alone, but it can
really hamper progress if someone else takes over the codebase.

In short: It's easy and it gets the job done, but will come back and
bite you later for sure. Don't give in to the temptation -- it's much
better to write custom template tags where you can pass the user
explicitly to the function, which makes it very clear that the
output/the result of a certain function depends on the user. It also
makes testing a breeze, because the behavior of methods is only
determined by their arguments (as it should be), not by other
circumstances or the current weather.


Matthias

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: pre-fetch one-to-many and many-to-many relationships

[Matthias Kestenholz]

Hey,

On Fri, Jul 17, 2009 at 5:06 PM, Miriam<magol...@gmail.com> wrote:
>
> There currently is no way in Django to pre-fetch one-to-many and/or
> many-to-many relationships, right?
>
> There's select_related, which will pre-fetch FK or one-to-one, which
> is great, but not sufficient.
>
> Suppose I am fetching a list of Blog posts and I want to pre-fetch the
> Comments for each of these posts? There's no way to do that in
> Django.
>
> I was looking through the tickets at code.djangoproject.com and I
> didn't see anything about this.
>
> Does anyone know if this feature is planned for sometime down the
> road? Anyone have a work-around or a patch or anything. This is
> supremely irritating.
>

I have implemented prefetching (I've choosen the name 'prefilling',
but prefetching might be more appropriate) for a CMS I'm working on;
you can find the code here:

<http://github.com/matthiask/feincms/blob/426e1b62c3df89a990f5f569abc5ef53bf38e0e7/feincms/utils.py>

I can do something like that to prefetch authors (m2m), images and
richtext elements (both reverse foreign keys) for a list of blog posts
for example. It wont work for django.contrib.comments though, since
the comments model uses generic relations, and I've not implemented
prefetching for those yet.


Matthias
Maybe it will inspire someone to create

> Miriam
>
> >
>



-- 
Matthias Kestenholz
Konzept & Programmierung

FEINHEIT GmbH
Dienerstrasse 15
CH-8004 Zürich

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Current user in model.save() context

[Matthias Kestenholz]

On Fri, Jul 17, 2009 at 4:24 PM, Bartłomiej Górny wrote:
>
> Phil wrote:
>> Hi Josh,
>>
>> unfortunately it seems that there is no way to do so. As you've
>> noticed that correctly you can use request (request.user) in any place
>> but model save.
>
> Yes, I bumped into the same problem and came to the same conclusion. No
> way. Unless you hack out something along the lines of
> translation.activate/get_language - using a global dictionary and
> current thread. It works, but is hardly in line with Django spirit.
>
> I think it is a design decision, to keep MVC structure clean. Though it
> might be arguable if it would really seriously breach the MVC principle.
> Maybe it is worthwhile.
>

If you really need to do that (or if you are just extremely lazy)
there is a cookbook recipe for achieving this sort of thing:

http://code.djangoproject.com/wiki/CookBookThreadlocalsAndUser


That's deep in the category of 'give them rope to hang themselves
with' though. You should understand the implications and design
decisions involved before hacking your way around it.


Matthias

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Cached forms when changing language- Is this a bug?

[Matthias Kestenholz]

Hi,

On Fri, Jul 17, 2009 at 9:14 AM, Adrián Ribao wrote:
>
> Hello everybody,
>
> I have an multi language site with a form in the home. If I change the
> language of the site everything changes but the form takes a few
> minutes before I see it in the right language.
>
> If I reload the server the form is visualized ok, but this is not the
> right behaviour.
>
> The code of the form is somethin like:
> from django.utils.translation import ugettext as _

You need ugettext_lazy instead of ugettext when declaring forms:
from django.utils.translation import ugettext_lazy as _

Read about it here:
http://docs.djangoproject.com/en/dev/topics/i18n/#lazy-translation


Matthias

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: using modelformsets

[Matthias Kestenholz]

Hi,

On Sun, Jul 5, 2009 at 11:42 PM, Eric Abrahamsen wrote:
>
> I'm somehow failing to use modelformsets, this is the relevant view
> and error traceback:
>
> http://dpaste.org/evHq/
>
> I'm validating a whole bunch of forms at the same time, but I don't
> see how that could cause the formset failure. Sample is a model with a
> ForeignKey to Author (though the ForeignKey field itself is called
> 'translator', stupid naming practice). I'm hoping there's something
> obviously wrong with what I'm doing there, but I can provide more
> details if necessary...
>


It seems that the modelformset code cannot find the primary key values
in the POST request. You need to include the primary key hidden field
in your form code, otherwise it will not work; something like this:

{% for form in formset %}
   {{ form.id }}
   {# the rest of your code #}
{% endfor %}


I don't recall whether this is documented or not. This approach worked
for me, though.



Matthias

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Translation question : some strings not translated

[Matthias Kestenholz]

Hi,

2009/7/2 François Verbeek :
> Mmm to make the problem easier to deal with I wrote a very very small
> app with just 1 view and a very basic template :
> from django.http import HttpResponse
> from django.utils.translation import ugettext as _
> from django.shortcuts import render_to_response,get_object_or_404
> def display_a_string_through_template(request,**kwargs):
>      data=kwargs.get("argument","nothing")
>      string=_("Hi, there %(wee)s" % {'wee':data})

This should be _("Hi, there %(wee)s") % {'wee': data}

Note the placement of parentheses. gettext recognizes only the string
"Hi, there %(wee)s" before interpolation, and not anymore when the
content of 'wee' has been filled in.


Matthias

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Customizing extends template tag for mobile version of site

[Matthias Kestenholz]

On Fri, Jun 5, 2009 at 6:35 PM, Andrew Fong  wrote:
>
> I was hoping someone could explain to me what the exact behavior would
> be if the Extends Node in the template was not first.
>
> Here's my use-case scenario: I need to maintain separate mobile and
> desktop templates for my site. I'm finding out that 90% of my
> templates would be identical -- the only difference would be which
> templates they extended from -- e.g. {% extends 'base.html' %} vs. {%
> extends 'm_base.html' %}.
>
> My views insert a mobile variable into the context if they think the
> user-agent is a mobile device. So I want behavior like this:
>
> {% if mobile_var %}
>  {% extends 'm_base.html' %}
> {% else %}
>  {% extends 'base.html' %}
> {% endif %}
>
> This won't work because the the extends tag doesn't really understand
> the {% if %} tag above it and just throws up when it comes to the {%
> else %} tag. So as an alternative, I plan to encapsulate that logic in
> a custom extends tag -- e.g. {% mextends mobile_var 'm_base.html'
> 'base.html' %} that wraps the existing do_extends function.
>
> When going over the ExtendNode source code however, I noticed it has
> to be first. However, in order to use my custom tag, I need to call {%
> load %}, and that call means any ExtendNode created after that can't
> be first. I'm tempted to simply disable that, but I'm not really sure
> what will happen if I do. Are there any problems with calling a load
> tag before an extends?
>


I don't know the answer to your question, but here is a suggestion how
you might accomplish using a different base template for the mobile
version of your site. The extends tag accepts a variable too, so you
could just use a context processor to pass the base template into the
renderer, something like this (in pseudo-code):


def base_template(request):
 return {'base_template': is_mobile(request) and 'm_base.html' or
'base.html'}


And inside your templates, use:
{% extends base_template %}



Matthias

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Quoting in extra(select=...) expression

[Matthias Kestenholz]

Hey,

On Mon, May 11, 2009 at 9:09 PM, lemming110  wrote:
>
> I am trying to use the select keyword in extra.  But I cannot properly
> quote the the expression for postrgres.  I am using the
> django.contrib.comments.  I started with this snippet
> http://www.djangosnippets.org/snippets/1101/ which returns the number
> of comments for an object.  However, the code does not work.  The
> problem that the field django_comment.object_pk is text and my item pk
> is integer.
>
> In postgres, this works:
>
> select count(*)
> from django_comments
> where django_comments.content_type_id=12 and
> django_comments.object_pk='332';
>
> But using extra(select={'comment_count': sql,}) where
>
> sql = '''select count(*)
> from django_comments
> where django_comments.content_type_id=12 and
> django_comments.object_pk=
> %s'''
>
> gives me an error every way that I have tried to add quotes.  (This
> includes django.db.connection.ops.quote_name.)
>
> Any ideas on how to embedded quotes in postgres?
>

Why don't you try using the built-in annotation and aggregation
support of django? Should be much easier than trying to do it
yourself...

http://docs.djangoproject.com/en/dev/topics/db/aggregation/


Matthias

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Ajax and non-ajax forms.

[Matthias Kestenholz]

Hey,

On Wed, May 6, 2009 at 3:27 PM, Chris Dew  wrote:
>
> I'd like to develop a Django application with the following
> properties:
>
> A page (list of items) will have a link to a page with a form to add a
> new item.
>
> If there is no javascript, the link will take the user to the new page
> and let the user submit the form, then return them to the initial page
> when the form successfully validates.
>
> If there is javascript, the link will open the form *within* the
> current page (via ajax, perhaps as thickbox or greybox).  Submission/
> validation errors of/on the form will take place entirely within the
> current page.  When the for is submitted and valid, the form's div
> will disappear/close.
>
>
> At the moment, I think that I need to have ajax and non-ajax views for
> *each form* within the application.
>
> I also need to code form template snippets (for ajax) for *each form*
> which are included by the templates for the non-ajax pages.
>
> Has anyone developed a Django extension which makes this easier - some
> form of 'unajax for non javascript-capable browsers'.
>
> I realise that I'll probably need to do this myself, by hand, but I
> thought I'd ask the question, just in case.


Just to give you some ideas (it really is not that hard):


def your_view(request):
# your processing code

if request.is_ajax():
return render_to_response('_form.html', {}...)
else:
return render_to_response('form.html', {}...)

Your form.html template should contain not much more than the following code:

{% extends "base.html" %}

{% block content %}

{% include "_form.html" %}

{% endblock %}



If you use the jQuery form plugin (it's what I know, not what I want
to advertize -- I'm sure every javascript library has the bestest way
to do it), you can prepare your form like this:

$('#form form').ajaxForm({'target': '#form'})



So in closing, you'll need several templates which are only used if
the client does not support javascript; there is still some code
duplication around, but not too much anymore, because you can reuse
the view code and the _form.html template.


I hope this'll put you on track.
Matthias

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: i need a unlimited subcategories

[Matthias Kestenholz]

On Tue, Apr 28, 2009 at 3:09 PM, Alex Robbins
 wrote:
>
> For a real simple solution you might just set up a foreign key field
> that points to the parent of any given category. (If you don't need
> the extra features of those libraries, they might just make things
> more complicated.)
>
> E.g. subcat1-1-1 and subcat1-1-2 are fk'ed to subcat1-1.
> subcat1-1 is fk'ed to cat1
> Anything with a null fk field is a top level category.
>
> I might call the fk field parent, and set the related_name of the
> foreign key to children. Then you could access stuff like this:
subcat1-1.parent
> 
subcat1-1.children.all()
> [  , ]
>
> Anyway, it works in my head. I haven't actually coded any of it.
> Hope that helps,
> Alex
>

Although this would in fact work, it would be inefficient. mptt adds and
manages additional attributes on your models to allow for efficient retrieval
of all children, all ancestors etc. with a single query instead of executing one
query per parent until you get to the root of the tree. If you want arbitrarily
deeply nested categories, you _really_ want to look into using something
like django-mptt.

Matthias

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Query to retrieve users from a given group

[Matthias Kestenholz]

On Fri, Apr 17, 2009 at 3:18 PM, Daniel Roseman
 wrote:
>
> On Apr 17, 1:23 pm, Bastien  wrote:
>> Hi,
>>
>> I'm trying to retrieve a list of users belonging  to a given group but
>> don't understand how to do it. It must be a sort of many to many query
>> but I can't get it to work.
>>
>> I would like to do something like this:
>>
>> basic_users_list = User.objects.filter(groups__in=Group.objects.get
>> (name='basic'))
>>
>> but django tells me that:
>>
>> 'Group' object is not iterable
>>
>> If there is another way to do some actions on a given group then I
>> would be as happy.
>>
>> thanks for your guidance.
>
> Does this not work?
> basic_users_list = User.objects.filter(
>    groups=Group.objects.get(name='basic'))
>

You're hitting the database twice which seems unnecessary given that
you don't do anything with the group object.

You could simply use the following piece of code and be done with it:

basic_users_list = User.objects.filter(groups__name='basic')

Or have I missed something?

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Fieldlookup: NOT

[Matthias Kestenholz]

On Thu, Apr 16, 2009 at 3:56 PM, Thomas Guettler  wrote:
>
> Hi,
>
>
> For forms which display a list of results I use:
>    form=QueryForm(request.GET)
>    
>    queryset=MyModel.objects.filter(**form.cleaned_data)
>
> But, now I need to use exclude() instead of filter().
>
> I looked at the queryset API, but it seems that there is no
> alternative to qs.exclude().
>
> Wouldn't it be nice to have a "not" field lookup? Example:
>
> MyModel.objects.filter(field__not=...)
> MyModel.objects.filter(field__not__in=...)
>


There is this:

from django.db.models import Q
MyModel.objects.filter(~Q(field__in=...))

This should do what you want. You could also let the form create an
appropriate Q object which you can pass into the filter method.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Django MPTT Admin

[Matthias Kestenholz]

Hey,

A topic which comes up on this list from time to time is an automatic
admin interface for django-mptt. I'd like to advertise a piece of code
we have written at our company a little bit, and I'd also like to invite
everyone to give comments and feedbacks. I do have many more ideas
floating around, and there are a couple of issues still open, but I think
the code is ready for wider review and maybe usage, who knows?


The current version of the code generates an interface with drag/drop
capabilities for managing mptt-based trees. It's still very clear that the
code was extracted from a `classical' page cms. All you need to do
is the following:


-- 8< --

from django.db import models

class Category(models.Model):
title = models.CharField(max_length=200)
parent = models.ForeignKey('self', related_name='children',
blank=True, null=True)

-- 8< --

from django.contrib import admin
from feincms.admin import editor

class CategoryAdmin(editor.TreeEditorMixin, admin.ModelAdmin):
pass

admin.site.register(Category, CategoryAdmin)

-- 8< --

The generated admin interface looks like that:

http://spinlock.ch/pub/feincms/category_tree_admin.png

The page cms feeling is still very much there, but we'll see.

In any case, you'll find the code on github:
http://github.com/matthiask/feincms/tree/master


Thanks,
Matthias




-- 
"Programming is an art form, like the creation
of poetry or music." (Donald E. Knuth, 1974)

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Securely storing passwords

[Matthias Kestenholz]

Hi,

On Tue, Feb 24, 2009 at 12:49 PM, LaundroMat  wrote:
>
> Hi -
>
> I'm working on a small django app that allows users to interact with
> other websites where they have an account. Ofcourse, using this app
> means providing your username and password for the other website.
>
> What are the most secure ways of handling this information? I suppose
> encrypting the passwords is one option, but are there any ways to
> prevent people who have access to the app's source code and database
> of retrieving user's names and passwords?
>


We do this by encrypting the usernames and passwords with GPG. Using
browser plugins like FireGPG makes it possible to encrypt and decrypt
the content without leaving the website.


Matthias

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Equivalent of find_or_create_by in Django

[Matthias Kestenholz]

Hey,

On Tue, Feb 17, 2009 at 2:33 PM, Anders
 wrote:
>
> Hi.
>
> I do a lot of csv-import of data and have previously been using Ruby
> on Rails. And the only thing I miss about Rails (apart from database
> migration) is the find_or_create_by methods.
>
> Are there any similar methods in Django?
>

Yes, take a look at get_or_create:
http://www.djangoproject.com/documentation/models/get_or_create/

> My use is like this:
>
> I import a CSV file, and in one column there is a value (i.e. a
> string). I don't want to store it as a string in Model1, but as a
> foreign key to Model2 - thus trying to find a record that has the
> string and returning the foreign key id if found - else create the
> object in Model2.
>
> From the rails api:
>
>  # No 'Summer' tag exists
>  Tag.find_or_create_by_name("Summer") # equal to Tag.create(:name =>
> "Summer")
>
>  # Now the 'Summer' tag does exist
>  Tag.find_or_create_by_name("Summer") # equal to Tag.find_by_name
> ("Summer")
>
>  # Now 'Bob' exist and is an 'admin'
>  User.find_or_create_by_name('Bob', :age => 40) { |u| u.admin =
> true }
>
> I know it's probably bad to say that Rails is good in some ways in a
> Django forum, so forgive me :)
>

Why?


Matthias

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: get children of children

[Matthias Kestenholz]

On Wed, Sep 24, 2008 at 9:25 AM, Evgeny <[EMAIL PROTECTED]> wrote:
>
> Hi,
> There's an object hierarchy: A references B, B references C.
> "references" means foreign key.
> Is there a nice Django way to select all C objects which are
> grandchilds of given A with one query? Somethink like
>
> select C.* from C
> join B on B.id = C.id_b
> join A on A.id = B.id_a
> where A.id = 1
>
> i.e. in Django terms get all C objects which are children of
> A.objects.get(id=1).B_set.all()

You probably mean this:
C.objects.filter(id_b__id_a__exact=1)

Your code and your description do not match though. You write
'A references B', but you've got a foreign key from B to A (field id_a)
Maybe you meant A is referenced by B?


Matthias

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Sending HTML email

[Matthias Kestenholz]

On Tue, Sep 23, 2008 at 7:38 PM, Berco Beute <[EMAIL PROTECTED]> wrote:
>
> Currently I'm sending plain text mails using:
>
> ###
> from django.core.mail import EmailMessage
> email = EmailMessage('hi', 'howdy', host, to)
> email.send()
> ###
>
> But now I want to use HTML in the body of the email. How do I format
> such a message and can I just send it like above?
>

Yes, or at least in a similar way. You might try reading the documentation:
http://docs.djangoproject.com/en/dev/topics/email/#sending-alternative-content-types

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Template Inheritance Question

[Matthias Kestenholz]

On Sat, Sep 20, 2008 at 12:08 AM, David Durham, Jr.
<[EMAIL PROTECTED]> wrote:
>
> On Fri, Sep 19, 2008 at 4:07 PM, djandrow <[EMAIL PROTECTED]> wrote:
>>
>> I have a template, text that extend a template base.
>>
>> In my text template I have;
>>
>> {% extends 'base.html' %}
>>
>> {% block content %}
>>
>> SOME CODE
>>
>> {% endblock content %}
>
> I'm not a django expert, but I think that you don't need {% endblock
> content %}, just {% endblock %}.
>

That's allowed (http://docs.djangoproject.com/en/dev/topics/templates/#id1) but
not used too often.

>> Anyway, my question is when I enter this save it then stick it on my
>> server, it adds closing tags at the bottom;  and the
>> Doctype stored in base,html on the top, is this the way i'm uploading
>> the files or is it sommething to do with Django, and if so is there
>> anyway to stop it?
>

The template system works for nearly everbody else, so you must be
doing something wrong. Do you have the closing tags in all files or only
in base.html? If they are in all files it's no surprise that they appear twice
in the final input.

If you'd post your template files to dpaste or quote the relevant parts in
an email, maybe someone will have further tips for you.


Matthias

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Template problem with dates(field, kind, order='ASC')

[Matthias Kestenholz]

On Sat, Sep 13, 2008 at 11:49 PM, djandrow <[EMAIL PROTECTED]> wrote:
>
> This is probably really really obvious. I have the following statement
> in my views.py:
>
> archive_list = Entry.objects.dates('entry_date', 'month',
> order='DESC')
>
> then I have;
>
> {% for archive in archive_list %}
>
> {{ archive.datetime }}
>
> {% endfor %}
>
> in my template, i am 99.9% my problem is with {{ archive.datetime }}.
>
> Any help would be much appreciated,
>

It would be helpful if you'd include what went wrong or what did not
match your expectations.

Matthias

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: flatpage -- content type?

[Matthias Kestenholz]

On Sat, Sep 13, 2008 at 11:12 PM, shaunc <[EMAIL PROTECTED]> wrote:
>
> umm... but that's not exactly according to "D.R.Y." :) -- but thanks.
>

It's good to try to follow DRY, but it's not the solution for everything. Django
is a tool box, not a CMS with everything included. Sometimes it's better to
write a few lines of code instead of trying to add more knobs and configurables
to existing code... remember, "Do one thing, and do it well" instead of "Try
doing 1000 things, but still fail at most of them."


Matthias

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: flatpage -- content type?

[Matthias Kestenholz]

On Sat, Sep 13, 2008 at 9:33 PM, shaunc <[EMAIL PROTECTED]> wrote:
>
> Hello,
>
> Does anyone know how to set the content type when serving a page via
> FlatPages?
>

You have to write your own middleware or view function. This is
easy enough since you can copy the flatpages view and middleware
code and modify it for your needs.

Matthias

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Restricting views

[Matthias Kestenholz]

On Thu, Sep 11, 2008 at 6:00 PM, ek_wals <[EMAIL PROTECTED]> wrote:
>
> What then is the point of 'is_superuser'  or superuser's in general?
>
> Looking through the Django code, it seems that the only use for
> superusers is that a superuser is automatically a moderator.
>
> Could be so much more.
>

Yeah, ... a super user could have all permissions that are defined
in a project for example. Wait a moment -- that's already true today!
(See the User has_perm method)

Do you have some other ideas, what a superuser could be apart from that?

Matthias

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Restricting views

[Matthias Kestenholz]

On Thu, Sep 11, 2008 at 5:22 PM, ek_wals <[EMAIL PROTECTED]> wrote:
>
>
> And I can see exactly how to do it --
> copy  contrib/admin/views/decorators.py:staff_member _required   and
> change
> 'request.user.is_staff'  to 'request.user.is_superuser'
>
> Sure seems repetitive (non-DRY) (wet?)
> Its seems so easy that I can't help but think that I'm overlooking
> something. Why would Django provide both 'is_staff' and 'is_superuser'
> but only provide a decorator for one of them??  Assuming that its just
> an oversight seems dangerous.
>
> Any thoughts would be welcome

Well, normally it is interesting if a user has certain permissions (is he
allowed to log into the admin interface, does he have add permission on
a certain model). It is seldom interesting to know if she has ALL permissions.

Matthias

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---