Asset creation workflow

[sixpearls]

I've been thinking about this, and I think there's something worth discussion. As I see it, there are 4 types of wagtail related models:

1. Page subclasses, which are any distinct website page (it has a URL).
2. Snippet-registered models, which are attached to a page
3. And helper models (eg, M2M through models) which don't have their own admin area--they show up as inlines or not at all
4. Assets, which are used within fields on a page (currently ships with Images, Documents, Embeds. Redirects seem similar, but perhaps another category)

So far, #s 1-3 are beautiful and joyous to work with as both a developer and user. In contrast, support for creating new assets is completely absent. The only asset I know I would want to add is a gallery (collection of images, with over-writable/selectable embed templates). I could copy and paste a bunch of the wagtailimage and wagtaildocs code, but I think it would behoove the project to simplify the process for developers. The shipped assets should be re-factored to take advantage of the new developer tools. This was already started in the move to allow hallo plugins (1ecc215759142e6cafdacb185bbfd3f8e9cd3185), and I think the project should keep moving in that direction.

[tomdyson]

Thanks for the feedback, @sixpearls. We're not totally clear what you mean - would you mind clarifying with a fuller example of the workflow you have in mind?

[tomdyson]

P.S. I've change the issue title so we can reference it more easily.

[sixpearls]

Essentially, it would be nice to be able to add a model to wagtail's admin with a similar ease to customizing django's admin. As a developer, I want to take my non-Page-subclass model, define my panels and register my model to have the model added to the admin. I should also be able define an optional small set of paremeters so to plug into hallo.js.

It may make sense to spin out the code needed to do this to a separate (contrib) app. In my notes, I've been calling it snapin as a play on snippet and because it allows models to snap into the admin interface. The admin would need to be refactored a bit to allow for it, even if these features were spun out as a separate app.

That asset development workflow would need to appropriate MetaClass's and inheritable models/forms to automatically generate the appropriate url/view combos. The templates (including CSS) would need to be abstracted, as well. I think some of this work may be started in @kaedroho's move to class based views mentioned in #237.

Is that any clearer? I would be glad to work on this, but I would like to fit it with the project's roadmap. Thanks.

[akrawchyk]

I'm interested in this as well. Seems like an overarching theme of "Media" is related to assets. We have DocumentChooser, ImageChooser etc, but no EmbedChooser. I'd like to easily be able to create a collection of different media types related to a Page.

For example, a media gallery for events would have Images and Embeds. I attempted to solve this by creating EventPageRelatedImages and EventPageRelatedEmbeds models with ForeignKeys to the EventPage. Then, I was planning on making a property on the EventPage that returns a zip of all related Images and Embeds. However, I realized this was wrong since there is no EmbedChooser field.

[gasman]

@akrawchyk There's no EmbedChooser because an embed is essentially just a URL to an external site such as Youtube, which is turned into a chunk of HTML by the embed template filter. (The Embed model should be thought of as a cache for these HTML chunks, rather than a list to choose from in the same way that you would choose an image). Your EventPageRelatedEmbeds model would therefore just consist of a text field to enter the URL into.

It sounds like what you're asking for is for the Embed model to become a first-class citizen like Image and Document, and allow users to create a library of videos (or whatever else) within Wagtail that can then be picked from a list in order to add them to a page, rather than just entering a Youtube URL on the spot. That could be a neat addition to Wagtail, but I'm not sure that it would save any work unless you find yourself embedding the same video over and over again on different pages. But perhaps there's a use-case I've not thought of!

[gasman]

@sixpearls Sorry for the delay in responding! I'm not really clear on how your 'snapin' concept differs from snippets - your description of "take my non-Page-subclass model, define my panels and register my model to have the model added to the admin" sounds exactly like a snippet to me. Is it just about giving the model its own top-level item in the admin menu?

[sixpearls]

@gasman No problem about the delay. I've been away from web development work, so I've been quiet. Don't think I'm any less a fan of this project!

The difference between snippet and 'snapin' is that the latter creates what you describe as a "first-class citizen." In my mind key features are to make it easy to add: (1) a main admin menu item (2) dedicated chooser/button in the RichTextField, (3) the necessary white-listing and db expansion/compression* to support (2), and (4) a custom ForeignKey chooser. I would also love it if Image, Document, and Embed, were re-factored to use the same system to remove their "special-ness"-- in my utopian (distopian?) future, all assets are equal.

I haven't been paying close attention, but it looks like there's already work being done on a lot of these features. From what I saw, it didn't look like a concerted effort for the sake of systematically adding these assets, but enough support may have been added to do what I want to do (e.g., create a "gallery" asset).

Does that clear it up?

*In my notes, I have a comment about the whitelister, embedhandler, and something about an expander (I believe db->template and db->editor). I'm not sure what it currently looks like, as I wrote those notes "way back" around 0.3.

[davecranwell]

Is there any way we can move this ticket on or is it just a case of closing it in favour of #634?

[gasman]

634 doesn't really supersede this ticket - it's just a spinoff from the comment about embed choosers, which (if I'm not mistaken) was only tangentially related to @sixpearls's original suggestion.

StreamField (#823) will address the issue of including references to arbitrary models within richtext/mixed content, without the need to jump through whitelisting/expansion hoops - we'd do that by making the snippet chooser one of our fundamental block types. At that point, I think the only thing remaining on this ticket would be the question of whether snippet models are "first-class" enough, or whether we ought to do more to support custom model types that live at the top-level menu.

While I won't promise that StreamField will be the magic bullet that solves everything, I think it'll make it much clearer to see what further work needs to be done here - so in the interests of un-clogging the backlog of tickets, I'll close this one with the intention of possibly opening new ones post-StreamField.

[sixpearls]

This issue is actually essentially proposing the same thing as #891 (with the sample refactoring of #890) and is closely related to #634, #858.

The basic idea was to make it clear how to take an arbitrary model "asset", and (1) add CRUD pages to the admin and (2) add a good chooser interface for every type of field it might be useful (ForeignKeys and ManyToMany relationships, the richtextfield interface, and now the StreamField interface). Bonus points if the current Image, Document, and Embed assets were re-factored to use the new workflow.

So between the above identified issues, every aspect is being covered. I guess at this point the only value this issue has is in pointing out how the new features are related. Since that's done, by all means keep this one closed!