view release on metacpan or  search on metacpan

pod/Xmldoom/doc/GettingStarted.pod  view on Meta::CPAN

Here is a good yet simple BookStore/Object.pm code (you can always make this simpler or 
more complex depending on your needs):

  package BookStore::Object;
  use base qw(Xmldoom::Object);

  use Module::Util qw/ module_fs_path /;
  use File::Basename qw/ dirname /;
  use File::Spec::Functions qw/ catfile /;
  use DBIx::Romani::Driver::mysql;
  use Xmldoom::Definition;
  use strict;
  
  our $DATABASE;
  
  BEGIN
  {
  	my $module_dir = dirname( module_fs_path(__PACKAGE__) );
  	my $database_xml = catfile( $module_dir, 'database.xml' );
  	my $objects_xml  = catfile( $module_dir, 'objects.xml' );
  
  	# read the database definition
  	$DATABASE = Xmldoom::Definition::parse_database_uri( $database_xml );
  	$DATABASE->parse_object_uri( $objects_xml );

	# setup connection factory
	my $driver  = DBIx::Romani::Driver::mysql->new();
	my $factory = DBIx::Romani::Connection::Factory->new({
		dsn      => 'DBI:mysql:database=mydb;host=localhost',
		username => 'myuser',
		password => 'mypass',
		driver   => $driver
	});
	$DATABASE->set_connection_factory( $factory );
  }
  
  1;

A more detailed guide on the bootstrapping process is forth comming.

=head1 PERL OBJECTS

For all the objects in the object definition described above, you need
to have a corresponding Perl package.  It will descend from the custom object class
we defined above to complete the bootstrapping process.

The simplest possible Perl package would be:

  package BookStore::Book;
  use base qw(BookStore::Object);

  1;

Besides using the Perl package to simply add domain specific function and operations to 
your object, there are many other customizations you can make to your object through hooks
into the base Xmldoom::Object.

A more detailed guide on customizing your objects from Perl is forth comming.

=head1 EMBEDING OBJECT XML IN POD

We have found that when working on a large project with many users hacking on the same
source control repository, that many problems can arise with having a centralized
I<objects.xml> file.  One possible solution to this, is keeping the object definitions
for a specific Perl module embedded in that module's POD documentation and running a
script to extract and compile the I<objects.xml>.

Here is an example:

  package BookStore::Publisher;
  use base qw(BookStore::Object);

  1;

  __END__

  =pod

  =begin Xmldoom

  <object name="Publisher" table="publisher">
  	<property name="publisher_id">
  		<simple/>
  	</property>
  	<property name="name">
  		<simple/>
  	</property>
  	<property name="book">
  		<object name="Book"/>
  	</property>
  </object>

  =end Xmldoom

  =cut

Notice how we omit the perl:class="..." attribute.  This will be automatically added
by the script later.  Also, using the __END__ token if you can is good policy, because
it will prevent the Perl compiler from bothering with the object definition which can
get rather large.

Use the xmldoom-generate script from the command line to recursively walk your modules
and build the centralized objects.xml:

  $ xmldoom-generate object-xml -r lib/BookStore -o lib/BookStore/objects.xml

=head1 FOOTNOTES

=over 4

=item 1

http://db.apache.org/torque/

=item 2

http://propel.phpdb.org/trac/

=back