Loading ...
Sorry, an error occurred while loading the content.

Submode support in nXML

Expand Messages
  • drkm
    First, I don t know a lot of nXML internals, so I can say wrong things. Please be carefull while reading this, and correct the errors I do. And two
    Message 1 of 1 , Jul 29, 2004
    • 0 Attachment
      First, I don't know a lot of nXML internals, so I can say wrong
      things. Please be carefull while reading this, and correct the errors
      I do.

      And two definitions. "Submode": embedded major mode. "Submode
      region": region whose content is to be edited with a submode.

      I think a common base to all mecanisms could be a modification of
      nXML to identify submode regions. While MMM Mode (and nxml-script
      too, I think) uses regexps to identify these submode regions, nXML can
      do it more robustly, because it effectly parse the XML document. When
      nXML identify a submode region, it delegates its processing to a kind
      of hook, or a function contained in a variable.

      This has the advantage of modify only a few things in nXML itself.
      So we can deal with multiple implementations, compare tradeoffs, etc.
      And maybe effectively provide multiple implementations within the user
      may choose which he want use.

      These changes to nXML can be made with something more generic in
      mind. Something like "parse events" : "Hey, the parser, because you
      are using the XHTML schema, I'm intrested in the event 'encountering a
      script element'. So I'm setting a specific variable to a function to
      be called when you see this event. Don't forget me." But as I said,
      I don't know so much to nXML internals, so maybe I say stupidities.

      We have to provide the ability to identify submode regions by
      element names, attribute names and PI names, IMHO. By element names
      is usefull for elements like XHTML's "script" or "style". By
      attribute names is usefull for script or style embedded in attributes,
      like the XHTML's "style" or "onclick" attributes. I don't have
      concrete example about PI, but I think this is usefull, too.

      When this in place, we can consider the two ways discussed in the
      past days. I think this is quite trivial to plug MMM Mode in this
      interface. It provides a function to MMM-ify a region, which would be
      enough. The other way, that is switching explicitely to the submode,
      can be implemented, for example, by creating an overlay over the
      submode region, telling which submode to use. The switching command
      inspects the overlay, get the submode region limits, the submode, and
      do what it have to do. Other techniques can be usefull, too.

      Some points we have to consider are the deletion of the submode
      region (for example deletion of the enclosing element), and modifying
      the enclosing element's name (for example from script to anything
      else). And other points I don't think about for the moment. For the
      deletion of the submode region, I think it is automaticaly managed by
      MMM Mode, when the region become zero-length. And I think overlays
      have the same functionality. For renaming elements, the parser have
      to report the event, to let the implementation to do the right things.

      Coming back to the identification of the submode regions by nXML. I
      guess this can be placed somewhere in the validation code.
      `rng-process-attributes()', `rng-process-start-tag()' and
      `rng-process-end-tag()' may be of interest (please tell us if you
      think other points are better). I don't found anything like these
      related to PIs. These functions can run a specific hook or check an
      alist (names -> functions). Both solutions provide the ability to
      do :

      (when rng-process-<something>-hook
      ...

      or

      (when rng-process-<something>-alist
      ...

      which is only one test, so it would not slow down the validity code, I
      hope.

      If the user want to use one or other submode managing code, this
      code can register a hook in `rng-schema-change-hook'. This hook is
      responsible to push the right things in `rng-process-<something>-hook'
      or `rng-process-<something>-alist'. For example, if the schema is
      the XHTML one, it push functions to deal with "script" and "style"
      elements, and "style" attribute, at least.

      (BTW, why are `rng-schema-change-hook' and `rng-current-schema'
      declared in <FILE:rng-pttrn.el>, instead of <FILE:rng-loc.el>, for
      example?)

      So, I resumeĀ :

      1/ a few changes to nXML (validity?) code to call functions under
      some conditions;

      2/ sets of rules, one by supported schema, to register the good
      functions to be called in 1/; these rules are processed in
      `rng-schema-change-hook';

      3/ submode managing implementations, telling to 2/ which functions
      to register, and defining all they need.

      I think all this has the advantage to be modularized enough. nXML
      itself doesn't depend on any specific submodes. Anybody can add its
      own submode managing implementation. And submode implementations
      themself can be enough generic to provide the ability to easy adding
      support to some specific submode.

      But maybe I didn't consider something that make all this less
      simple. Any comment? What do you think about this?

      --drkm, en recherche d'un stageĀ : http://www.fgeorges.org/ipl/stage.html
    Your message has been successfully submitted and would be delivered to recipients shortly.