Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Extract Renderable interfaces to module #619

Closed

Conversation

iachettifederico
Copy link

This PR is a Work in progress, since it's missing some tests and documentation.

  • extracted all the functionality of SGML to Renderable module
  • extracted all the functionality of HTML to HtmlRenderable module
  • extracted all the functionality of SVG to SvgRenderable module

All the tests that were on the repository are passing

@joeldrapper
Copy link
Collaborator

This is a great start! I’d quite like to separate the SGML stuff from the renderable stuff where SGML is a specific implementation of renderable that buffers SGML tags, but other objects could implement the renderable interface just by implementing call to take a buffer, view context and block and mutate the buffer before returning it.

Then the render method could just check that the object includes Renderable before calling it. Does that make sense?

@joeldrapper
Copy link
Collaborator

joeldrapper commented Jan 9, 2024

These names might not be quite right, but here's the main parts I think we should have:

  1. Renderable — a module that declares that you implement the interface where call takes a buffer, context and block and returns the (mutated) buffer;
  2. SGML — a module that implements Renderable with a buffer and the ability to dynamically define tag methods for a specific SGML language;
  3. HTMLRenderable a module that extends SGML with a specific set of tag;
  4. SVGRenderable a module that extends SGML with a different set of tags;
  5. HTML a class that includes HTMLRenderable; and
  6. SVG a class that includes SVGRenderable.

It might even make sense to have a layer between 1 and 2 that provides the buffer, context, capture, etc. without any of the SGML element macros.

@iachettifederico
Copy link
Author

3. `HTMLRenderable` a module that extends `SGML` with a specific set of tag;

4. `SVGRenderable` a module that extends `SGML` with a different set of tags;

For 3 and 4 I thought of 2 optiions:

  1. HTMLRenderable (whichi I actually wrote)
  2. HTML::Renderable

For both of those might be pros and cons. I think I like the second one best, but I'm absolutely flexible about this

@iachettifederico
Copy link
Author

@joeldrapper also, I'm working on a Linux machine and don't have a Mac. Could you help me solve failing Mac specs?

@iachettifederico iachettifederico force-pushed the extract-to-module branch 2 times, most recently from b5a4224 to 5d6b6dd Compare January 20, 2024 22:52
@joeldrapper
Copy link
Collaborator

Hey @iachettifederico, sorry this ended up going stale. I’m going to open a new PR for this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

2 participants