armstrong / armstrong Goto Github PK

We should have South listed in the INSTALLED_APPS by default and it should be in all of the project level requirements files.

Any idea what could cause an error like this?

Traceback:
File "/usr/lib/python2.7/dist-packages/django/core/handlers/base.py" in get_response

1.                 response = response.render()
   

   File "/usr/lib/python2.7/dist-packages/django/template/response.py" in render

2.         self._set_content(self.rendered_content)
   

   File "/usr/lib/python2.7/dist-packages/django/template/response.py" in rendered_content

3.     content = template.render(context)
   

   File "/usr/lib/python2.7/dist-packages/django/template/base.py" in render

4.         return self._render(context)
   

   File "/usr/lib/python2.7/dist-packages/django/template/base.py" in _render

5.     return self.nodelist.render(context)
   

   File "/usr/lib/python2.7/dist-packages/django/template/base.py" in render

6.             bits.append(self.render_node(node, context))
   

   File "/usr/lib/python2.7/dist-packages/django/template/debug.py" in render_node

7.         result = node.render(context)
   

   File "/usr/lib/python2.7/dist-packages/django/template/loader_tags.py" in render

8.     return compiled_parent._render(context)
   

   File "/usr/lib/python2.7/dist-packages/django/template/base.py" in _render

9.     return self.nodelist.render(context)
   

   File "/usr/lib/python2.7/dist-packages/django/template/base.py" in render

10.             bits.append(self.render_node(node, context))
    

    File "/usr/lib/python2.7/dist-packages/django/template/debug.py" in render_node

11.         result = node.render(context)
    

    File "/usr/lib/python2.7/dist-packages/django/template/loader_tags.py" in render

12.         result = block.nodelist.render(context)
    

    File "/usr/lib/python2.7/dist-packages/django/template/base.py" in render

13.             bits.append(self.render_node(node, context))
    

    File "/usr/lib/python2.7/dist-packages/django/template/debug.py" in render_node

14.         result = node.render(context)
    

    File "/home/avoine/repos/armstrong/armstrong_site/external_apps/armstrong/core/arm_layout/templatetags/layout_helpers.py" in render

15.     objs = self.obj_list.resolve(context)
    

    File "/usr/lib/python2.7/dist-packages/django/template/base.py" in resolve

16.             new_obj = func(obj, *arg_vals)
    

    File "/usr/lib/python2.7/dist-packages/django/template/defaultfilters.py" in slice_

17.     return value[slice(*bits)]
    

    File "/home/avoine/repos/armstrong/armstrong_site/external_apps/armstrong/core/arm_wells/querysets.py" in wrapper

18.         args[0]._prep()
    

    File "/home/avoine/repos/armstrong/armstrong_site/external_apps/armstrong/core/arm_wells/querysets.py" in _prep

19.     for obj in self.queryset:
    

    File "/home/avoine/repos/armstrong/armstrong_site/external_apps/armstrong/core/arm_wells/querysets.py" in wrapper

20.         args[0]._prep()
    

    File "/home/avoine/repos/armstrong/armstrong_site/external_apps/armstrong/core/arm_wells/querysets.py" in _prep

21.         key = "%s.%s" % (model_class.**module**, obj_ct.model)
    

Exception Type: TemplateSyntaxError at /
Exception Value: Caught AttributeError while rendering: 'NoneType' object has no attribute 'module'

The ability to create pages that are more complex than a regular story is key to an engaging, unique site. One thing that we keep running into at the Tribune is the ability to do stories that have an article, a video or images, and some sort of interactive (whether we wrote it or its embedded). An example of this is Stay of Execution Could Give Death Row Inmate Another Day in Court from this past summer.

Giving journalists this ability without having to code anything would be an amazing feature, but there are several components that would need to be tackled. Here's a visual with some markup showing what would go where.

There are a couple of things necessary for this.

• Page Layout Tool: This could be pretty simple. Drop-downs and such with a click to preview would be sufficient for a quick first-draft. It might be easy enough to have a ContainerPage model that can have N relationships to other models, then stacking those other models makes for more complex relationships and displays.
• Model Templates: Each model would need to have some way to render itself and to ask for configuration. For this example, we'd need a `TabbedPage`` model that provides relationships to N other models and titles for those relationships. Ideally we would be able to do this all a layout app in the admin, but a model with drop downs could work as a first pass.

I know this isn't a "big deal" or anything, but I really wish arm_layout was called arm_inlines. Maybe it's just semantics, but all the templates that go in layout app aren't templates for a site layout but are really templates for inline elements that get placed on a page.

We could iterate faster on demo projects/starter projects if they weren't packaged inside armstrong.cli.

After implementing this you'd be able to do: armstrong init --template=jrhacker/demo foo which would do a git clone of git://github.com/jrhacker/demo.git or possibly git://github.com/jrhacker/armstrong.templates.demo.git and run the same processes that we do now (running the template engine over files listed in the manifest).

We can maintain backwards compatibility by assuming the user is armstrong if the template variable doesn't have a slash character.

Tastypie calls filter on querysets. arm_wells's GenericForeignKeyQuerySet doesn't have a filter method. We have options:

1. Find a way to get tastypie to avoid calling filter.
2. If tastypie passes no arguments to filter when the request doesn't require filtering, add a filter method to GenericForeignKeyQuerySet that returns self if the arguments are empty and raises an exception otherwise.
3. If tastypie is passing arguments to filter, things get more complicated. Perhaps an argument to the queryset constructor that makes filter return self regardless to avoid errors?

Typing anything in the search box then pressing Tab will select the gibberish as the facet. It shouldn't be selected, and ideally there'd be some visual feedback (red flash?) that the input was incorrect.

On a post on the django-developers mailing list, Carl Meyer wrote:

Currently, startapp always creates the new app inside the "project directory", currently defined as "the directory where the settings module lives" (and found via a combination of baling wire and ugly hackery).

My preference, however, and what I've implemented in my preferred patch [2], is to change startapp so that it always creates the app in the current directory, rather than jumping through hoops to find the "project directory".

armstrong startapp seems to follow this behavior, as new applications are created inside the settings subdirectory of the project. Regardless of whether Django decides to create new applications within the project directory, I think it makes sense for Armstrong to do so.

Currently if you try to run the tests for Armstrong projects that have a _support app, they fail. This is a false failure. All tests do pass in isolation, but these tests fail because of a lack of their <name>_support app being installed.

Apps in the current 11.09.0 release that are effected:

• armstrong.core.arm_access
• armstrong.core.arm_content
• armstrong.core.arm_layout
• armstrong.core.arm_sections.
• armstrong.core.arm_wells
• armstrong.apps.related_content

armstrong.apps.images fails for a different reason, and it's something I'm (@tswicegood) looking into.

Using https://github.com/agiliq/merchant

Caused by the assumption that there's always a STATIC_URL setting. Just needs to do some type checking. It should raise an improperly configured exception/error.

Environment:


Request Method: GET
Request URL: http://localhost:8000/

Django Version: 1.3.1
Python Version: 2.7.1
Installed Applications:
('django.contrib.contenttypes',
 'armstrong.core.arm_access',
 'armstrong.core.arm_sections',
 'armstrong.core.arm_wells',
 'armstrong.core.arm_wells.tests.arm_wells_support',
 'armstrong.apps.articles',
 'armstrong.apps.content',
 'south')
Installed Middleware:
('django.middleware.common.CommonMiddleware',
 'django.contrib.sessions.middleware.SessionMiddleware',
 'django.middleware.csrf.CsrfViewMiddleware',
 'django.contrib.auth.middleware.AuthenticationMiddleware',
 'django.contrib.messages.middleware.MessageMiddleware')


Traceback:
File "/Users/tswicegood/.virtualenvs/armstrong/lib/python2.7/site-packages/django/core/handlers/base.py" in get_response
  101.                             request.path_info)
File "/Users/tswicegood/.virtualenvs/armstrong/lib/python2.7/site-packages/django/core/urlresolvers.py" in resolve
  250.             for pattern in self.url_patterns:
File "/Users/tswicegood/.virtualenvs/armstrong/lib/python2.7/site-packages/django/core/urlresolvers.py" in _get_url_patterns
  279.         patterns = getattr(self.urlconf_module, "urlpatterns", self.urlconf_module)
File "/Users/tswicegood/.virtualenvs/armstrong/lib/python2.7/site-packages/django/core/urlresolvers.py" in _get_urlconf_module
  274.             self._urlconf_module = import_module(self.urlconf_name)
File "/Users/tswicegood/.virtualenvs/armstrong/lib/python2.7/site-packages/django/utils/importlib.py" in import_module
  35.     __import__(name)
File "/Users/tswicegood/.virtualenvs/armstrong/lib/python2.7/site-packages/armstrong/core/arm_wells/tests/arm_wells_support/urls.py" in <module>
  3. from armstrong import hatband as admin
File "/Users/tswicegood/.virtualenvs/armstrong/lib/python2.7/site-packages/armstrong/hatband/__init__.py" in <module>
  9. from .options import ModelAdmin, StackedInline, TabularInline
File "/Users/tswicegood/.virtualenvs/armstrong/lib/python2.7/site-packages/armstrong/hatband/options.py" in <module>
  5. from . import forms
File "/Users/tswicegood/.virtualenvs/armstrong/lib/python2.7/site-packages/armstrong/hatband/forms.py" in <module>
  4. from . import widgets
File "/Users/tswicegood/.virtualenvs/armstrong/lib/python2.7/site-packages/armstrong/hatband/widgets/__init__.py" in <module>
  6. from .ckeditor import CKEditorWidget
File "/Users/tswicegood/.virtualenvs/armstrong/lib/python2.7/site-packages/armstrong/hatband/widgets/ckeditor.py" in <module>
  5. class CKEditorWidget(widgets.Textarea):
File "/Users/tswicegood/.virtualenvs/armstrong/lib/python2.7/site-packages/armstrong/hatband/widgets/ckeditor.py" in CKEditorWidget
  7.     class Media:
File "/Users/tswicegood/.virtualenvs/armstrong/lib/python2.7/site-packages/armstrong/hatband/widgets/ckeditor.py" in Media
  8.         js = (''.join((settings.STATIC_URL, "ckeditor/ckeditor.js")),)

Exception Type: TypeError at /
Exception Value: sequence item 0: expected string, NoneType found

Select a facet, type garbage, hit enter.

The standard template needs to show off how to use the paywall to restrict content.

Hello developers!

I've tried to install Armstrong multiple times in a separate and clean virtualenv and I always get the same error:

Caught TypeError while rendering: init() keywords must be strings

Not sure what's going on. Seems to be a a custom tag error, but I could not debug it.

Here's the full traceback:
http://dpaste.com/628463/

Thanks!

Rodrigo Landerdahl

Would be awesome to support their API. More info at their website. Nobody's using it just yet, but no one will if we don't support it. :-)

Looks like work is already started on this:
https://github.com/Jbonnett/armstrong.apps.crm.backends.salesforce

Simply adding issue to keep track.

It's a good idea to show using Django's built in comments app inside the demo project. It's easy enough for people to switch out to other commenting systems if they want, but having comments baked in would be a good start.

See website for more information about format.

This needs to happen so we don't generate random errors with the old demo.

There's no reason to use Django's server. armstrong runserver could just as easily use Gunicorn or something else. @tswicegood got a local copy working relatively easily, but we need to address possible issues with people not wanting to/having the ability to install things such as Gunicorn.

ImageSet images are orderable and the admin interface would be greatly improved if you could use drag and drop ordering like with Arm Wells.

I'd like the ability to use the sugar that comes with the {% include %} tag with {% render_model %}.

Current use case is I've got a layout with an image, and I'd like to pass in an optional width for the layout to use. The 'ole workaround is just use the with tag around the block. I really just care about getting with but if we're going to add that we might as well add only to make it match up with include.

Questions:
Is this something you see as useful? Did we want to reserve additional parameters to render_model for something else? These are the questions that keep me up at night.

Current Include Tag Syntax:
https://docs.djangoproject.com/en/dev/ref/templates/builtins/#std:templatetag-include
Current Include Tag Source:
https://github.com/django/django/blob/master/django/template/loader_tags.py#L219

Currently, models that inherit from Section still have a parent foreign key to Section, resulting in type mismatches when retrieving trees of sections.

Possibly extract the fields from Section into a BaseSection abstract model.

Currently the bulk of the time spent running tests in a CI environment is spent installing stuff. Because we use Fabric we end up having to install a bunch of crypto stuff which requires real compiles.

The choice to use Fabric as the test runner was done before we had the armstrong.cli project. At this point it's probably worth adding a command to run tests through that and removing Fabric as a dependency.

We currently have two sets of dependencies: a few apps say they want 1.3.3, while others want 1.4. We need to upgrade all of them so they're on the same version.

Side benefit, the tests for reversion 1.3.3 currently don't pass in an Armstrong project.

https://gist.github.com/c363c0c34a76b8308f2b

Thats the error from alerts but any of the fab tests that use the VirtualDjango facility have the same problem.

Well nodes aren't saved in the django-reversion history of a well.

Sections currently have a tree_id field that determines their order, but there isn't currently a user-friendly way to reorder them, like django-mptt's FeinCMSModelAdmin.

No reason to do a pip install --no-dep . when testing, should install any dependencies.

We can pretty easily create some crypto-gibberish and add it via the template system. That would be better than assigning ''

Need to setup the site, make sure the dns is pointed to GH, and rough in the first pass at the docs.

If you have a Story type, for instance, load a new add well form, focus the search box, then type st<tab>. "ST:" will be your selected facet.

Consider a well with two Story nodes, both of which refer to the same Story. In GenericForeignKeyQuerySet._prep(), ordering will end up with a value like {u'story.28461': 1}, which has a length of one, while model_data.["objects_ids"] will be something like [u'28461', u'28461'], which has a length of two. This makes the loop over node_content raise an IndexError.

Traceback (most recent call last):

 File "/home/virtualenvs/texastribune/src/django/django/core/handlers/base.py", line 111, in get_response
   response = callback(request, *callback_args, **callback_kwargs)

 File "/home/webapps/texastribune/content/utils.py", line 45, in wrapped
   context_info = func(request, *args, **kwargs)

 File "/home/webapps/texastribune/content/utils.py", line 109, in wrapped
   context_info = func(request, *args, **kwargs)

 File "/home/webapps/texastribune/content/multimedia/views.py", line 32, in main
   slideshows = get_well_content(MULTIMEDIA_SLIDESHOWS)[:2]

 File "/home/virtualenvs/texastribune/lib/python2.6/site-packages/armstrong/core/arm_wells/querysets.py", line 9, in wrapper
   args[0]._prep()

 File "/home/virtualenvs/texastribune/lib/python2.6/site-packages/armstrong/core/arm_wells/querysets.py", line 127, in _prep
   self.content[idx] = obj

IndexError: list assignment index out of range

Tribune folks, see http://www.texastribune.org/sentry/group/314093.

StopIteration raised within a template tag is caught by Django, which raises a TemplateSyntaxError. This makes render_iter's StopIteration handling useless. This also means any tag that calls iterator.next() (i.e. render_next and render_remainder, the latter of which already does) needs to handle StopIteration.

armstrong.core.arm_sections.models.Section uses the default Django SlugField to represent its slug. This slug's default max_length is only 50 characters.

This can lead to issues when importing from external databases. WordPress' section slugs have a maximum length of 200 characters, which can cause errors.

The settings.defaults module should have a one-liner that can be commented out that allows auto-discovering all "apps" inside the <project>/apps/ directory. Something like:

INSTALLED_APPS += settings.helpers.auto_discover_apps()

This would be a good time to move the settings.project_dir function into a settings.helpers module as well.

It would be nice to have some sort of soft constraints on what can be in a well. For example here at the bay citizen we have our right rails which we are re-implementing in Armstrong Wells. We have 3 ads that should be in certain positions of every right rail well, unless there is a VERY good reason for them not to be. Some sort of popup or warning, would help us enforce the biz constraints of having ads while still letting editorial folks change things in the right rail as they see fit.

Perhaps this could be implemented such that you would set up Well Templates and for each slot in the template you could set wither a type mismatch would raise a warning or a error.

For instance, PIL requires additional development packages (sudo aptitude build-dep python-imaging) to be present at build time to be useful.

Got a few reports of this at DjangoCon last week. Needs a bit more investigation.

The $.getJSON() call in hatband/static/generickey.js initVisualSearch.valueMatches() is hard-coded to use '/admin/'. This should somehow detect (or be given) the actual base URL to use.

On the Django side the URL routing works fine.
Say the route is setup in urls.py like:

(r'^different_admin/',                      include(admin.site.urls)),

Doing this gives the correct result:

>>> reverse("admin:articles_article_search", args=("articles", "article"))
'/different_admin/articles/article/search/'

See armstrong/armstrong.core.arm_wells@acdfb8c#L0R18

hatband's generic_key_modelsearch will sometimes pollute a ModelAdmin's change_list_template on multi-threaded servers. It should instead create a new instance of the model admin or do some othe rmethod to not leave the ModelAdmin in a bad state.

One of the issues we kicked down the road for our 11.09 release was shipping default urls on a per app basis. Since we make no assumptions about implementors' url schemes, we have a less than great implementation for get_absolute_url in armstrong.core.arm_content that calls out to a function in the user's ROOT_URLCONF called get_url_for_model. That function will end up being a giant switch statement for any large site.

We've always wanted to move to a backend based model that allows implementors to choose from different url patterns (eg '/2011/3/2/article_slug' vs. '/primary_section/child_section/article_id' or whatever).

A backend would be a module that defines the following:

• urlpatterns - A standard url patterns that can be included
• get_url_for_model(model) - takes in an object and returns the result of a reverse call
• models - a tuple of tuples, each tuple is ('app', 'model') that defines what models the get_url_for_model function knows how to handle

In the site's settings would be a setting like::

ARMSTRONG_URL_BACKENDS = [
    "armstrong.core.arm_sections.urls.slug_based",
    "armstrong.apps.articles.urls.date_based",
]

And in the urls::

url(r'^sections/', include(armstrong.core.arm_sections.urls)),

Inside the urlconf for an armstrong app would be roughly the following::

from armstrong.conf.urls import configurable_urls
urlpatterns = configurable_urls(__name__)

The configurable_urls function would iterate through the ARMSTRONG_URLS_BACKENDS, looking for one that is defined for the app that matches __name__ and would then return the urlpatterns for that module

All armstrong models will similarly delegate their get_absolute_url function to get_url_for_model from the new armstrong.conf.urls module. That function will iterate through the ARMSTRONG_URLS_BACKENDS looking for one that supports the model that is being reversed and then call it.

I created a new Armstrong project with armstrong init and armstrong syncdb. Upon running armstrong runserver, I received the "Welcome to Armstrong" page, but /admin/ brought up an Site.DoesNotExist error. This was fixed by manually creating a Site through armstrong shell, but I see how this could seriously confuse newcomers to Armstrong.

I think that this could be fixed by updating armstrong init to automatically create a default Site so that the admin section will properly work immediately after a new project is created.