Login | Register
My pages Projects Community openCollabNet

Discussions > dev > RE: [propel-dev] propel / c++

propel
Discussion topic

Hide all messages in topic

All messages in topic

Re: [propel-dev] propel / c++

Reply

Author Roel Vanhout <roel dot vanhout at gmail dot com>
Full name Roel Vanhout <roel dot vanhout at gmail dot com>
Date 2006-07-24 08:32:59 PDT
Message Looks like this requires deeper changes than I originally thought (no
surprise there).

It's easy to make PHPObjectBuilder and put the php-specific things in
there. However, in order to let the other classes derive from that
PHPObjectBuilder, we'd need something like this (I originally thought
it would work but it doesn't):

class PHP5BasicObjectBuilder extends
DataModelBuilder::bu​ilderFactory(null, 'ombuilder') {
}

Then we'd just add another key to the propertiesfile and off we go.
But as I said, it looks like inheriting from anything but a 'static'
type is impossible.

Next option is to recreate the OMBuilder, ObjectBuilder and
PeerBuilder in the language-specific directorie and have them derive
from the language-neutral classes (to avoid duplicating code). This is
fine for OMBuilder (I wrote a PHPOMBuilder that derives from OMBuilder
and let all classes that originally derived from OMBuilder derive from
PHPOMBuilder.) But for PeerBuilder, that doesn't work because
PeerBuilder itself derives from OMBuilder, whereas it should derive
from PHPOMBuilder, or CPPOMBuilder, as required. The alternative is to
move the code from PeerBuilder to PHPPeerBuilder, but that same code
would have to be duplicated in CPPPeerBuilder, which is not good.
In C++ I'd solve this with either multiple inheritance to pull in the
common functionality from a shared base class or with templates to let
PeerBuilder be templated to provide the base class, but it seems that
MI and templates aren't available in PHP without nasty hacks. I'm not
quite sure what to do at this point, I'll think it over, but if anyone
who is more familiar with the codebase has an idea, feel free to take
a look yourself :)

cheers,

roel


On 7/24/06, Roel Vanhout <roel dot vanhout at gmail dot com> wrote:
> I'll look into making a patch, but I'd rather not commit it myself - I
> got yelled at once in another project a couple of years ago, now I'm a
> bit hesitant to commit to codebases I'm not very familiar with :) I'll
> let the list know. Thanks.
>
> cheers,
>
> roel
>
>
> On 7/24/06, Hans Lellelid <hans at velum dot net> wrote:
> > Hi Roel,
> >
> > I think we just need to change that behavior. Perhaps we should make a
> > PHPOMBuilder subclass that holds any PHP specific stuff. I'll see if I
> > can find a few minutes to look at that today. (Or, if you'd like to
> > refactor that class, you can send me an email w/ username request for
> > SVN and I'll make you an account.)
> >
> > Cheers,
> > Hans
> >
> > Roel Vanhout wrote:
> > > Hello Soenke,
> > >
> > > Thanks for your answer, this works for all classes that are in the
> > > propel\generator\c​lasses\propel\engi​ne\builder\om\php​5 directory but
> > > there is one file (OMBuilder.php) that is one directory higher. I
> > > don't see it mentioned in the default.properties list of builders. In
> > > this file, which defines the OMBuilder class, the <?php is added to
> > > every file that is written out and it sets .cpp as extention for files
> > > that are written, both of which I'd like to change. I don't see
> > > however where I can indicate that my custom class should be used.
> > >
> > > cheers,
> > >
> > > roel
> > >
> > >
> > > On 7/24/06, Soenke Ruempler <ruempler@topconc​epts.com> wrote:
> > >> Roel Vanhout <mailto:roel.vanh​out at gmail dot com> wrote on Monday, July 24,
> > >> 2006 12:50 PM:
> > >>
> > >> > I'm not sure if that was directed at the PECL thing or the pure C++
> > >> > that I'm trying to accomplish :) , but either way: is there anyone who
> > >> > knows the answer to my original question whether it is possible to use
> > >> > another OMBuilder class? Thanks.
> > >>
> > >> Of course, in build.properties we have it like this:
> > >>
> > >> propel.builder.mapbuilder.class = tcc.Propel.Engine.Builder.Map
> > >> propel.builder.object.class =tcc.Propel.Engine.B​uilder.ComplexObject​
> > >> propel.builder.peer.class =tcs.Propel.Engine.B​uilder.ComplexPeer
> > >>
> > >> -soenke
> > >>
> > >> --------------------​--------------------​--------------------​---------
> > >> To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org
> > >> For additional commands, e-mail: dev-help at propel dot tigris dot org
> > >>
> > >>
> > >
> > > --------------------​--------------------​--------------------​---------
> > > To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org
> > > For additional commands, e-mail: dev-help at propel dot tigris dot org
> > >
> >
> > --------------------​--------------------​--------------------​---------
> > To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org
> > For additional commands, e-mail: dev-help at propel dot tigris dot org
> >
> >
>

Re: [propel-dev] propel / c++

Reply

Author hlellelid
Full name Hans Lellelid
Date 2006-07-24 06:20:06 PDT
Message Ok, a patch would be great :)

Thanks -
Hans

Roel Vanhout wrote:
> I'll look into making a patch, but I'd rather not commit it myself - I
> got yelled at once in another project a couple of years ago, now I'm a
> bit hesitant to commit to codebases I'm not very familiar with :) I'll
> let the list know. Thanks.
>
> cheers,
>
> roel
>
>
> On 7/24/06, Hans Lellelid <hans at velum dot net> wrote:
>> Hi Roel,
>>
>> I think we just need to change that behavior. Perhaps we should make a
>> PHPOMBuilder subclass that holds any PHP specific stuff. I'll see if I
>> can find a few minutes to look at that today. (Or, if you'd like to
>> refactor that class, you can send me an email w/ username request for
>> SVN and I'll make you an account.)
>>
>> Cheers,
>> Hans
>>
>> Roel Vanhout wrote:
>> > Hello Soenke,
>> >
>> > Thanks for your answer, this works for all classes that are in the
>> > propel\generator\c​lasses\propel\engi​ne\builder\om\php​5 directory but
>> > there is one file (OMBuilder.php) that is one directory higher. I
>> > don't see it mentioned in the default.properties list of builders. In
>> > this file, which defines the OMBuilder class, the <?php is added to
>> > every file that is written out and it sets .cpp as extention for files
>> > that are written, both of which I'd like to change. I don't see
>> > however where I can indicate that my custom class should be used.
>> >
>> > cheers,
>> >
>> > roel
>> >
>> >
>> > On 7/24/06, Soenke Ruempler <ruempler@topconc​epts.com> wrote:
>> >> Roel Vanhout <mailto:roel.vanh​out at gmail dot com> wrote on Monday, July
>> 24,
>> >> 2006 12:50 PM:
>> >>
>> >> > I'm not sure if that was directed at the PECL thing or the pure C++
>> >> > that I'm trying to accomplish :) , but either way: is there
>> anyone who
>> >> > knows the answer to my original question whether it is possible
>> to use
>> >> > another OMBuilder class? Thanks.
>> >>
>> >> Of course, in build.properties we have it like this:
>> >>
>> >> propel.builder.mapbuilder.class = tcc.Propel.Engine.Builder.Map
>> >> propel.builder.object.class =tcc.Propel.Engine.B​uilder.ComplexObject​
>> >> propel.builder.peer.class =tcs.Propel.Engine.B​uilder.ComplexPeer
>> >>
>> >> -soenke
>> >>
>> >> --------------------​--------------------​--------------------​---------
>> >> To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org
>> >> For additional commands, e-mail: dev-help at propel dot tigris dot org
>> >>
>> >>
>> >
>> > --------------------​--------------------​--------------------​---------
>> > To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org
>> > For additional commands, e-mail: dev-help at propel dot tigris dot org
>> >
>>
>> --------------------​--------------------​--------------------​---------
>> To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org
>> For additional commands, e-mail: dev-help at propel dot tigris dot org
>>
>>
>
> --------------------​--------------------​--------------------​---------
> To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org
> For additional commands, e-mail: dev-help at propel dot tigris dot org
>

Re: [propel-dev] propel / c++

Reply

Author Roel Vanhout <roel dot vanhout at gmail dot com>
Full name Roel Vanhout <roel dot vanhout at gmail dot com>
Date 2006-07-24 06:19:26 PDT
Message I'll look into making a patch, but I'd rather not commit it myself - I
got yelled at once in another project a couple of years ago, now I'm a
bit hesitant to commit to codebases I'm not very familiar with :) I'll
let the list know. Thanks.

cheers,

roel


On 7/24/06, Hans Lellelid <hans at velum dot net> wrote:
> Hi Roel,
>
> I think we just need to change that behavior. Perhaps we should make a
> PHPOMBuilder subclass that holds any PHP specific stuff. I'll see if I
> can find a few minutes to look at that today. (Or, if you'd like to
> refactor that class, you can send me an email w/ username request for
> SVN and I'll make you an account.)
>
> Cheers,
> Hans
>
> Roel Vanhout wrote:
> > Hello Soenke,
> >
> > Thanks for your answer, this works for all classes that are in the
> > propel\generator\c​lasses\propel\engi​ne\builder\om\php​5 directory but
> > there is one file (OMBuilder.php) that is one directory higher. I
> > don't see it mentioned in the default.properties list of builders. In
> > this file, which defines the OMBuilder class, the <?php is added to
> > every file that is written out and it sets .cpp as extention for files
> > that are written, both of which I'd like to change. I don't see
> > however where I can indicate that my custom class should be used.
> >
> > cheers,
> >
> > roel
> >
> >
> > On 7/24/06, Soenke Ruempler <ruempler@topconc​epts.com> wrote:
> >> Roel Vanhout <mailto:roel.vanh​out at gmail dot com> wrote on Monday, July 24,
> >> 2006 12:50 PM:
> >>
> >> > I'm not sure if that was directed at the PECL thing or the pure C++
> >> > that I'm trying to accomplish :) , but either way: is there anyone who
> >> > knows the answer to my original question whether it is possible to use
> >> > another OMBuilder class? Thanks.
> >>
> >> Of course, in build.properties we have it like this:
> >>
> >> propel.builder.mapbuilder.class = tcc.Propel.Engine.Builder.Map
> >> propel.builder.object.class =tcc.Propel.Engine.B​uilder.ComplexObject​
> >> propel.builder.peer.class =tcs.Propel.Engine.B​uilder.ComplexPeer
> >>
> >> -soenke
> >>
> >> --------------------​--------------------​--------------------​---------
> >> To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org
> >> For additional commands, e-mail: dev-help at propel dot tigris dot org
> >>
> >>
> >
> > --------------------​--------------------​--------------------​---------
> > To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org
> > For additional commands, e-mail: dev-help at propel dot tigris dot org
> >
>
> --------------------​--------------------​--------------------​---------
> To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org
> For additional commands, e-mail: dev-help at propel dot tigris dot org
>
>

Re: [propel-dev] propel / c++

Reply

Author hlellelid
Full name Hans Lellelid
Date 2006-07-24 05:29:07 PDT
Message Hi Roel,

I think we just need to change that behavior. Perhaps we should make a
PHPOMBuilder subclass that holds any PHP specific stuff. I'll see if I
can find a few minutes to look at that today. (Or, if you'd like to
refactor that class, you can send me an email w/ username request for
SVN and I'll make you an account.)

Cheers,
Hans

Roel Vanhout wrote:
> Hello Soenke,
>
> Thanks for your answer, this works for all classes that are in the
> propel\generator\c​lasses\propel\engi​ne\builder\om\php​5 directory but
> there is one file (OMBuilder.php) that is one directory higher. I
> don't see it mentioned in the default.properties list of builders. In
> this file, which defines the OMBuilder class, the <?php is added to
> every file that is written out and it sets .cpp as extention for files
> that are written, both of which I'd like to change. I don't see
> however where I can indicate that my custom class should be used.
>
> cheers,
>
> roel
>
>
> On 7/24/06, Soenke Ruempler <ruempler@topconc​epts.com> wrote:
>> Roel Vanhout <mailto:roel.vanh​out at gmail dot com> wrote on Monday, July 24,
>> 2006 12:50 PM:
>>
>> > I'm not sure if that was directed at the PECL thing or the pure C++
>> > that I'm trying to accomplish :) , but either way: is there anyone who
>> > knows the answer to my original question whether it is possible to use
>> > another OMBuilder class? Thanks.
>>
>> Of course, in build.properties we have it like this:
>>
>> propel.builder.mapbuilder.class = tcc.Propel.Engine.Builder.Map
>> propel.builder.object.class =tcc.Propel.Engine.B​uilder.ComplexObject​
>> propel.builder.peer.class =tcs.Propel.Engine.B​uilder.ComplexPeer
>>
>> -soenke
>>
>> --------------------​--------------------​--------------------​---------
>> To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org
>> For additional commands, e-mail: dev-help at propel dot tigris dot org
>>
>>
>
> --------------------​--------------------​--------------------​---------
> To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org
> For additional commands, e-mail: dev-help at propel dot tigris dot org
>

Re: [propel-dev] propel / c++

Reply

Author Roel Vanhout <roel dot vanhout at gmail dot com>
Full name Roel Vanhout <roel dot vanhout at gmail dot com>
Date 2006-07-24 04:17:38 PDT
Message Hello Soenke,

Thanks for your answer, this works for all classes that are in the
propel\generator\c​lasses\propel\engi​ne\builder\om\php​5 directory but
there is one file (OMBuilder.php) that is one directory higher. I
don't see it mentioned in the default.properties list of builders. In
this file, which defines the OMBuilder class, the <?php is added to
every file that is written out and it sets .cpp as extention for files
that are written, both of which I'd like to change. I don't see
however where I can indicate that my custom class should be used.

cheers,

roel


On 7/24/06, Soenke Ruempler <ruempler@topconc​epts.com> wrote:
> Roel Vanhout <mailto:roel.vanh​out at gmail dot com> wrote on Monday, July 24,
> 2006 12:50 PM:
>
> > I'm not sure if that was directed at the PECL thing or the pure C++
> > that I'm trying to accomplish :) , but either way: is there anyone who
> > knows the answer to my original question whether it is possible to use
> > another OMBuilder class? Thanks.
>
> Of course, in build.properties we have it like this:
>
> propel.builder.mapbuilder.class = tcc.Propel.Engine.Builder.Map
> propel.builder.object.class =tcc.Propel.Engine.B​uilder.ComplexObject​
> propel.builder.peer.class =tcs.Propel.Engine.B​uilder.ComplexPeer
>
> -soenke
>
> --------------------​--------------------​--------------------​---------
> To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org
> For additional commands, e-mail: dev-help at propel dot tigris dot org
>
>

RE: [propel-dev] propel / c++

Reply

Author Soenke Ruempler <ruempler at topconcepts dot com>
Full name Soenke Ruempler <ruempler at topconcepts dot com>
Date 2006-07-24 04:07:02 PDT
Message Roel Vanhout <mailto:roel.vanh​out at gmail dot com> wrote on Monday, July 24,
2006 12:50 PM:

> I'm not sure if that was directed at the PECL thing or the pure C++
> that I'm trying to accomplish :) , but either way: is there anyone who
> knows the answer to my original question whether it is possible to use
> another OMBuilder class? Thanks.

Of course, in build.properties we have it like this:

propel.builder.mapbuilder.class = tcc.Propel.Engine.Builder.Map
propel.builder.object.class =tcc.Propel.Engine.B​uilder.ComplexObject​
propel.builder.peer.class =tcs.Propel.Engine.B​uilder.ComplexPeer

-soenke

Re: [propel-dev] propel / c++

Reply

Author Roel Vanhout <roel dot vanhout at gmail dot com>
Full name Roel Vanhout <roel dot vanhout at gmail dot com>
Date 2006-07-24 03:49:34 PDT
Message On 7/24/06, Soenke Ruempler <ruempler@topconc​epts.com> wrote:
> But it's a very interesting project, kepp on working!

I'm not sure if that was directed at the PECL thing or the pure C++
that I'm trying to accomplish :) , but either way: is there anyone who
knows the answer to my original question whether it is possible to use
another OMBuilder class? Thanks.

cheers,

roel

RE: [propel-dev] propel / c++

Reply

Author Soenke Ruempler <ruempler at topconcepts dot com>
Full name Soenke Ruempler <ruempler at topconcepts dot com>
Date 2006-07-24 03:11:41 PDT
Message Hi,

Pedram Nimreezi <mailto:zenstyle@​gmail.com> wrote on Saturday, July 22,
2006 6:40 PM:

> [..]

Propel trunk has already PDO support instead of creole, so you can use
it right now.

If you want to build C classes from your model, you have to port the
Propel base classes to C/C++, too - as C classes cannot extend / use
userland classes (IMHO).

But it's a very interesting project, kepp on working!

Re: [propel-dev] propel / c++

Reply

Author Pedram Nimreezi <zenstyle at gmail dot com>
Full name Pedram Nimreezi <zenstyle at gmail dot com>
Date 2006-07-22 13:28:27 PDT
Message Yeah it's cool and possible, I considered writing my framework as a PECL, I
actually did initially and then
decided to get it right as PHP and then consider a rewrite as a c/c++
version but its effectively
equivalent to hitting the NOS button on your PHP apps... and c is strikingly
similar to PHP so
you can do a profile of a request, spot the slow ass culprits and use your
existing PHP knowledge
to write an equivalent replacement.. unfortunately PECL documentation is
spotty at best, and
explaining it and writing is that much more difficult... I might make a
tutorial on it though if I were
prompted enough ;-)


On 7/22/06, Alan Pinstein <apinstein at mac dot com> wrote:
>
> Ok well that's cool then! I wasn't aware that it was possible.
> Alan
>
> On Jul 22, 2006, at 1:49 PM, Pedram Nimreezi wrote:
>
> It can... If it couldn't I couldn't for example.. make a Memcache Session
> Handler from the Memcache class
> provided by the Memcache PECL nor would it make sense to make for example
> a propel-gen-pecl-c++.
>
>
> On 7/22/06, Alan Pinstein <apinstein at mac dot com> wrote:
> >
> > SDO looks pretty interesting. Never heard of it.
> > However, I still don't think you answered my question.
> >
> > You proposed using propel-gen to create C++ classes for objects that
> > could be compiled as a PECL, to get the execution speed of C++ with the
> > flexibility of Propel.
> >
> > However, the propel generator creates a PHP object hierarchy, which you
> > then modify the Object.php and ObjectPeer.php classes with your business
> > logic.
> >
> > I am not aware of the ability to expose classes via PECL. All the times
> > I have used it, it can return objects that implement interfaces, but never
> > actual PHP classes that could be extended.
> >
> > For instance, if you use propel-gen-c++ to generate a MyObjectBase* as a
> > PECL, I don't think you can then, in PHP, do:
> >
> > class MyObject extends MyObjectBase
> > {
> > function customCode()
> > {
> > // do something
> > }
> > }
> >
> > I don't believe this is possible, but I am not certain. And if it's not,
> > the idea of propel-gen-c++ doesn't seem useful.
> >
> > I know you said that it was done in the links you sent, but I don't have
> > time to dig through piles of links and CVS trees looking for this example.
> > Feel free to provide a direct link showing how this is done.
> >
> > Thanks!
> > Alan
> >
> > On Jul 22, 2006, at 12:39 PM, Pedram Nimreezi wrote:
> >
> > Am I sure it would be a good idea? Well I do have at least *some*
> > evidence
> > I mean IBM hasn't really done open source PHP until they did SDO which
> > is
> > a C++ and PHP API similar in purpose and design to creole and propel,
> > SDO
> > is to PDO as propel is to creole, meaning SDO relies on PDO for its data
> > base
> > accessibility. PDO unlike creole is written in C (afaik). SDO unlike
> > propel in C++,
> > PDO and SDO unlike propel and creole must be installed into PHP either
> > statically
> > through ./configure or dynamically through phpize, moved to the location
> > specified in
> > php.ini as extension_dir = and loaded like you would a standard .dll or
> > .so extension.
> > SDO does not have "optionally" a script-able interface to itself from
> > PHP, it actually
> > requires it since SDO was never completely ported to C++ from PHP, or
> > they couldn't
> > find the time to write the remaining portions so those objects are
> > written in PHP 5, there
> > is no PHP 4 version as SDO remains completely dependent on PDO for
> > database access.
> > Therefore I think it would be a *good* idea because they can be similar
> > in speeds and propel
> > can obviously spit out PHP 4, PHP 5 and now C++, why not PECL? or why
> > not write the other
> > classes as PHP 4 and PHP 5 compatible and then refactor that into a PECL
> > so the only
> > scripting is done on initialization code, makes little sense not to
> > pursue this because *some*
> > people cannot personally install an extension in their web server which
> > would actually lower
> > the load on the server and increase the throughput for this *good* type
> > of programming.
> > I would just like to say that I don't use SDO, I use propel and
> > creole because I just like to,
> > I rewrote creole and propel to be PHP 4 AND PHP 5 compatible and like
> > that much better in
> > my "rapid" framework whose design includes things for SEO and SOA.
> > I've requested before at least for mine or the PHP 4 version be
> > dual licensed under LGPL
> > and BSD License, so that I can dual license MY framework under BSD
> > license as well, also
> > SDO is provided under much less restriction than the LPGL. I think
> > helping make these patterns
> > for advanced web application programming better and faster will help
> > everyone. I know I wouldn't
> > of had any reason to dedicate a couple years using propel and creole, or
> > want to be involved had
> > it not been for such good open source contributors like Hans, the PHP
> > user groups and yourself.
> >
> >
> > Ps, Here's a list of sites on the matter that may shed some light on SDO
> > and PECL implementations
> > where you can subclass classes and more. Don't forget to look all in the
> > CVS code and tests..
> >
> >
> > http://us2.php.net/sdo
> > http://www.zend.com/​pecl/tutorials/sdo.p​hp
> > http://www-128.ibm.c​om/developerworks/li​brary/os-sdophp/
> > http://en.wikipedia.​org/wiki/Metadata
> >
> >
> >
> >
> > On 7/22/06, Alan Pinstein < apinstein at mac dot com> wrote:
> > >
> > > Are you sure? Would you be able to subclass classes provided in PECL?
> > > One still needs to write custom business logic on their propel
> > > objects... how would that work?
> > >
> > > I don't know much about PECL so LMK!
> > >
> > > Alan
> > >
> > > On Jul 22, 2006, at 11:11 AM, Pedram Nimreezi wrote:
> > >
> > > Ok.. but making them as PECL's is a good idea too... I might do
> > > that...
> > >
> > >
> > >
> >
> >
> > --
> > ~
> > Pedram Nimreezi -- President/Senior Engineer
> > Major Computing, Inc
> > --
> >
> > Not by age, but by knowledge is wisdom acquired.
> >
> >
> >
>
>
> --
> ~
> Pedram Nimreezi -- President/Senior Engineer
> Major Computing, Inc
> --
>
> Not by age, but by knowledge is wisdom acquired.
>
>
>


--
~
Pedram Nimreezi -- President/Senior Engineer
Major Computing, Inc
--

Not by age, but by knowledge is wisdom acquired.
Attachments

Re: [propel-dev] propel / c++

Reply

Author Alan Pinstein <apinstein at mac dot com>
Full name Alan Pinstein <apinstein at mac dot com>
Date 2006-07-22 12:13:38 PDT
Message Ok well that's cool then! I wasn't aware that it was possible.

Alan

On Jul 22, 2006, at 1:49 PM, Pedram Nimreezi wrote:

> It can... If it couldn't I couldn't for example.. make a Memcache
> Session Handler from the Memcache class
> provided by the Memcache PECL nor would it make sense to make for
> example a propel-gen-pecl-c++.
>
>
> On 7/22/06, Alan Pinstein <apinstein at mac dot com> wrote:
> SDO looks pretty interesting. Never heard of it.
>
> However, I still don't think you answered my question.
>
> You proposed using propel-gen to create C++ classes for objects
> that could be compiled as a PECL, to get the execution speed of C++
> with the flexibility of Propel.
>
> However, the propel generator creates a PHP object hierarchy, which
> you then modify the Object.php and ObjectPeer.php classes with your
> business logic.
>
> I am not aware of the ability to expose classes via PECL. All the
> times I have used it, it can return objects that implement
> interfaces, but never actual PHP classes that could be extended.
>
> For instance, if you use propel-gen-c++ to generate a MyObjectBase*
> as a PECL, I don't think you can then, in PHP, do:
>
> class MyObject extends MyObjectBase
> {
> function customCode()
> {
> // do something
> }
> }
>
> I don't believe this is possible, but I am not certain. And if it's
> not, the idea of propel-gen-c++ doesn't seem useful.
>
> I know you said that it was done in the links you sent, but I don't
> have time to dig through piles of links and CVS trees looking for
> this example. Feel free to provide a direct link showing how this
> is done.
>
> Thanks!
> Alan
>
> On Jul 22, 2006, at 12:39 PM, Pedram Nimreezi wrote:
>
>> Am I sure it would be a good idea? Well I do have at least *some*
>> evidence
>> I mean IBM hasn't really done open source PHP until they did SDO
>> which is
>> a C++ and PHP API similar in purpose and design to creole and
>> propel, SDO
>> is to PDO as propel is to creole, meaning SDO relies on PDO for
>> its data base
>> accessibility. PDO unlike creole is written in C (afaik). SDO
>> unlike propel in C++,
>> PDO and SDO unlike propel and creole must be installed into PHP
>> either statically
>> through ./configure or dynamically through phpize, moved to the
>> location specified in
>> php.ini as extension_dir = and loaded like you would a
>> standard .dll or .so extension.
>> SDO does not have "optionally" a script-able interface to itself
>> from PHP, it actually
>> requires it since SDO was never completely ported to C++ from PHP,
>> or they couldn't
>> find the time to write the remaining portions so those objects are
>> written in PHP 5, there
>> is no PHP 4 version as SDO remains completely dependent on PDO for
>> database access.
>> Therefore I think it would be a *good* idea because they can be
>> similar in speeds and propel
>> can obviously spit out PHP 4, PHP 5 and now C++, why not PECL? or
>> why not write the other
>> classes as PHP 4 and PHP 5 compatible and then refactor that into
>> a PECL so the only
>> scripting is done on initialization code, makes little sense not
>> to pursue this because *some*
>> people cannot personally install an extension in their web server
>> which would actually lower
>> the load on the server and increase the throughput for this *good*
>> type of programming.
>> I would just like to say that I don't use SDO, I use propel
>> and creole because I just like to,
>> I rewrote creole and propel to be PHP 4 AND PHP 5 compatible and
>> like that much better in
>> my "rapid" framework whose design includes things for SEO and SOA.
>> I've requested before at least for mine or the PHP 4 version
>> be dual licensed under LGPL
>> and BSD License, so that I can dual license MY framework under BSD
>> license as well, also
>> SDO is provided under much less restriction than the LPGL. I think
>> helping make these patterns
>> for advanced web application programming better and faster will
>> help everyone. I know I wouldn't
>> of had any reason to dedicate a couple years using propel and
>> creole, or want to be involved had
>> it not been for such good open source contributors like Hans, the
>> PHP user groups and yourself.
>>
>>
>> Ps, Here's a list of sites on the matter that may shed some light
>> on SDO and PECL implementations
>> where you can subclass classes and more. Don't forget to look all
>> in the CVS code and tests..
>>
>>
>> http://us2.php.net/sdo
>> http://www.zend.com/​pecl/tutorials/sdo.p​hp
>> http://www-128.ibm.c​om/developerworks/li​brary/os-sdophp/
>> http://en.wikipedia.​org/wiki/Metadata
>>
>>
>>
>>
>> On 7/22/06, Alan Pinstein < apinstein at mac dot com> wrote:
>> Are you sure? Would you be able to subclass classes provided in PECL?
>>
>> One still needs to write custom business logic on their propel
>> objects... how would that work?
>>
>> I don't know much about PECL so LMK!
>>
>> Alan
>>
>> On Jul 22, 2006, at 11:11 AM, Pedram Nimreezi wrote:
>>
>>> Ok.. but making them as PECL's is a good idea too... I might do
>>> that...
>>
>>
>>
>>
>> --
>> ~
>> Pedram Nimreezi -- President/Senior Engineer
>> Major Computing, Inc
>> --
>>
>> Not by age, but by knowledge is wisdom acquired.
>>
>
>
>
>
> --
> ~
> Pedram Nimreezi -- President/Senior Engineer
> Major Computing, Inc
> --
>
> Not by age, but by knowledge is wisdom acquired.
Attachments

Re: [propel-dev] propel / c++

Reply

Author Pedram Nimreezi <zenstyle at gmail dot com>
Full name Pedram Nimreezi <zenstyle at gmail dot com>
Date 2006-07-22 10:49:06 PDT
Message It can... If it couldn't I couldn't for example.. make a Memcache Session
Handler from the Memcache class
provided by the Memcache PECL nor would it make sense to make for example a
propel-gen-pecl-c++.


On 7/22/06, Alan Pinstein <apinstein at mac dot com> wrote:
>
> SDO looks pretty interesting. Never heard of it.
> However, I still don't think you answered my question.
>
> You proposed using propel-gen to create C++ classes for objects that could
> be compiled as a PECL, to get the execution speed of C++ with the
> flexibility of Propel.
>
> However, the propel generator creates a PHP object hierarchy, which you
> then modify the Object.php and ObjectPeer.php classes with your business
> logic.
>
> I am not aware of the ability to expose classes via PECL. All the times I
> have used it, it can return objects that implement interfaces, but never
> actual PHP classes that could be extended.
>
> For instance, if you use propel-gen-c++ to generate a MyObjectBase* as a
> PECL, I don't think you can then, in PHP, do:
>
> class MyObject extends MyObjectBase
> {
> function customCode()
> {
> // do something
> }
> }
>
> I don't believe this is possible, but I am not certain. And if it's not,
> the idea of propel-gen-c++ doesn't seem useful.
>
> I know you said that it was done in the links you sent, but I don't have
> time to dig through piles of links and CVS trees looking for this example.
> Feel free to provide a direct link showing how this is done.
>
> Thanks!
> Alan
>
> On Jul 22, 2006, at 12:39 PM, Pedram Nimreezi wrote:
>
> Am I sure it would be a good idea? Well I do have at least *some* evidence
> I mean IBM hasn't really done open source PHP until they did SDO which is
> a C++ and PHP API similar in purpose and design to creole and propel, SDO
> is to PDO as propel is to creole, meaning SDO relies on PDO for its data
> base
> accessibility. PDO unlike creole is written in C (afaik). SDO unlike
> propel in C++,
> PDO and SDO unlike propel and creole must be installed into PHP either
> statically
> through ./configure or dynamically through phpize, moved to the location
> specified in
> php.ini as extension_dir = and loaded like you would a standard .dll or
> .so extension.
> SDO does not have "optionally" a script-able interface to itself from PHP,
> it actually
> requires it since SDO was never completely ported to C++ from PHP, or they
> couldn't
> find the time to write the remaining portions so those objects are written
> in PHP 5, there
> is no PHP 4 version as SDO remains completely dependent on PDO for
> database access.
> Therefore I think it would be a *good* idea because they can be similar in
> speeds and propel
> can obviously spit out PHP 4, PHP 5 and now C++, why not PECL? or why not
> write the other
> classes as PHP 4 and PHP 5 compatible and then refactor that into a PECL
> so the only
> scripting is done on initialization code, makes little sense not to pursue
> this because *some*
> people cannot personally install an extension in their web server which
> would actually lower
> the load on the server and increase the throughput for this *good* type of
> programming.
> I would just like to say that I don't use SDO, I use propel and
> creole because I just like to,
> I rewrote creole and propel to be PHP 4 AND PHP 5 compatible and like that
> much better in
> my "rapid" framework whose design includes things for SEO and SOA.
> I've requested before at least for mine or the PHP 4 version be dual
> licensed under LGPL
> and BSD License, so that I can dual license MY framework under BSD license
> as well, also
> SDO is provided under much less restriction than the LPGL. I think helping
> make these patterns
> for advanced web application programming better and faster will help
> everyone. I know I wouldn't
> of had any reason to dedicate a couple years using propel and creole, or
> want to be involved had
> it not been for such good open source contributors like Hans, the PHP user
> groups and yourself.
>
>
> Ps, Here's a list of sites on the matter that may shed some light on SDO
> and PECL implementations
> where you can subclass classes and more. Don't forget to look all in the
> CVS code and tests..
>
>
> http://us2.php.net/sdo
> http://www.zend.com/​pecl/tutorials/sdo.p​hp
> http://www-128.ibm.c​om/developerworks/li​brary/os-sdophp/
> http://en.wikipedia.​org/wiki/Metadata
>
>
>
>
> On 7/22/06, Alan Pinstein < apinstein at mac dot com> wrote:
> >
> > Are you sure? Would you be able to subclass classes provided in PECL?
> > One still needs to write custom business logic on their propel
> > objects... how would that work?
> >
> > I don't know much about PECL so LMK!
> >
> > Alan
> >
> > On Jul 22, 2006, at 11:11 AM, Pedram Nimreezi wrote:
> >
> > Ok.. but making them as PECL's is a good idea too... I might do that...
> >
> >
> >
>
>
> --
> ~
> Pedram Nimreezi -- President/Senior Engineer
> Major Computing, Inc
> --
>
> Not by age, but by knowledge is wisdom acquired.
>
>
>


--
~
Pedram Nimreezi -- President/Senior Engineer
Major Computing, Inc
--

Not by age, but by knowledge is wisdom acquired.
Attachments

Re: [propel-dev] propel / c++

Reply

Author Alan Pinstein <apinstein at mac dot com>
Full name Alan Pinstein <apinstein at mac dot com>
Date 2006-07-22 09:57:10 PDT
Message SDO looks pretty interesting. Never heard of it.

However, I still don't think you answered my question.

You proposed using propel-gen to create C++ classes for objects that
could be compiled as a PECL, to get the execution speed of C++ with
the flexibility of Propel.

However, the propel generator creates a PHP object hierarchy, which
you then modify the Object.php and ObjectPeer.php classes with your
business logic.

I am not aware of the ability to expose classes via PECL. All the
times I have used it, it can return objects that implement
interfaces, but never actual PHP classes that could be extended.

For instance, if you use propel-gen-c++ to generate a MyObjectBase*
as a PECL, I don't think you can then, in PHP, do:

class MyObject extends MyObjectBase
{
  function customCode()
  {
    // do something
  }
}

I don't believe this is possible, but I am not certain. And if it's
not, the idea of propel-gen-c++ doesn't seem useful.

I know you said that it was done in the links you sent, but I don't
have time to dig through piles of links and CVS trees looking for
this example. Feel free to provide a direct link showing how this is
done.

Thanks!
Alan

On Jul 22, 2006, at 12:39 PM, Pedram Nimreezi wrote:

> Am I sure it would be a good idea? Well I do have at least *some*
> evidence
> I mean IBM hasn't really done open source PHP until they did SDO
> which is
> a C++ and PHP API similar in purpose and design to creole and
> propel, SDO
> is to PDO as propel is to creole, meaning SDO relies on PDO for its
> data base
> accessibility. PDO unlike creole is written in C (afaik). SDO
> unlike propel in C++,
> PDO and SDO unlike propel and creole must be installed into PHP
> either statically
> through ./configure or dynamically through phpize, moved to the
> location specified in
> php.ini as extension_dir = and loaded like you would a
> standard .dll or .so extension.
> SDO does not have "optionally" a script-able interface to itself
> from PHP, it actually
> requires it since SDO was never completely ported to C++ from PHP,
> or they couldn't
> find the time to write the remaining portions so those objects are
> written in PHP 5, there
> is no PHP 4 version as SDO remains completely dependent on PDO for
> database access.
> Therefore I think it would be a *good* idea because they can be
> similar in speeds and propel
> can obviously spit out PHP 4, PHP 5 and now C++, why not PECL? or
> why not write the other
> classes as PHP 4 and PHP 5 compatible and then refactor that into a
> PECL so the only
> scripting is done on initialization code, makes little sense not to
> pursue this because *some*
> people cannot personally install an extension in their web server
> which would actually lower
> the load on the server and increase the throughput for this *good*
> type of programming.
> I would just like to say that I don't use SDO, I use propel
> and creole because I just like to,
> I rewrote creole and propel to be PHP 4 AND PHP 5 compatible and
> like that much better in
> my "rapid" framework whose design includes things for SEO and SOA.
> I've requested before at least for mine or the PHP 4 version
> be dual licensed under LGPL
> and BSD License, so that I can dual license MY framework under BSD
> license as well, also
> SDO is provided under much less restriction than the LPGL. I think
> helping make these patterns
> for advanced web application programming better and faster will
> help everyone. I know I wouldn't
> of had any reason to dedicate a couple years using propel and
> creole, or want to be involved had
> it not been for such good open source contributors like Hans, the
> PHP user groups and yourself.
>
>
> Ps, Here's a list of sites on the matter that may shed some light
> on SDO and PECL implementations
> where you can subclass classes and more. Don't forget to look all
> in the CVS code and tests..
>
>
> http://us2.php.net/sdo
> http://www.zend.com/​pecl/tutorials/sdo.p​hp
> http://www-128.ibm.c​om/developerworks/li​brary/os-sdophp/
> http://en.wikipedia.​org/wiki/Metadata
>
>
>
>
> On 7/22/06, Alan Pinstein < apinstein at mac dot com> wrote:
> Are you sure? Would you be able to subclass classes provided in PECL?
>
> One still needs to write custom business logic on their propel
> objects... how would that work?
>
> I don't know much about PECL so LMK!
>
> Alan
>
> On Jul 22, 2006, at 11:11 AM, Pedram Nimreezi wrote:
>
>> Ok.. but making them as PECL's is a good idea too... I might do
>> that...
>
>
>
>
> --
> ~
> Pedram Nimreezi -- President/Senior Engineer
> Major Computing, Inc
> --
>
> Not by age, but by knowledge is wisdom acquired.
>
Attachments

Re: [propel-dev] propel / c++

Reply

Author Pedram Nimreezi <zenstyle at gmail dot com>
Full name Pedram Nimreezi <zenstyle at gmail dot com>
Date 2006-07-22 09:39:42 PDT
Message Am I sure it would be a good idea? Well I do have at least *some* evidence
I mean IBM hasn't really done open source PHP until they did SDO which is
a C++ and PHP API similar in purpose and design to creole and propel, SDO
is to PDO as propel is to creole, meaning SDO relies on PDO for its data
base
accessibility. PDO unlike creole is written in C (afaik). SDO unlike propel
in C++,
PDO and SDO unlike propel and creole must be installed into PHP either
statically
through ./configure or dynamically through phpize, moved to the location
specified in
php.ini as extension_dir = and loaded like you would a standard .dll or .so
extension.
SDO does not have "optionally" a script-able interface to itself from PHP,
it actually
requires it since SDO was never completely ported to C++ from PHP, or they
couldn't
find the time to write the remaining portions so those objects are written
in PHP 5, there
is no PHP 4 version as SDO remains completely dependent on PDO for database
access.
Therefore I think it would be a *good* idea because they can be similar in
speeds and propel
can obviously spit out PHP 4, PHP 5 and now C++, why not PECL? or why not
write the other
classes as PHP 4 and PHP 5 compatible and then refactor that into a PECL so
the only
scripting is done on initialization code, makes little sense not to pursue
this because *some*
people cannot personally install an extension in their web server which
would actually lower
the load on the server and increase the throughput for this *good* type of
programming.
      I would just like to say that I don't use SDO, I use propel and creole
because I just like to,
I rewrote creole and propel to be PHP 4 AND PHP 5 compatible and like that
much better in
my "rapid" framework whose design includes things for SEO and SOA.
      I've requested before at least for mine or the PHP 4 version be dual
licensed under LGPL
and BSD License, so that I can dual license MY framework under BSD license
as well, also
SDO is provided under much less restriction than the LPGL. I think helping
make these patterns
for advanced web application programming better and faster will help
everyone. I know I wouldn't
of had any reason to dedicate a couple years using propel and creole, or
want to be involved had
it not been for such good open source contributors like Hans, the PHP user
groups and yourself.


Ps, Here's a list of sites on the matter that may shed some light on SDO and
PECL implementations
where you can subclass classes and more. Don't forget to look all in the CVS
code and tests..


http://us2.php.net/sdo
http://www.zend.com/​pecl/tutorials/sdo.p​hp
http://www-128.ibm.c​om/developerworks/li​brary/os-sdophp/
http://en.wikipedia.​org/wiki/Metadata




On 7/22/06, Alan Pinstein <apinstein at mac dot com> wrote:
>
> Are you sure? Would you be able to subclass classes provided in PECL?
> One still needs to write custom business logic on their propel objects...
> how would that work?
>
> I don't know much about PECL so LMK!
>
> Alan
>
> On Jul 22, 2006, at 11:11 AM, Pedram Nimreezi wrote:
>
> Ok.. but making them as PECL's is a good idea too... I might do that...
>
>
>


--
~
Pedram Nimreezi -- President/Senior Engineer
Major Computing, Inc
--

Not by age, but by knowledge is wisdom acquired.
Attachments

Re: [propel-dev] propel / c++

Reply

Author Alan Pinstein <apinstein at mac dot com>
Full name Alan Pinstein <apinstein at mac dot com>
Date 2006-07-22 08:34:07 PDT
Message Are you sure? Would you be able to subclass classes provided in PECL?

One still needs to write custom business logic on their propel
objects... how would that work?

I don't know much about PECL so LMK!

Alan

On Jul 22, 2006, at 11:11 AM, Pedram Nimreezi wrote:

> Ok.. but making them as PECL's is a good idea too... I might do
> that...
Attachments

Re: [propel-dev] propel / c++

Reply

Author Pedram Nimreezi <zenstyle at gmail dot com>
Full name Pedram Nimreezi <zenstyle at gmail dot com>
Date 2006-07-22 08:11:08 PDT
Message Ok.. but making them as PECL's is a good idea too... I might do that...

On 7/21/06, Roel Vanhout <roel dot vanhout at gmail dot com> wrote:
>
> No, I'm generating C++ to be used stand-alone. I like the way database
> access works with propel/php and I'd like to do the same in my C++
> applications. I'll 'port' as much of Propel & Creole to get it to work
> for sqlite databases, in standalone C++ applications, and only use php
> as 'generator language'.
>
> cheers,
>
> roel
>
>
> On 7/21/06, Pedram Nimreezi <zenstyle at gmail dot com> wrote:
> > Are you generating c++ classes to be used as php pecl's? I could maybe
> help
> > with that
> > targetPlatform could effectively be ignored with Zend Engine Version
> > detection in that regard...
> >
> >
> >
> >
> > On 7/21/06, Roel Vanhout <roel dot vanhout at gmail dot com> wrote:
> > >
> > Hi,
> >
> > I'm trying to get propel to generate c++ classes. I've progressed
> > nicely, but to do things neatly, I need a way to specify which
> > OMBuilder to use (I need to override build() and getClassFilePath()).
> > However I haven't yet found a way; is there a clean way to specify
> > that the factory should instantiate my CPP_OMBuilder and not OMBuilder
> > like there is for the other classes (like the other classes can be set
> > in the properties file)? If not, would you be willing to make it
> > configurable? In that case, I'd like to see that file
> > (generator\classes​propel\engine\bui​lder\om\OMBuilder.​php)
> > moved to
> > the php5/ subdirectoy, so that I could keep all language-specific
> > things in a separate directory.
> > Also, I noticed the following line in the default.properties:
> >
> > propel.targetPlatform = php5
> >
> > Can I leverage this to make generating c++ classes easier? What is it
> > used for? Thanks.
> >
> > cheers,
> >
> > roel
> >
> > --------------------​--------------------​--------------------​---------
> > To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org
> > For additional commands, e-mail: dev-help at propel dot tigris dot org
> >
> >
> >
> >
> > --
> > ~
> > Pedram Nimreezi -- Senior Engineer
> > Major Computing, Inc
> > --
> >
> > Not by age, but by knowledge is wisdom acquired.
>
> --------------------​--------------------​--------------------​---------
> To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org
> For additional commands, e-mail: dev-help at propel dot tigris dot org
>
>


--
~
Pedram Nimreezi -- Senior Engineer
Major Computing, Inc
--

Not by age, but by knowledge is wisdom acquired.
Attachments

Re: [propel-dev] propel / c++

Reply

Author Roel Vanhout <roel dot vanhout at gmail dot com>
Full name Roel Vanhout <roel dot vanhout at gmail dot com>
Date 2006-07-21 09:41:38 PDT
Message No, I'm generating C++ to be used stand-alone. I like the way database
access works with propel/php and I'd like to do the same in my C++
applications. I'll 'port' as much of Propel & Creole to get it to work
for sqlite databases, in standalone C++ applications, and only use php
as 'generator language'.

cheers,

roel


On 7/21/06, Pedram Nimreezi <zenstyle at gmail dot com> wrote:
> Are you generating c++ classes to be used as php pecl's? I could maybe help
> with that
> targetPlatform could effectively be ignored with Zend Engine Version
> detection in that regard...
>
>
>
>
> On 7/21/06, Roel Vanhout <roel dot vanhout at gmail dot com> wrote:
> >
> Hi,
>
> I'm trying to get propel to generate c++ classes. I've progressed
> nicely, but to do things neatly, I need a way to specify which
> OMBuilder to use (I need to override build() and getClassFilePath()).
> However I haven't yet found a way; is there a clean way to specify
> that the factory should instantiate my CPP_OMBuilder and not OMBuilder
> like there is for the other classes (like the other classes can be set
> in the properties file)? If not, would you be willing to make it
> configurable? In that case, I'd like to see that file
> (generator\classes​propel\engine\bui​lder\om\OMBuilder.​php)
> moved to
> the php5/ subdirectoy, so that I could keep all language-specific
> things in a separate directory.
> Also, I noticed the following line in the default.properties:
>
> propel.targetPlatform = php5
>
> Can I leverage this to make generating c++ classes easier? What is it
> used for? Thanks.
>
> cheers,
>
> roel
>
> --------------------​--------------------​--------------------​---------
> To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org
> For additional commands, e-mail: dev-help at propel dot tigris dot org
>
>
>
>
> --
> ~
> Pedram Nimreezi -- Senior Engineer
> Major Computing, Inc
> --
>
> Not by age, but by knowledge is wisdom acquired.

Re: [propel-dev] propel / c++

Reply

Author Pedram Nimreezi <zenstyle at gmail dot com>
Full name Pedram Nimreezi <zenstyle at gmail dot com>
Date 2006-07-21 09:30:52 PDT
Message Are you generating c++ classes to be used as php pecl's? I could maybe help
with that
targetPlatform could effectively be ignored with Zend Engine Version
detection in that regard...



On 7/21/06, Roel Vanhout <roel dot vanhout at gmail dot com> wrote:
>
> Hi,
>
> I'm trying to get propel to generate c++ classes. I've progressed
> nicely, but to do things neatly, I need a way to specify which
> OMBuilder to use (I need to override build() and getClassFilePath()).
> However I haven't yet found a way; is there a clean way to specify
> that the factory should instantiate my CPP_OMBuilder and not OMBuilder
> like there is for the other classes (like the other classes can be set
> in the properties file)? If not, would you be willing to make it
> configurable? In that case, I'd like to see that file
> (generator\classes​propel\engine\bui​lder\om\OMBuilder.​php) moved to
> the php5/ subdirectoy, so that I could keep all language-specific
> things in a separate directory.
> Also, I noticed the following line in the default.properties:
>
> propel.targetPlatform = php5
>
> Can I leverage this to make generating c++ classes easier? What is it
> used for? Thanks.
>
> cheers,
>
> roel
>
> --------------------​--------------------​--------------------​---------
> To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org
> For additional commands, e-mail: dev-help at propel dot tigris dot org
>
>


--
~
Pedram Nimreezi -- Senior Engineer
Major Computing, Inc
--

Not by age, but by knowledge is wisdom acquired.
Attachments

propel / c++

Reply

Author Roel Vanhout <roel dot vanhout at gmail dot com>
Full name Roel Vanhout <roel dot vanhout at gmail dot com>
Date 2006-07-21 09:11:01 PDT
Message Hi,

I'm trying to get propel to generate c++ classes. I've progressed
nicely, but to do things neatly, I need a way to specify which
OMBuilder to use (I need to override build() and getClassFilePath()).
However I haven't yet found a way; is there a clean way to specify
that the factory should instantiate my CPP_OMBuilder and not OMBuilder
like there is for the other classes (like the other classes can be set
in the properties file)? If not, would you be willing to make it
configurable? In that case, I'd like to see that file
(generator\classes​propel\engine\bui​lder\om\OMBuilder.​php) moved to
the php5/ subdirectoy, so that I could keep all language-specific
things in a separate directory.
Also, I noticed the following line in the default.properties:

propel.targetPlatform = php5

Can I leverage this to make generating c++ classes easier? What is it
used for? Thanks.

cheers,

roel
Messages per page: