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.

Sign up for GitHub

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

Jump to bottom

Document structure #214

Open
bcardarella opened this issue Dec 11, 2024 · 3 comments
Open

Document structure #214

bcardarella opened this issue Dec 11, 2024 · 3 comments

Comments

@bcardarella
Copy link
Contributor

To date we've had a flat document with multiple "root" nodes. We should instead enforce a document structure with a single root node, a Head node and a Body node. The Head should allow for Section node that is intended for various states that can override client states. For example, in the SwiftUI client we have disconnected, reconnecting, and error state views. These views are defined on the client. These have allowed for a native client-side views to be used when server is unavailable (disconnected), in-flight (reconnecting), or when an error happens (error). However, you may want to redefine override these from the server. The server's dead render Head node could include overrides for each:

NML -> Native Markup Language. I do think maybe this would justify a rename of the sigil_LVN to sigil_NML:

~NML"""
<Text>Hi!</Text>
"""
<NML>
  <Head>
    <Style url="..."/>
    <Section template="disconnected">
      ...
    </Section>
     <Section template="reconnecting">
      ...
    </Section>
    <Section template="error">
      ...
    </Section>
  </Head>
  <Body>
  </Body>
</NML>

we can include helpers to delegate each section to it's own external template file:

<NML>
  <Head>
    <Style url="..."/>
    {section(:disconnected)}
    {section(:reconnecting)}
    {section(:error)}
  </Head>
  <Body>
  </Body>
</NML>

I would prefer to use {@error_content} but off the top of my head I'm not sure if that is possible so I'll investigate.
@carson-katri
Copy link
Contributor

Could the root element be <LVN>? And do we need a root element? It doesn't have any attributes, so it seems unnecessary.

@bcardarella
Copy link
Contributor Author

@carson-katri I considered that but with my desire to eventually de-couple the client from LiveView at some point I figured it would be best to do this now. Besides, the root element in HTML is <html>. I've been considering calling our markup language "Native Markup Language"

@bcardarella
Copy link
Contributor Author

As far as the necessity of a root element, I'm not entirely sold on the necessity either. Just figured I'd include it for discussion

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@bcardarella @carson-katri