You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@hivemind.apache.org by hi...@jakarta.apache.org on 2004/04/26 14:49:44 UTC

[Jakarta HiveMind Wiki] New: NotXMLProposal

   Date: 2004-04-26T05:49:44
   Editor: HowardLewisShip <hl...@apache.org>
   Wiki: Jakarta HiveMind Wiki
   Page: NotXMLProposal
   URL: http://wiki.apache.org/jakarta-hivemind/NotXMLProposal

   no comment

New Page:

= Problem Description =

HowardLewisShip, April 26 2004, 1-0-alpha-4

One of the tenets of !HiveMind is that deployment descriptors for J2EE are in verbose XML.

And yet, the descriptors for HiveMind are themselves XML and can be quite verbose.

Several people, especially ErikHatcher, have '''repeatedly''' pointed this out to me.

As things currently stand, XML is used for two reasons:
   * It's easy to use an XML parser to read the kind of hierarchical data inside a descriptor.
   * It's easy to generate HiveDoc directly from the XML.

= Proposed Solution =

WE can define our own special purpose langage for the descriptors.  The language could be more readable and succinct than the equivalent XML. More work would have to be put
into the HiveDoc, to generate the HiveDoc directly from the descriptor objects, or to generate an intermediate XML format from the descriptor objects.

Here's some examples along the lines of thinking:
{{{
module  myapp.ui.toolbar, version 1.0.1

configuration-point ToolbarActions
{
  element item
  {
    required attribute label;
    required attribute icon;
    attribute action-class;
    attribute service-id;

    conversion (class=myapp.ui.toolbar.ToolbarAction)
    {
      map (attribute=action-class property=action translator=object)
      map (attribute=service-id property=action translator=service)
    }
  }
}

contribution ToolbarAction
{
  item(label=Open icon=Open.gif service-id=OpenService)
}

service-point OpenService interface=myapp.ui.toolbar.ToolbarAction
{
  invoke hivemind.BuilderFactory
  {
    construct(class=myapp.ui.toolbar.impl.OpenActionImpl log-property=log messages-property=messages)
    {
      set(name=frob value=grognard)
      set-service(name=dialogViewer service-id=myapp.ui.DialogViewer)
      set-configuration(name=pipeline configuration-id=myapp.ui.FileOpenPipeline)
    }
  }

  add-interceptor service-id=hivemind.LoggingFactory;
}


}}}

This is pretty obviouslly darn isomorphic to the existing XML format. Remember, XML started as a document format, where using punctuation for blocking delimiters
was a bad idea, since such characters could show up in the document text. Our use of !HiveMind deployment descriptors is a much more constrained environment, more like scripting
than like pure documents. For example, quoting of attributes is not necessary for most attributes, just the ones with whitespace (or other characters outside a specific subset).

Also, many parts of XML were intended to make it easier to write an XML parser (though, over time, things have twisted such that a fully conformant  XML parser is now an enourmous beast). Again ... not our concern.

This solution involves nailing down precisely (in BNF) what our format will look like and writing that parser. Most likely, something like ["JavaCC"] can be leveraged (depending on licensing). Possibly, we write a simply parser that converts the above to a DOM-like format and work from there.

= Discussion =

---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-cvs-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-cvs-help@jakarta.apache.org