Hello,

--- In metal-dev@yahoogroups.com, "enradia" <enradia@y...> wrote:
> My name is Joshua and I am the project leader for Nexista
> (nexista.tigris.org). We are currently using metabase for our DB
> access and have decided to move to a DAO approach. We are
> considering Metastorage or Propel. SO far I am very impressed with
> what I have seen and have a couple of questions.

Yes, currently Metastorage generates code that still uses Metabase but I
plan to make it an option between Metabase and using code that uses
native PHP database API calls. I am thinking about generating MySQL
specific code in a first alternative implementation.

Generating PHP 5 specific code as an option is also planned and will not
take much work as most of the new PHP 5 features were already supported
in MetaL classes object model (protected, private, public, package,
exceptions, etc...).

BTW, recently I made a suggestion to Zend people to add a warning when
object cloning is performed in Zend engine 1 compatibility mode but will
no longer happen in PHP 5 with Zend engine 2. This has already helped
locating some inadverted object copying occurrences in MetaL engine code
and soon I will be fixing them. This means that all MetaL applications
will run under PHP 5 soon too. The code generated by Metastorage is not
a problem because it is already passing objects by reference everywhere.


> 1. I understand that filters is under development. What is the ETA

The filters are done since a long time ago. This means that the logic
for translating filter expressions to SQL syntax is ready. What is not
done is the support to most of the types of expressions and operators
that you will want to use, although that is the easy part.

I intend to work on finishing and document that soon next month. For now
you can for instance just add a getallobjects functions with filter like
this and it will generate the appropriate code.

<function>
<name>getrootcategories</name>
<type>getallobjects</type>
<parameters>
<class>category</class>
<filter>
<isnull><variable>parent</variable></isnull>
</filter>
</parameters>
</function>


As for an estimated time for availability, usually I implement features
once I can test them in real usage situation because that way I can test
and validate the implementation. That is why only a part of the filter
expressions was implemented. That was what I needed when I developed it.

I intend to finish a basic set a common filter expressions and operators
soon because I really need that for other projects. Soon in this case
means the first two weeks of May as that it will be when I will be done
with the pending issues of the Innovation Award of the PHP Classes site.



> for a usable set and what will it look like. For example, the Propel
> approach towards WHERE filters might look like:
>
> $c->add(AuthorPeer::FIRST_NAME, "Karl");
> $c->add(AuthorPeer::LAST_NAME, "Marx", Criteria::NOT_EQUAL);
>
> Pear is similar. Neither is much easier than writing raw sql though
> it may be more portable.
>
> What would be a Metastorage example of something like this? a
> complicated example would be great :)

If you pick the example getallobjects function filter above you may be
able to see what is generated.

Anyway, the basic principle is that you will never have to build the
search query dynamically at run time and even less you will need to
enter SQL by hand. Remember that Metastorage is meant to generate
storage container independent API. Most storage containers do not even
provide SQL, like flat files databases, XML files, data in LDAP servers,
etc..

The way it works, is that when you need to perform a search with a given
filter expression, you need to add a query factory function of type like
getobject or getallobjects if you do not depart from an existing object
or some other class function if you depart from an existing object.

Lets consider you example above of wanting to retrieve all objects of
class author with first name Karl and last name not Marx. You would need
to declare a factory function of type getallobjects like this:

<function>
<name>getkarlnotmarx</name>
<type>getallobjects</type>
<parameters>
<class>author</class>
<filter>
<variable>first_name</variable> <equalto /> <text>Karl</text>
<and />
<variable>last_name</variable> <differentfrom /> <text>Marx</text>
</filter>
</parameters>
</function>

But lets say you do not want to make those literal strings static and
take them as arguments that you can pass at run time. You just need to
add arguments to the function and use them in the filter expression.

<function>
<name>getkarlnotmarx</name>
<type>getallobjects</type>
<parameters>
<class>author</class>
<argument>
<name>first_name</name>
<type>TEXT</type>
</argument>
<argument>
<name>last_name</name>
<type>TEXT</type>
</argument>
<filter>
<variable>first_name</variable> <equalto />
<argument>first_name</argument>
<and />
<variable>last_name</variable> <differentfrom />
<argument>first_name</argument>
</filter>
</parameters>
</function>

More complex cases involve relationships (joins) that require also the
declaration of the classes of the objects involved in the relationships
that you want to query.


> 2. Nexista already has it's own validator/filter/form system (all
> xml). It would be nice to extend Metastorage to generate generic
> filter/validator/form files. Would this be a difficult task? I took
> a looksy at the .input and .ouput files. I assume these are the
> Metal configs that generate the whole thing?

It is not difficult but there is a lot to explain because the way MetaL
works is unusual. You do not program it MetaL, you just write programs
that once compiled do what you want in a target language. That is
meta-programming.

From the base MetaL meta-programming language to PHP/Java/Perl it is
more or less simple to understand because it is a basic translation
performed by different modules of MetaL compiler that take care of
implementing things like control flow, expression handling, classes,
templates compilation, etc...

Metastorage is actually a wrapper around a special module named
persistence. The persistence module does not generate (now) code in a
target language directly. Instead it generates MetaL code (XML, those
input, output, class files in the generated directory) that other
modules will process in a second stage to the generate the target
language code (currently just PHP).

You can call that meta-meta-programming or meta-2-programming. The trend
is to abstract your applications higher and have other smarter modules
that wrap around the persistence module to provide very high level
domain specific programming support. But this is already an advanced
topic that moves away from what you need to know now.

The persistence module generates an output stream that defines XML
documents that compose those files in the generated directory. Currently
such composition is done with a lot of PHP code in
metal_persistence_*.php classes.

I am not happy with this solution because it is hard to maintain. So, I
plan to soon add support to generate all from XML templates that will be
easier to maintain. I think then it will be easier for you to understand
and customize.

For now, MetaL generates data object classes and also basic form classes
to handle simple classes but nothing stops you for now to generate your
own form classes that call the data object classes generated by MetaL.
That is what currently the form classes generated by MetaL do.


> I'm not sure if you have looked at Propel. I know from past emails
> that you've given very useful and professional comparisons of
> Metabase vs xxx. I would be curious to hear of your thoughts on
> this.

I do not know all that those packages can do. But from what I could
gather what they do still works a lot based on executing static
decisions dynamically, thus loosing the chance to optimize the generate
code as much as it could.

The example of composing search queries above demonstrates that clearly.
When you develop your applications, you will hardly ever need to compose
search queries dynamically. Most of your queries have static formats,
despite they may depend on run-time parameters as in the case when you
pass query parameters as function arguments.

All this dynamic composion approach has a price in terms of performance
and code bloat.

Another problem is that these packages tend to make it all depend on fat
base classes that ship all the functionality that you could ever need,
whether or not you will really use it in your applications.

In PHP this is particularly penalizing. PHP objects are in fact
associative arrays accessed with a different syntax. So, all those
functions and variable will occupy space and take some initialization
time even if you do not use them.

The Metastorage approach is what I call JE WIN - Just Exactly What I
Need. It means that in practice, the persistence module will only
generate the code that each class model needs, not more, not less.

For instance, if you do not need a function to delete an object,
Metastorage will not generate it. That is why Metastorage requires that
you declare that you need in each class apart from those that are
mandatory because you will always use them.

Anyway, as I said I do not know enough about those other solutions. If
you have studied them and found any details where their approach is
beneficial, I would certainly would like to know because it may have
been some optimization opportunity that I may have overlooked.

This is part of the reason why it pays to open the source of projects.
Have poeple with critical eyes look into it and suggest things that
could be done better.

--

Regards,
Manuel Lemos

PHP Classes - Free ready to use OOP components written in PHP
http://www.phpclasses.org/

PHP Reviews - Reviews of PHP books and other products
http://www.phpclasses.org/reviews/

Metastorage - Data object relational mapping layer generator
http://www.meta-language.net/metastorage.html