wq / wq.db Goto Github PK

#65 introduces default behaviour when filtering attachments with a type filter: an empty context will result in the filter fields being filtered against None, which would usually result in an empty set of attachments (this could be made more robust).

The filter will fail if there is a populated context, but there is a miss on one or more of the type filter fields. In particular, the computed filter will be {'fieldname' : ''}, which raises an error if the field type is not in fact a string.

If I'm reading correctly, the behaviour consistent with wq.app would be to return an empty set of attachments in all such cases.

The latest version of DRF handles boolean values more robustly, but it breaks some things with how checkboxes worked before (e.g. the <input> needs to have value="t" instead of just "on"). Also, unchecking a box on an existing record doesn't necessarily cause an update to False (since the field is omitted entirely). Need a better way of handling checkbox values (here and/or in wq.app).

The multiple interwoven use cases are getting a bit out of hand. Probably should break down and have multiple serializers for each case:

• Detail view (retrieve/update)
• List view (list)
• List view post (create)
• GeoJSON versions?

Perhaps the view should then have more specific functions like get_serializer_for_update?

Edit: The biggest issue is really the excessive magic for generating nested serializers. Instead of detail/list/etc. serializers, this can be cleaned up simply by creating explicit, custom serializers whenever a nested serializer is needed. This will likely affect the external API so is a good candidate for 0.8. See #34.

Due to code in the ModelPermissions class.

It's time to integrate a testing framework.

djangorestframework==3.8.2

 File "/srv/venv/lib64/python3.6/site-packages/wq/db/rest/__init__.py", line 2, in <module>
    from .routers import ModelRouter, router
  File "/srv/venv/lib64/python3.6/site-packages/wq/db/rest/routers.py", line 560, in <module>
    router = ModelRouter()
  File "/srv/venv/lib64/python3.6/site-packages/wq/db/rest/routers.py", line 49, in __init__
    initkwargs={'suffix': 'List'}
TypeError: __new__() missing 1 required positional argument: 'detail'

wq.db.rest.app.router assumes that there is only one model with a given name (as it doesn't include the app label when differentiating models). For example, if vera.Site is registered, sites.Site should not be. Should at least provide a warning when the user registers two models with the same name. Another option would be to provide a custom name for the model when registering it.

It's rarely used and not tested. The wq.db.rest interface is more robust and the preferred route - it just needs some templates.

Update to Django REST Framework 3.0.

The TypedAttachmentListSerializer class currently defines default attachments to call get_lookup_choices with an empty context:

def default_attachments(self, initial):
    """ """
    types = self.child.get_lookup_choices(type_field, {})

The empty context is passed through to compute_filter unchanged, so it does not filter on query string parameters (or anything else) as I believe it is intended to.

Registering patterns attachment models by default means that they are downloaded separately by wq.app, and it's not easy to ensure the right attachments are downloaded (e.g. the first 50 "identifiers" may or may not correspond to the first 50 "mymodels"). When saving, wq.app extracts attachments from saved models and stores them in their separate list. However, it's much more common to only need to load attachments together with their parent models, and there isn't usually a need to reference attachments as a distinct list.

As of wq.db 0.8.2, the Location model is no longer registered by default and is always referenced with respect to a parent model (though locate is already a special case).

This change would likely mean including attachments even in list views (since list views are what wq.app uses to cache JSON data). We'd also need to document how to re-enable the current behavior and deal with the caveats.

While the creation of new model instances for an AnnotatedModel functions properly via POST request, when attempting to save via a PUT request, the server returns the following Error:

'GenericRelatedObjectManager' object is not iterable

Associated annotations for the annotated model are included in the PUT request.

Replace the current naming convention with a more standard and flexible format based on the HTML JSON Forms spec. For example,

<input name="annotation-123-value" value="Example">

will become

<input name="annotations[0][value]" value="Example">
<input name="annotations[0][type_id]" value="123">

Support for HTML JSON Forms is being implemented in DRF core: see encode/django-rest-framework#2148 and encode/django-rest-framework#2682.

Support the new split social modules created in python-social-auth 0.3.0.

Preferably set by default and/or synced with config.

After going through the installation procedure here:
https://wq.io/docs/setup

using ubuntu 14.04

TypeError at /
init() missing 1 required positional argument: 'engine'
Request Method: GET
Request URL:
Django Version: 1.8.2
Exception Type: TypeError
Exception Value:
init() missing 1 required positional argument: 'engine'
Exception Location: /usr/local/lib/python3.4/dist-packages/wq/db/rest/template.py in get_template_source, line 9
Python Executable: /usr/bin/python3
Python Version: 3.4.0
Python Path:
['/home/wq/proj/da/db',
'/usr/lib/python3.4',
'/usr/lib/python3.4/plat-x86_64-linux-gnu',
'/usr/lib/python3.4/lib-dynload',
'/usr/local/lib/python3.4/dist-packages',
'/usr/lib/python3/dist-packages']
Server time: Mon, 25 May 2015 16:10:39 +0000

Probably using an existing third-party DRF extension.

wq.db 0.7 will add support for Django 1.7 and drop support for Django 1.5. To keep the codebase clean, wq.db 0.8 should probably drop support for 1.6.

This would include:

• Removing remaining references to south
• Removing other compatibility hacks (field.clone()?)

The serverside template renderer expects annotations, but the client side expects the custom type.

Add a debug entry to the router-generated config object indicating the state of settings.DEBUG. Could use router.set_extra_config for this (see wq/wq#15) though will need to make sure it's always set. This will be used by wq.app for various build settings - see wq/wq.app#45

Like Django admin does now. (Also need to update docs & template)

My serializer should calculate some values which depend on the user's account.

I subclassed ModelSerializer (from wq), and can't find a way to reliably determine the request in the constructor (to prepare information for to_representation method to use for every serialized instance).

According to https://stackoverflow.com/a/34617511/1762343, the request should be in self.context dict, but I can only (sometimes) find 'router': <wq.db.rest.routers.ModelRouter> there.

Survey(models.Model):
    date = models.DateField()
    valid_survey = models.BooleanField()

For such a model ./manage.py dump_config outputs string as the type of valid_survey:

            "form": [
                {
                    "name": "date",
                    "bind": {
                        "required": true
                    },
                    "type": "date",
                    "label": "Date"
                },
                {
                    "name": "valid_survey",
                    "type": "string",
                    "label": "Valid Survey"
                }
            ]

Consequently, wq maketemplates renders it as a simple text input which is not a best option.
If these two (Null)BooleanField field types were treated as type "select one", they would hopefully be rendered as choice buttons by wq maketemplates.

Foreign keys are serialized as (field)_id, but when saving a model, the field name must be sent without the id suffix. Among other things, this makes form rendering a bit awkward (<input name=field value={{field_id}}>). The best approach is probably to standardize on field_id, and figure out how to remove the field_from_native / field_to_native hacks in IDRelatedField.

While a file field is required, the form requires a new file and does not allow leaving the existing one in place. Should perhaps allow fields like Django's form to leave or remove existing file separate from uploading a new one.
(edit: When the file field is optional, it's possible to submit the form without a new file; the existing file stays in place and there is no way to remove it.)

If any of the auto-generated _label (or _id) fields are explicitly declared on the model, don't override them.

As of Django 1.9, admin.site.urls no longer needs to be wrapped in include(), but removing the wrapper from rest.router.urls causes an error. See Soil-Carbon-Coalition/atlasbiowork#1.

One of the least intrusive ways to extend the Django's User model is to create a separate model with OneToOne relation to the User model, that contains additional fields about the user (e.g. the company he belongs to).
It would be useful if the serializer could include that information at /login.json.
One solution would be to provide a configuration option "EXPOSE_USER_PROFILE_CLASSES" and use it to add related OneToOne objects recursively (e.g. to access user.profile.company.name).

When creating a new page with add_page, I would have expected to be able to set context variables directly for both the server-side and the config.json. Currently, creating a view as a third parameter is the only way to pass a context variable through.

It would be really handy to be able to pass variables directly through to both the config.json and the "page_name".json.

Thanks!

In favor of general optimization techniques and wq/django-rest-pandas#4

Due to how the serializer interprets is_detail when running get_wq_config()

Which was removed from DRF core.

There is an inconsistency of client- and server-side validation for CharField fields with blank=True.
The generated templates accept such an object, but the synchronization fails. The outbox synchronization process sends these fields as "", but the server responds with "400 Bad Request" with a JSON structure containing "This field may not be null." messages.

This would read settings.AUTHENTICATION_BACKENDS, and generate an array suitable for use in e.g. login.html.

When accessing an e.g. annotation detail view, the parent content object is not available by default.

This will require some sort of "pattern registration" api which will have a nice side effect of making it easier to register custom patterns with the rest api. It will also open up the possibility of spinning off more of the built-in patterns into separate libraries.

• Move the thumbnail generator in files.views / files.util to a separate PyPI package
• Make dbio a separate PyPI package (eventually) supporting arbitrary models; fully independent of vera (and possibly independent of wq.db, like django-rest-pandas is)
  • Edit: dbio relies on the identify pattern so it will still need to depend on wq.db.
• Move vera code to the existing PyPI package
• Probably leave chart, search and the rest of files as the remaining contrib apps.
  • Edit: Chart is dependent on vera though... fix this

I am trying to override one of the admin templates for a django app build with wq (the species tracker example app). When I add the directory to the template I am using to override the admin template, like this:

TEMPLATE_DIRS = (
    os.path.join(BASE_DIR, 'templates'),
    os.path.join(BASE_DIR, 'db/dictionary/templates'),
)

I get this error: 'Template' object has no attribute 'nodelist'

But this works:

# TEMPLATE_DIRS = (
#     os.path.join(BASE_DIR, 'templates'),
#     # os.path.join(BASE_DIR, 'db/dictionary/templates'),
# )
TEMPLATES = [
    {
        'BACKEND': 'django.template.backends.django.DjangoTemplates',
        'DIRS': [
                 os.path.join(BASE_DIR, 'db/dictionary/templates'),
                 ],
        'APP_DIRS': True,
        'OPTIONS': {
            'context_processors': [
                'django.template.context_processors.debug',
                'django.template.context_processors.request',
                'django.contrib.auth.context_processors.auth',
                'django.contrib.messages.context_processors.messages',
            ],
            # 'loaders': [
            #     'django.template.loaders.filesystem.Loader',
            #     'django.template.loaders.app_directories.Loader',
            # ]
        },
    },

]

But in the second case, none of wq's templates render.

In django's documentation, they show how you can use multiple template backends for different folders of templates:

TEMPLATES = [
    {
        'BACKEND': 'django.template.backends.django.DjangoTemplates',
        'DIRS': [
            '/home/html/example.com',
            '/home/html/default',
        ],
    },
    {
        'BACKEND': 'django.template.backends.jinja2.Jinja2',
        'DIRS': [
            '/home/html/jinja2',
        ],
    },
]

I tried something similar, but I don't know what to put in the 'BACKEND' directive for the wq templates.

What can I do differently to override the admin template using the default template backend without interfering with wq's template rendering?

Currently, wq.db.rest.app.autodiscover() searches for myapp.views (and myapp.serializers) to ensure registration methods are called. The choice of views makes some sense as much of the view logic is handled automatically by the router. However, it makes things a bit messy whenever one needs to actually define custom views. It would probably be best to recommend a separate namespace for registration: myapp.rest, myapp.app, or myapp.routes being some possibilities.

Incorporate some kind of registration mechanism. Would need to differentiate between attachments and parent models.

wq/app.js automatically includes the actual page configuration in the template rendering context for list and detail views (See source). However, ModelViewSet does not do the same, which causes subtle rendering differences between server and client if template authors are relying on the app.js feature. (Related to #5, #6, #7).

And document natural keys (the concept) as well as the library.

Even if they aren't installed. This is usually only an issue when trying to remove obsolete contenttypes.

Per Django's guidelines, this means we can also drop support for 1.8 and 1.10.

• Limit travis, setup.py, and README to Django 1.11 and 2.0
• Fix any failing tests
• Review entire code to remove any remaining backwards compatibility hacks