METADATA WIDGET!!!!

[sourcefilter]

The problem

• Django is very opinionated, and strongly tied to a strict relational-database model.
• Cobweb should cover a variety of use cases with different metadata needs, and we have no control over imported metadata schemas.
• Django does have a "JSONField", to support arbitrary data structures with postgres's JSON data type type. I've been using this to store all metadata beyond "title", "description", and "keywords", but there aren't good HTML widgets to support this type – you get a json, unless your write your own.</li> </ul> <h1>Potential Solutions</h1> <h2>1. Be inflexible. Force users to conform to a strict, hard-coded schema. Clearly separate the imported data, which can be stored in a JSONField but not edited.</h2> <p>To be honest, I hadn't even been considering this option. It'd be so much easier. Maybe I'm wasting a lot of energy on things that don't add that much value...</p> <h2>2. No JSONField - use a separate table of (Object, property, value) triples.</h2> <p>Pros:</p> <ul> <li>Highly normalized, makes some queries easy.</li> <li>Good Django HTML widget support via <a rel="noreferrer nofollow" target="_blank" href="https://docs.djangoproject.com/en/2.0/topics/forms/formsets/">formsets</a></li> </ul> <p>Cons:</p> <ul> <li>Unnecessary layer of complexity. It just feels wrong.</li> <li>Getting the metadata involves expensive joins. Caching / indexing has to be configured to avoid this. Even more complexity.</li> <li>Increases our dependence on a dated model of web app design, makes it harder to create a modern, javascripty feel.</li> </ul> <h2>3. Write new Django FormFields and Widgets.</h2> <p>Pros:</p> <ul> <li>Possibly the least work.</li> <li>Allows more flexible metadata storage w/o diverging too far from Django Orthodoxy (and thus maintainability).</li> <li>Make a tool nobody's made before (a decent JSON widget!), share it w/ the world.</li> </ul> <p>Cons:</p> <ul> <li>Lots of work understanding Django internals.</li> <li>Still depend on dated web app model.</li> <li>Probably there's a reason nobody's made this tool before, and ours would probably be too specific to our particular model for the JSON-formatted data to share anyway.</li> </ul> <h2>4. JavaScript option 1: make a jquery widget.</h2> <p>Pros:</p> <ul> <li>Django bit can stay simple, sending and receiving json.</li> <li>Fast, modern-feeling, javascripty experience.</li> <li>Can use good libraries like <a rel="noreferrer nofollow" target="_blank" href="https://select2.org/">Select2</a>.</li> </ul> <p>Cons:</p> <ul> <li>More complexity, with a fairly intimate connection between Python and JavaScript components.</li> <li>Still a bit dated.</li> </ul> <h2>5. Javascript option 2: make a react widget.</h2> <p>Cons:</p> <ul> <li>Steeper learning curve than jquery.</li> <li>Less suited to a single widget - that's possible, but react is really meant for building the whole app.</li> </ul> <p>Pros:</p> <ul> <li>Stepping stone to building the whole app in react, w/ many benefits: <ul> <li>People really seem to like react. Once you get over the initial unfamiliarity with its way of doing things it's supposed to be fairly fast and easy. It actually implements a few things that had already occurred to me as better ways of making web apps.</li> <li>Does all the rendering client-side, saving us server resources.</li> <li>All our backend work is still useful - we can plug in the <a rel="noreferrer nofollow" target="_blank" href="http://www.django-rest-framework.org/">Django REST Framework</a> to run our API - which I was planning to do anyway.</li> <li>Moves us toward a modern stack: NoSQL db, client-side framework, &c, each part of which has caught on for a reason. The extra learning time at least gives me something more useful than expertise in Django form internals.</li> </ul></li> </ul> <p>Cons to switching entirely to react:</p> <ul> <li>Client-side rendering interferes with search engine indexing and can slow down the initial page load (since the whole javascript app has to load first). One solution is isomorphic Javascript - basically run our react code on the server to render the first page, then hand off to the client. That's a new layer of complexity. The Django REST Framework has a <a rel="noreferrer nofollow" target="_blank" href="http://www.django-rest-framework.org/topics/browsable-api/">browsable API</a> that might be good enough for search indexing...</li> </ul> <h1>Current Status</h1> <p>I've made significant progress on #3 (a new Django widget), but am really leaning toward #1 (inflexible metadata) or #5 (switching to React). The middle ground options just don't seem to be worth the trouble.</p> <p>I've also made some progress on the react version and it seems doable, but it'd really only be worth it if we wanted to change our frontend framework to react – which is a pretty big decision.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/broadwell"><img src="https://avatars.githubusercontent.com/u/7329112?v=4" />broadwell</a> commented <strong> 6 years ago</strong> </div> <div class="markdown-body"> <p>Yeah, the BuildUCLA web team students I supervise are always agitating to burn down any existing framework we're using and replace it with a JSON bucket on the backend and whatever hotrod Javascript front-end is in vogue. Apparently this is called a "progressive" stack. I'm not against it in principle, though for this project, I think I'd prefer to get #1 working and then explore #3 or #5 if there's time.</p> </div> </div> <div class="page-bar-simple"> </div> <div class="footer"> <ul class="body"> <li>© <script> document.write(new Date().getFullYear()) </script> Githubissues.</li> <li>Githubissues is a development platform for aggregating issues.</li> </ul> </div> <script src="https://cdn.jsdelivr.net/npm/jquery@3.5.1/dist/jquery.min.js"></script> <script src="/githubissues/assets/js.js"></script> <script src="/githubissues/assets/markdown.js"></script> <script src="https://cdn.jsdelivr.net/gh/highlightjs/cdn-release@11.4.0/build/highlight.min.js"></script> <script src="https://cdn.jsdelivr.net/gh/highlightjs/cdn-release@11.4.0/build/languages/go.min.js"></script> <script> hljs.highlightAll(); </script> </body> </html>