eregsplatformthoughts.md

This is a rough outline of how I envision the plugin implementation for eRegs, sans parser. There’s plenty here that is just a starting point, and that I have not thought through fully. The main point that I want to make is that we can reuse patterns and code that we already have to give plugin writers the option to add their own content in ways that have been validated by user feedback.

I’m thinking about a first implementation, not a final vision. The idea is to rework code we have, add foundational plugin code, and document how we expect people to write a plugin and what controls they have available to them. The motivation is to be able to relatively quickly and cleanly spin up instances of eRegs, with an eye toward many agencies having instances in the future. Each agency seems to have its own specific set of documents that are important to them, and my hope is that we can identify a set of feature types that match content we have now and will meet many of the immediate needs that agencies have.

Using modules we have for the current UI, give a plugin writer the ability to:

• add a drawer tab link
• add a drawer pane
• associate supplemental content with reg
  • insert below reg text in an expandable (like the CFPB interpretations)
  • insert into the sidebar (like definitions or section by section)
• open supplemental content in the breakaway view

Maybe the plugin writer defines something like a content type and configures how it behaves - I can add a drawer pane plugin that gives me the option to add a tab link. Or I have a new reference content type that I want to bring into the expandable and contextually link to in a sidebar module.

Implementation of a feature plugin (includes the theming process):

Plugin:

• potentially stuff that goes further back in the stack that I haven't even attempted to think about.
• CM, please help
• Django view implementation
  • is it possible to live in Adam's world where an eRegs instance repo can be the theme, and in this one where, I would assume, plugin development has to happen in Django and back?

Theme:

• create template if needed
  • can we template only some things in JS? how ugly would it be to insert features defined by custom plugins, while the rest is served from django?
  • what is adam's idea here?
• JS view implementation
  • add a *-view.js to the right dir and it will be included in build
• CSS implementation
  • add a less file to the right place, build will pick up on it and include it to override core classes
  • insert takeaways from John's findings here

We would translate the conventions in place, with some polishing, into a process and documentation. As suggested above, should we rely on file naming and placement convention as the way for plugin writers to extend eRegs?

Types of things people will most want to do:

• lists of links to supplemental content
• bringing other documents into eRegs

Does narrowing this down help to give us an initial technical approach? My guess is that it does. Is there more that belongs on this list? Am I wrong about what is on this list?

What this doesn’t handle:

• overriding core functionality
• layout changes

We should do the quickest useful thing that addresses our semi-immediate needs, and ship it ASAP. We can learn from it and then take on these bigger challenges, if the need exists. We should also be sure we're not letting folks too easily create bad experiences - part of the promise of eRegs is a pleasant experience.

Shouldn't this be part of "Plugin" instead of "Theme"? While JS views will sometimes be required, I think logic should be moved out of JS wherever possible. The majority of cases should use, e.g., a shared "breakaway.js" rather than an agency-specific "section-by-section.js".

Yup, I agree. I must have not very clearly explained. JS should be part of a plugin, not a theme. I am also hoping that we can use generic views that correspond to a type of feature rather than the specific implementation. So a section by section plugin would, by virtue of somehow specifying that a sxs should open in a breakaway and have a sidebar module, use the default breakaway and sidebar module views. I was thinking about a potential future where we may need to write very different features for an agency, which would necessitate more custom code, but maybe there's not a benefit to thinking about that at this point. Does that sound better?

More to come.

ETA: I see now where this came from. I'm not sure what I was thinking, putting that under theme.

is it possible to live in Adam's world where an eRegs instance repo can be the theme, and in this one where, I would assume, plugin development has to happen in Django and back?

I don't understand this sentence.

So, here I wasn't thinking of an agency's eregs instance being a Django project, and was trying to reconcile server side changes with front end ones in that scenario. In a world where an eregs instance is a Django project and we continue use of a front end compile of some sort, this problem goes away.