[ANN] xampl 0.1.0

Discussion in 'Ruby' started by Bob Hutchison, Nov 21, 2005.

  1. Hi,

    I've just uploaded the first release (0.1.0) of xampl for Ruby. I'm
    expecting a few teething pains but I hope they'll be over with soon.

    This is a ruby version of a project I've been working on in Java
    since 1998 or so. The Java version has been used to help develop some
    relatively large commercial software applications over the years. The
    Ruby version is a much smaller body of code than the Java version,
    partly due to the fact that it is new, but, really, mostly because of
    the dynamic nature of Ruby.

    It is in three parts. Xampl proper is in xampl-0.1.0.gem. The xampl
    code generators are in xampl-generator-0.1.0.gem. And there is
    documentation, examples, and unit tests in a separate download (the
    documentation needs debugging too). I don't have access to a windows
    machine, so I'd really appreciate it if someone could let me know
    what happens there.

    You can download it here <http://rubyforge.org/frs/?group_id=1034>
    (and I obviously don't know how rubyforge works since only one of the
    three parts is visible from the project's summary page).

    Enjoy!

    Cheers,
    Bob

    Xampl is a tool for developing Ruby programs. It facilitates the 'M'
    part
    of an MVC architecture. It is meant to be very easy to use,
    supportive of
    idiomatic Ruby usage, and mostly invisible.

    Features:
    - pure Ruby, no libraries required except those shipped with Ruby
    1.8.2
    - uses XML to declaratively describe a object structures
    - uses a collection of example XML documents, no schema are
    required
    - supports arbitrary object graphs, not just XML-like trees
    - Ruby idiomatic facilities to navigate the object structures
    (e.g. named
    arrays, hash, iterator support, uses blocks, etc.)
    - support empty, simple (text content only), data (no or limited
    text
    content, but with arbitrary element content), and mixed
    content (where
    text and element content can be intermingled)
    - maps XML namespaces to Ruby modules (with handy defaults) and
    you can
    suggest preferred namespace prefixes for XML output
    - includes an XML pull parser (very fast)
    - code generation is template driven, so the adventurous can
    change what
    is generated
    - includes a simple but powerful and fast templating engine
    - includes a simple-minded but effective hash-like class that
    maintains
    insertion order (fast insertion, lookup, and iteration, but at
    the
    expense of delete)
    - naming conventions are used when generating code (but these
    conventions
    can be changed)
    - additions to the XML will very rarely break existing code, and so
    incremental development of functionality is supported
    - generated code is readable and useful while debugging
    - a command line tool to generate the code, or you can generate
    at runtime
    - XML binding to the classes (i.e. parsing an XML file will
    produce an
    object graph)
    - can augment existing classes
    - programmer adds functionality by opening the class or module, no
    worries
    about the code generator overwriting your changes
    - object structures can generate XML output (and there is an XML
    pretty
    printer used for emphasising human readable XML output)
    - easy to use persistence mechanism
    - persistence is in terms of clusters of objects, the cluster is
    updated
    all at once
    - lazy loading of persisted clusters
    - LRU cache (of clusters)
    - the changed clusters are available for inspection
    - XML, Ruby, and YAML persistence mechanism (purposely no
    Marshal support)
    - persist to memory, or filesystem (optional persistence to an
    FSDB)
    - sync and rollback (even with memory persistence); this is a
    weak form
    of transaction support in this release
    - 'automatic' and 'manual' modes of persistence ('automatic'
    means that
    any xampl cluster created while a persister is active will be
    automatically managed by that persister, manual means that you
    have
    to introduce the xampl cluster to the persister)
    - fast alternative to persistence that does not support rollback
    - xampl objects can hold arbitrary attribute values through the
    persistence 'cycle' if using Ruby or YAML persistence (even xampl
    object); with XML you won't loose anything but all attributes
    will
    be strings after round tripping.
    - multiple persisters, possibly with differing persistence
    mechanisms,
    are supported
    - dead easy single user applications (e.g. desktop apps, CGI),
    almost as
    easy for multiple user applications and webapps
    - you can add your own persister types (and formats for that
    matter)
    - general purpose Visitor pattern facility, with pre and post
    visit methods,
    cycle and revisit detection and handling
    - lots of hooks
    - many unit tests, all execute without warning when run with the -
    w Ruby flag
    - there are some examples, and the beginnings of a tutorial in the
    form of
    a series of examples that lead you through the core parts of xampl

    Features that are coming soon:
    - many more hooks
    - more sophisticated augmentation of existing classes
    - indexing and querying of the persisted object structures
    - more persisters (e.g. sqlite)
    - real transactions
    - a better comparison function (that deals with cyclic structures
    at all, and
    better with non-tree acyclic structures)

    Known Bugs or Potential Problems or Suspected Problems
    - generated attribute names may conflict with Ruby keywords and
    this is not
    a nice thing to witness (this is easy to fix, but I don't want
    to do this
    until the next release at the earliest)
    - I don't know if this will work on Windows -- I tried, but I
    don't have a
    windows machine to test this with -- there might be some
    pathname stuff
    assuming unix (but I hope not)
    - some of the code is unnecessarily ugly (e.g. some of the visitor
    internals)
    - there are no Ruby docs (but I promise... really)
    - comparison of cyclic structures will crash

    License: GPL. An alternative license may be negotiated, contact me.

    While the Ruby version of xampl is brand new it is based on a Java
    tool that I've been developing since 1998 and in its fifth generation.
    There are many features in the Java version that are not available in
    this library, but that is either just a matter of time, or they will
    never be needed because Ruby programs don't need the help.

    The Java version of the tool has been used to write a number of large
    webapps, and a few smaller desktop applications, and even an applet.

    There is a Common Lisp/CLOS version coming.

    ----
    Bob Hutchison -- blogs at <http://www.recursive.ca/hutch/>
    Recursive Design Inc. -- <http://www.recursive.ca/>
    Raconteur -- <http://www.raconteur.info/>
     
    Bob Hutchison, Nov 21, 2005
    #1
    1. Advertising

  2. Some questions just out of curiosity. No offense intended.

    Bob Hutchison wrote:

    <snip/>

    > Xampl is a tool for developing Ruby programs. It facilitates the 'M'
    > part
    > of an MVC architecture. It is meant to be very easy to use,
    > supportive of
    > idiomatic Ruby usage, and mostly invisible.
    >
    > Features:
    > - pure Ruby, no libraries required except those shipped with Ruby
    > 1.8.2
    > - uses XML to declaratively describe a object structures
    > - uses a collection of example XML documents, no schema are
    > required


    Interestingly some days ago I thought about how J2EE is really two
    languages (Java for implementation, XML for configuration) and how Ruby
    can do both very neatly because of its clean syntax. From your
    experience, does it really pay off to use XML here? Or is ist just
    because you want to be able to read in arbitrary files and use the content
    as Ruby objects?

    <snip/>

    > - XML, Ruby, and YAML persistence mechanism (purposely no
    > Marshal support)


    Why is that? What's the reasoning behind this?

    Kind regards

    robert
     
    Robert Klemme, Nov 21, 2005
    #2
    1. Advertising

  3. On Nov 21, 2005, at 9:47 AM, Robert Klemme wrote:

    >
    > Some questions just out of curiosity. No offense intended.


    No problem. You've asked a couple of interesting questions.

    >
    > Bob Hutchison wrote:
    >
    > <snip/>
    >
    >> Xampl is a tool for developing Ruby programs. It facilitates the 'M'
    >> part
    >> of an MVC architecture. It is meant to be very easy to use,
    >> supportive of
    >> idiomatic Ruby usage, and mostly invisible.
    >>
    >> Features:
    >> - pure Ruby, no libraries required except those shipped with Ruby
    >> 1.8.2
    >> - uses XML to declaratively describe a object structures
    >> - uses a collection of example XML documents, no schema are
    >> required

    >
    > Interestingly some days ago I thought about how J2EE is really two
    > languages (Java for implementation, XML for configuration) and how
    > Ruby
    > can do both very neatly because of its clean syntax. From your
    > experience, does it really pay off to use XML here? Or is ist just
    > because you want to be able to read in arbitrary files and use the
    > content
    > as Ruby objects?


    Yes it does make sense I think. How do you express succinctly the
    relationship between a bunch of live objects? Amusingly, the hyper-
    verbose XML can actually do that :) It all depends on how you
    interpret the XML. XML can reflect a containment/composition/
    aggregation relationship about as tersely as you can get in text.

    Xampl is not about using XML for configuration, but for 1) describing
    dynamic relationships between objects; and 2) persistence.

    I agree with you that much of what XML, or YAML for that matter, is
    used for can be better done in Ruby (or Python, or any other dynamic
    language), certainly the way XML is used conventionally. Though xampl
    changes the picture a bit.

    The other thing xampl does is makes it a lot easier to deal with XML
    based protocols. I've provided an example with the distribution (and
    discussed in the documentation) of how to use xampl to read an Atom
    1.0 or 0.3 feed over the internet, cache the feeds, extract the
    entries, convert 0.3 entries to 1.0, aggregate in a new 1.0 feed
    paying attention to ordering, and serve it up via WEBrick. Xampl
    really helps in this kind of thing.

    This is actually a really good question and I should prepare a better
    answer. The background for what I'll say is documented in the
    download file, but there is no direct answer to this question there.


    >
    > <snip/>
    >
    >> - XML, Ruby, and YAML persistence mechanism (purposely no
    >> Marshal support)

    >
    > Why is that? What's the reasoning behind this?


    1) Upgrades of marshalled objects can be really nasty, using a text
    form that xampl has control over while parsing, you have a chance of
    intervening at an opportune time, making your life a lot easier.
    2) You can read XML, Ruby and YAML.
    3) You can use the data easily independently of any xampl program
    (e.g. in a text editor :)
    4) You cannot control how much of the network of reachable objects is
    written to one file (this is very important in xampl because of its
    clustering capabilities).

    There are more reasons that I've forgotten, these are enough for me.

    Cheers,
    Bob

    >
    > Kind regards
    >
    > robert
    >
    >


    ----
    Bob Hutchison -- blogs at <http://www.recursive.ca/hutch/>
    Recursive Design Inc. -- <http://www.recursive.ca/>
    Raconteur -- <http://www.raconteur.info/>
     
    Bob Hutchison, Nov 21, 2005
    #3
  4. Bob Hutchison wrote:
    > On Nov 21, 2005, at 9:47 AM, Robert Klemme wrote:
    >
    >>
    >> Some questions just out of curiosity. No offense intended.

    >
    > No problem. You've asked a couple of interesting questions.
    >
    >>
    >> Bob Hutchison wrote:
    >>
    >> <snip/>
    >>
    >>> Xampl is a tool for developing Ruby programs. It facilitates the 'M'
    >>> part
    >>> of an MVC architecture. It is meant to be very easy to use,
    >>> supportive of
    >>> idiomatic Ruby usage, and mostly invisible.
    >>>
    >>> Features:
    >>> - pure Ruby, no libraries required except those shipped with Ruby
    >>> 1.8.2
    >>> - uses XML to declaratively describe a object structures
    >>> - uses a collection of example XML documents, no schema are
    >>> required

    >>
    >> Interestingly some days ago I thought about how J2EE is really two
    >> languages (Java for implementation, XML for configuration) and how
    >> Ruby
    >> can do both very neatly because of its clean syntax. From your
    >> experience, does it really pay off to use XML here? Or is ist just
    >> because you want to be able to read in arbitrary files and use the
    >> content
    >> as Ruby objects?

    >
    > Yes it does make sense I think. How do you express succinctly the
    > relationship between a bunch of live objects? Amusingly, the hyper-
    > verbose XML can actually do that :) It all depends on how you
    > interpret the XML. XML can reflect a containment/composition/
    > aggregation relationship about as tersely as you can get in text.


    Well, you can describe those relationships in Ruby, too. In fact, nearly
    every Ruby program does it by creating / assigning member variables. :)

    > Xampl is not about using XML for configuration, but for 1) describing
    > dynamic relationships between objects; and 2) persistence.


    "describe" persistence or "implement" persistence? It seems rather the
    latter.

    > I agree with you that much of what XML, or YAML for that matter, is
    > used for can be better done in Ruby (or Python, or any other dynamic
    > language), certainly the way XML is used conventionally. Though xampl
    > changes the picture a bit.
    >
    > The other thing xampl does is makes it a lot easier to deal with XML
    > based protocols. I've provided an example with the distribution (and
    > discussed in the documentation) of how to use xampl to read an Atom
    > 1.0 or 0.3 feed over the internet, cache the feeds, extract the
    > entries, convert 0.3 entries to 1.0, aggregate in a new 1.0 feed
    > paying attention to ordering, and serve it up via WEBrick. Xampl
    > really helps in this kind of thing.
    >
    > This is actually a really good question and I should prepare a better
    > answer. The background for what I'll say is documented in the
    > download file, but there is no direct answer to this question there.


    So one of the strengths of xampl is to deal with existing XML data.

    >> <snip/>
    >>
    >>> - XML, Ruby, and YAML persistence mechanism (purposely no
    >>> Marshal support)

    >>
    >> Why is that? What's the reasoning behind this?

    >
    > 1) Upgrades of marshalled objects can be really nasty, using a text
    > form that xampl has control over while parsing, you have a chance of
    > intervening at an opportune time, making your life a lot easier.
    > 2) You can read XML, Ruby and YAML.
    > 3) You can use the data easily independently of any xampl program
    > (e.g. in a text editor :)
    > 4) You cannot control how much of the network of reachable objects is
    > written to one file (this is very important in xampl because of its
    > clustering capabilities).
    >
    > There are more reasons that I've forgotten, these are enough for me.


    Well, that's quite comprehensive! Thanks for the quick and exhaustive
    answer!

    Kind regards

    robert
     
    Robert Klemme, Nov 21, 2005
    #4
  5. Bob Hutchison

    Kirk Haines Guest

    On Monday 21 November 2005 7:28 am, Bob Hutchison wrote:

    > You can download it here <http://rubyforge.org/frs/?group_id=1034>
    > (and I obviously don't know how rubyforge works since only one of the
    > three parts is visible from the project's summary page).


    I'd love to take a look at xampl. Could you, though, upload an archive of it
    that doesn't depend on gems?


    Thanks,

    Kirk Haines
     
    Kirk Haines, Nov 21, 2005
    #5
  6. Absolutely. Good idea. Can you point me to how you deal with require
    statements that work with either. I think I saw something like that
    but I can't find it now. How would you like it done, since you've
    asked first?

    Cheers,
    Bob

    On Nov 21, 2005, at 10:46 AM, Kirk Haines wrote:

    > On Monday 21 November 2005 7:28 am, Bob Hutchison wrote:
    >
    >> You can download it here <http://rubyforge.org/frs/?group_id=1034>
    >> (and I obviously don't know how rubyforge works since only one of the
    >> three parts is visible from the project's summary page).

    >
    > I'd love to take a look at xampl. Could you, though, upload an
    > archive of it
    > that doesn't depend on gems?
    >
    >
    > Thanks,
    >
    > Kirk Haines
    >


    ----
    Bob Hutchison -- blogs at <http://www.recursive.ca/hutch/>
    Recursive Design Inc. -- <http://www.recursive.ca/>
    Raconteur -- <http://www.raconteur.info/>
     
    Bob Hutchison, Nov 21, 2005
    #6
  7. On Nov 21, 2005, at 10:32 AM, Robert Klemme wrote:

    > Bob Hutchison wrote:
    >> On Nov 21, 2005, at 9:47 AM, Robert Klemme wrote:
    >>
    >>>
    >>> Some questions just out of curiosity. No offense intended.

    >>
    >> No problem. You've asked a couple of interesting questions.
    >>
    >>>
    >>> Bob Hutchison wrote:
    >>>
    >>> <snip/>
    >>>
    >>>> Xampl is a tool for developing Ruby programs. It facilitates the
    >>>> 'M'
    >>>> part
    >>>> of an MVC architecture. It is meant to be very easy to use,
    >>>> supportive of
    >>>> idiomatic Ruby usage, and mostly invisible.
    >>>>
    >>>> Features:
    >>>> - pure Ruby, no libraries required except those shipped with
    >>>> Ruby
    >>>> 1.8.2
    >>>> - uses XML to declaratively describe a object structures
    >>>> - uses a collection of example XML documents, no schema are
    >>>> required
    >>>
    >>> Interestingly some days ago I thought about how J2EE is really two
    >>> languages (Java for implementation, XML for configuration) and how
    >>> Ruby
    >>> can do both very neatly because of its clean syntax. From your
    >>> experience, does it really pay off to use XML here? Or is ist just
    >>> because you want to be able to read in arbitrary files and use the
    >>> content
    >>> as Ruby objects?

    >>
    >> Yes it does make sense I think. How do you express succinctly the
    >> relationship between a bunch of live objects? Amusingly, the hyper-
    >> verbose XML can actually do that :) It all depends on how you
    >> interpret the XML. XML can reflect a containment/composition/
    >> aggregation relationship about as tersely as you can get in text.

    >
    > Well, you can describe those relationships in Ruby, too. In fact,
    > nearly
    > every Ruby program does it by creating / assigning member
    > variables. :)


    Sure, but not so tersely and not so easily understood by non-
    programmer. Most people are capable of recognising a document in a
    slightly unfamiliar form and how to read one, and XML is something
    they can recognise. You can design a xampl system by modelling paper
    pushing.

    That's not to say xampl won't be able to work directly on Ruby
    classes at some point :) Though that is a ways off I think.

    >
    >> Xampl is not about using XML for configuration, but for 1) describing
    >> dynamic relationships between objects; and 2) persistence.

    >
    > "describe" persistence or "implement" persistence? It seems rather
    > the
    > latter.


    Implement persistence as an option.

    >
    >> I agree with you that much of what XML, or YAML for that matter, is
    >> used for can be better done in Ruby (or Python, or any other dynamic
    >> language), certainly the way XML is used conventionally. Though xampl
    >> changes the picture a bit.
    >>
    >> The other thing xampl does is makes it a lot easier to deal with XML
    >> based protocols. I've provided an example with the distribution (and
    >> discussed in the documentation) of how to use xampl to read an Atom
    >> 1.0 or 0.3 feed over the internet, cache the feeds, extract the
    >> entries, convert 0.3 entries to 1.0, aggregate in a new 1.0 feed
    >> paying attention to ordering, and serve it up via WEBrick. Xampl
    >> really helps in this kind of thing.
    >>
    >> This is actually a really good question and I should prepare a better
    >> answer. The background for what I'll say is documented in the
    >> download file, but there is no direct answer to this question there.

    >
    > So one of the strengths of xampl is to deal with existing XML data.


    Yes, and producing XML. Though, and I really can't stress this
    enough, it even helps *a lot* if XML is only used as a description
    and never in practice.

    >
    >>> <snip/>
    >>>
    >>>> - XML, Ruby, and YAML persistence mechanism (purposely no
    >>>> Marshal support)
    >>>
    >>> Why is that? What's the reasoning behind this?

    >>
    >> 1) Upgrades of marshalled objects can be really nasty, using a text
    >> form that xampl has control over while parsing, you have a chance of
    >> intervening at an opportune time, making your life a lot easier.
    >> 2) You can read XML, Ruby and YAML.
    >> 3) You can use the data easily independently of any xampl program
    >> (e.g. in a text editor :)
    >> 4) You cannot control how much of the network of reachable objects is
    >> written to one file (this is very important in xampl because of its
    >> clustering capabilities).
    >>
    >> There are more reasons that I've forgotten, these are enough for me.

    >
    > Well, that's quite comprehensive! Thanks for the quick and exhaustive
    > answer!


    :)

    >
    > Kind regards
    >
    > robert
    >
    >


    ----
    Bob Hutchison -- blogs at <http://www.recursive.ca/hutch/>
    Recursive Design Inc. -- <http://www.recursive.ca/>
    Raconteur -- <http://www.raconteur.info/>
     
    Bob Hutchison, Nov 21, 2005
    #7
  8. On 11/21/05, Bob Hutchison <> wrote:
    > Absolutely. Good idea. Can you point me to how you deal with require
    > statements that work with either. I think I saw something like that
    > but I can't find it now. How would you like it done, since you've
    > asked first?


    I recommend looking at the PDF::Writer Rakefile (in the CVS
    repository) as I automatically create a gem, a .tar.gz, and a demo
    tar.gz from the rakefile and even upload it to RubyForge.

    I hope to be submitting a new version of the Rakefile that has a minor
    fix for the .tar.gz creation (the .tar.gz is built properly, but gzip
    reports that the compression wasn't completed; there is no damage to
    the file, it's mostly a spurious warning) in the next couple of days.

    -austin
    --
    Austin Ziegler *
    * Alternate:
     
    Austin Ziegler, Nov 21, 2005
    #8
  9. Bob Hutchison

    Kirk Haines Guest

    On Monday 21 November 2005 9:28 am, Bob Hutchison wrote:
    > Absolutely. Good idea. Can you point me to how you deal with require
    > statements that work with either. I think I saw something like that
    > but I can't find it now. How would you like it done, since you've
    > asked first?


    I've made a couple gems, but I'm not really a gems user now, so I can't really
    tell you, except to say that I would like to be able to download a tar
    archive of xampl so that I can try it out without having anything that I do
    with it forced to depend on gems.

    I'd look at what Austin Ziegler has done with his PDF::Writer package. It's a
    good practical example of how to target both gems and non-gems systems about
    as cleanly as it currently possible.


    Thanks,

    Kirk Haines
     
    Kirk Haines, Nov 22, 2005
    #9
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Mike Sampson [MSFT]

    [ANN]: NNTP Server slow downs.

    Mike Sampson [MSFT], Oct 7, 2003, in forum: ASP .Net
    Replies:
    0
    Views:
    417
    Mike Sampson [MSFT]
    Oct 7, 2003
  2. Mike Sampson [MSFT]

    [ANN]: NNTP Server slow downs.

    Mike Sampson [MSFT], Dec 6, 2003, in forum: ASP .Net
    Replies:
    0
    Views:
    502
    Mike Sampson [MSFT]
    Dec 6, 2003
  3. Richard Grimes [MVP]

    ANN: Free .NET Workshops

    Richard Grimes [MVP], Jul 4, 2005, in forum: ASP .Net
    Replies:
    0
    Views:
    506
    Richard Grimes [MVP]
    Jul 4, 2005
  4. Michael Livsey
    Replies:
    3
    Views:
    429
    Michael Livsey
    May 27, 2004
  5. zxem
    Replies:
    1
    Views:
    93
    Bob Hutchison
    Nov 16, 2007
Loading...

Share This Page