Some Midgard API ideas

1. Henri Bergius

   Some Midgard API ideas

   Tue April 15 2008 12:00:03 UTC
   Hi,
   
   I already posted these on IRC, but here they are for wider discussion.
   Some ideas on improving the MgdSchema API:
   
   * get_path() method for objects (returns the path the object could be
   fetched with in get_by_path())
   * save (does create or update depending on object status)
   * parameters usable directly via PHP5 magic __get and __set so you can
   $object->somedomain->somekey = 'value'; and echo
   $object->somedomain->somekey
   
   --
   Henri Bergius
   Motorcycle Adventures and Free Software
   http://bergie.iki.fi/
   
   Skype: henribergius
   Jabber: henri.bergius@gmail.com
   Jaiku: http://bergie.jaiku.com/
   _______________________________________________
   dev mailing list
   dev@lists.midgard-project.org
   http://lists.midgard-project.org/mailman/listinfo/dev
   •  Reply
   •  Report abuse
2. Arttu Manninen

   Re: [midgard-dev] Some Midgard API ideas

   Tue April 15 2008 12:45:02 UTC
   Henri Bergius wrote:
   > Hi,
   >
   > I already posted these on IRC, but here they are for wider discussion.
   > Some ideas on improving the MgdSchema API:
   >
   > * get_path() method for objects (returns the path the object could be
   > fetched with in get_by_path())
   > * save (does create or update depending on object status)
   > * parameters usable directly via PHP5 magic __get and __set so you can
   > $object->somedomain->somekey = 'value'; and echo
   > $object->somedomain->somekey
   >
   
   I like immediately a lot of `$object->somedomain->somekey` approach,
   it's very simple and elegant.
   
   My question is that does it work or has it already been tested? I made a
   quick test to see if the syntax works and at least I couldn't do it:
   
   <pre>
   <?php
   class get
   {
   function __get($parameter)
   {
   echo "-- get\n";
   print_r($parameter);
   echo "\n\n";
   }
   
   function __set($parameter, $value)
   {
   echo "-- set\n";
   print_r(array($parameter, $value));
   echo "\n\n";
   }
   }
   
   $class = new get();
   
   // Prints correctly 'test' via __get()
   $class->test;
   
   // Prints incorrectly only 'test' via __get()
   $class->test->parameter;
   
   // Prints correctly an array of 'test' and 'New value' via __set()
   $class->test = 'New value';
   
   // Prints incorrectly only 'test' via __get()
   $class->test->name = 'Parameter value';
   ?>
   </pre>
   
   It seems that the second parameter isn't passed at least that easily to
   the class. I don't know yet that well the features of PHP5, so I hope
   that I'm wrong and that it's possible to do this.
   
   It also means that we really need to discard completely the Java-style
   name-spacing and use underscores (which is going to happen anyway). E.g.
   `$object->midcom.helper.datamanager->schema_name` will not work this
   way. This just needs to be taken into account when updating sites from
   MidCOM 2.9 to MidCOM 3.0.
   
   
   --
   Arttu
   _______________________________________________
   dev mailing list
   dev@lists.midgard-project.org
   http://lists.midgard-project.org/mailman/listinfo/dev
   •  Reply
   •  Report abuse
3. Tarjei Huse

   Re: [midgard-dev] Some Midgard API ideas

   Wed April 16 2008 13:20:03 UTC
   -----BEGIN PGP SIGNED MESSAGE-----
   Hash: SHA1
   
   Arttu Manninen wrote:
   > Henri Bergius wrote:
   >> Hi,
   >>
   >> I already posted these on IRC, but here they are for wider discussion.
   >> Some ideas on improving the MgdSchema API:
   >>
   >> * get_path() method for objects (returns the path the object could be
   >> fetched with in get_by_path())
   >> * save (does create or update depending on object status)
   >> * parameters usable directly via PHP5 magic __get and __set so you can
   >> $object->somedomain->somekey = 'value'; and echo
   >> $object->somedomain->somekey
   >>
   >
   > I like immediately a lot of `$object->somedomain->somekey` approach,
   > it's very simple and elegant.
   
   I think that this approach will be very hard to keep consistent across
   languages and that it will also be hard to keep consistent with the fact
   that we allow any string to be the domain name, while PHP has some
   restrictions on what it allows as variable names.
   
   Instead, I'd like to see a parameters array:
   
   $object->parameters['domain']['key']
   
   this has a few bonuses:
   - -> it separates the parameters from the other object attributes.
   - -> it gives us the use of the different array operators. For example:
   unset($object->parameters['domain']);
   - -> we could separate out parameters updating until we are done changing
   the object:
   
   $object->parameters['domain']['key'] = foo
   $object->parameters['domain']['key'] = bar
   $object->save_parameters();
   
   This would reduce the DB load from paramters.
   
   More generally, I think that moving more info from parameters and into
   other tables should be a priority as this would reduce the amount of db
   IO that happens. A special case here is attachments, where I would love
   to see us saving image height and width into the attachment tables
   instead of in parameters.
   
   Another thing to consider is to move the attachment relationships we
   create in dm2 into a separate table instead of keeping them as
   parameters. This would also reduce the size of the parameters table and
   thus make it faster to get things from it.
   
   Now, back to what I should do: Work on my thesis :)
   
   Kind regards,
   Tarjei
   
   
   >
   > My question is that does it work or has it already been tested? I made a
   > quick test to see if the syntax works and at least I couldn't do it:
   >
   > <pre>
   > <?php
   > class get
   > {
   > function __get($parameter)
   > {
   > echo "-- get\n";
   > print_r($parameter);
   > echo "\n\n";
   > }
   >
   > function __set($parameter, $value)
   > {
   > echo "-- set\n";
   > print_r(array($parameter, $value));
   > echo "\n\n";
   > }
   > }
   >
   > $class = new get();
   >
   > // Prints correctly 'test' via __get()
   > $class->test;
   >
   > // Prints incorrectly only 'test' via __get()
   > $class->test->parameter;
   >
   > // Prints correctly an array of 'test' and 'New value' via __set()
   > $class->test = 'New value';
   >
   > // Prints incorrectly only 'test' via __get()
   > $class->test->name = 'Parameter value';
   > ?>
   > </pre>
   >
   > It seems that the second parameter isn't passed at least that easily to
   > the class. I don't know yet that well the features of PHP5, so I hope
   > that I'm wrong and that it's possible to do this.
   >
   > It also means that we really need to discard completely the Java-style
   > name-spacing and use underscores (which is going to happen anyway). E.g.
   > `$object->midcom.helper.datamanager->schema_name` will not work this
   > way. This just needs to be taken into account when updating sites from
   > MidCOM 2.9 to MidCOM 3.0.
   >
   >
   
   -----BEGIN PGP SIGNATURE-----
   Version: GnuPG v1.4.6 (GNU/Linux)
   Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
   
   iD8DBQFIBfuUYVRKCnSvzfIRAtKwAKCbzLZEvO9eG3UgS7a93q1MXz55fgCfWi1l
   9EICtfVsIynypgZFtKgT+uM=
   =AY2P
   -----END PGP SIGNATURE-----
   _______________________________________________
   dev mailing list
   dev@lists.midgard-project.org
   http://lists.midgard-project.org/mailman/listinfo/dev
   •  Reply
   •  Report abuse
4. Piotr Pokora

   Re: [midgard-dev] Some Midgard API ideas

   Wed April 16 2008 14:10:03 UTC
   tarjei writes:
   >> I like immediately a lot of `$object->somedomain->somekey` approach,
   >> it's very simple and elegant.
   >
   > I think that this approach will be very hard to keep consistent across
   > languages and that it will also be hard to keep consistent with the fact
   > that we allow any string to be the domain name, while PHP has some
   > restrictions on what it allows as variable names.
   
   We could make it for PHP only. But I am not sure about usability of this
   solution. Does it force us to check if property is an object type everytime?
   
   > Instead, I'd like to see a parameters array:
   >
   > $object->parameters['domain']['key']
   
   I am afraid it might be buggy.
   First we do not have reference to all arrays in this case.
   There is no hook for arrays on Zend level IIRC. And even if property's
   hook will be taken into account for object->parameters['domain'],
   generic zend's one might be invoked for
   $object->parameters['domain']['key'].
   
   That's why I introduced list_parameters method which should be used as
   basement for particular language solutions.
   
   > $object->parameters['domain']['key'] = foo
   > $object->parameters['domain']['key'] = bar
   > $object->save_parameters();
   >
   > This would reduce the DB load from paramters.
   
   It's already reduced by parameter method which I/O activity is done per
   domain.
   
   echo $obj->parameter("midcom", "A");
   echo $obj->parameter("midcom", "B");
   echo $obj->parameter("midcom", "C");
   echo $obj->parameter("midcom", "A");
   
   produces only one database query
   
   > More generally, I think that moving more info from parameters and into
   > other tables should be a priority as this would reduce the amount of db
   > IO that happens. A special case here is attachments, where I would love
   > to see us saving image height and width into the attachment tables
   > instead of in parameters.
   
   +1
   I think that possibility to inherit from MgdSchema class would be
   helpfull. midgard_image_attachment which extend midgard_attachment could
   handle all image related data. Even exif ones if needed.
   
   BTW, we also need an MgdSchema API method to get object without
   metadata. And this one on demand with some 'get_metadata' method.
   
   Piotras
   _______________________________________________
   dev mailing list
   dev@lists.midgard-project.org
   http://lists.midgard-project.org/mailman/listinfo/dev
   •  Reply
   •  Report abuse