https://htmx.org logo
Powered by
# htmx-general
  • f
    So ... I'm writing a sort of server-side framework, which is (at the top level) a data-flow model. The blocks in the data flow model are Python programs, and these Python programs can create web resources (HTML, CSS, JS, images or whatever) and send them to one or more webservers (which are also top-level blocks in the data flow model), which mostly act as dumb caches for the web resources, but can also do some very simple, very generic logic, such as issuing SSE notifications when particular resources change (through a very primitive sort of pub-sub), forwarding user interactions to other, downstream components, and executing small callbacks.... That's the context.
  • m
    @User that looks reasonable, but I'd say we should just trigger the event on the element every time, maybe w/ a namepsace
  • m
    something like 
    htmx:sse:<eventName>
  • m
    I don't think you need to special case it
  • f
    But I also don't want the content swapped in....
  • m
    Ah, OK. Let me look at it some more.
  • f
    Let me give the rationale.
  • f
    So ... I've got a dashboard builder.
  • f
    The dashboard components themselves can be dynamically added, removed and modified.
  • f
    For this, sse:swap is perfect.
  • f
    But I also want the dashboard components to display oscilloscope-like graphs...
  • f
    And for the data for the graph to come over as JSON, so I can use D3.js to do the plotting.
  • f
    So I have some situations where I want to do things the HTMX way ... and have a bit of HTML swapping in.
  • f
    And other situations where I want to do things differently, and have JSON coming in over SSE and being used to update a chart or other visualization with D3.js...
  • f
    So I need to be able to say 'do something with the content of this SSE event ... but don't swap it into the DOM'
  • l
    @mysterious-toddler-20573 So, if I ripped out dispatch by attribute name, if someone wants a different serialization, they'd have to make their own server-side object types (and not use regular Dictinoary, Vector, etc.)
  • l
    One other question.... while I've got brains. mbostock's conversion converts 
    camelCase
    to 
    kebab-case
    , however, this doesn't work for SVG attributes. This means I'd have to scan the content to grok namespace and then make serialization of attribute names be based upon namespace. My colleague Kyrylo suggested that I should be stupider. 
    camelCase
    stays 
    camelCase
    but 
    snake_case
    becomes 
    kebab-case
    . So, people using HTML would have to write 
    hx_swap
    in Julia and not 
    hxSwap
    .
  • l
    This would once again be "consistent" over "clever". @User sound about right?
  • f
    This seems sort of like the approach used by dominate ... which tries to do something similar ... I think.
  • m
    @User that sounds reasonable to me
  • l
    Awesome.
  • f
    I'm still looking at HypertextLiteral.jl and trying to grok it.
  • f
    Copy code
    @staticmethod
  def clean_attribute(attribute):
    '''
    Normalize attribute names for shorthand and work arounds for limitations
    in Python's syntax
    '''

    # Shorthand
    attribute = {
      'cls': 'class',
      'className': 'class',
      'class_name': 'class',
      'fr': 'for',
      'html_for': 'for',
      'htmlFor': 'for',
    }.get(attribute, attribute)

    # Workaround for Python's reserved words
    if attribute[0] == '_':
      attribute = attribute[1:]

    # Workaround for dash
    special_prefix = any([attribute.startswith(x) for x in ('data_', 'aria_')])
    if attribute in set(['http_equiv']) or special_prefix:
      attribute = attribute.replace('_', '-').lower()

    # Workaround for colon
    if attribute.split('_')[0] in ('xlink', 'xml', 'xmlns'):
      attribute = attribute.replace('_', ':', 1).lower()

    return attribute
  • f
    I think this is the relevant bit of the dominate codebase...
  • f
  • m
    @User OK, I see what you are doing now
  • m
    I have a few suggestions I'll make in the PR
  • f
    Also, I've just spotted that I rebased against the dev branch instead of master ...
  • f
    So there's some spurious accidental commits in the PR.
  • m
    yep
1...949596...1146Latest