Login | Register
My pages Projects Community openCollabNet

Discussions > dev > Re: [propel-dev] roadmap > Reply to message

Reply to message

* = Required fields
* Subject
* Body
Send reply to
Author (directly in email)
Please type the letters in the image above.

Original message

Author hlellelid
Full name Hans Lellelid
Date 2006-03-28 07:28:05 PST
Message Soenke Ruempler wrote:
> Hi Hans,
> Hans Lellelid <mailto:hans at velum dot net> wrote on Tuesday, March 28, 2006
> 4:50 PM:
>> I put together a Roadmap wiki page:
>> http://propel.phpdb.​org/trac/wiki/Develo​pment/Roadmap
>> I incorporated some things David & I have discussed in the
>> past, but at
>> this point it's more of a discussion than a finalized plan, so please
>> feel free to use the comment feature to post suggestions of features
>> you'd like to see (and hopefully help implement) in future
>> development.
>> I also added a Criteria page (linked from Roadmap) to discuss some of
>> the things that need attention in current Criteria API. We
>> can add new
>> pages to think through issues like identifier quoting & identity
>> map/"cache" stuff too. Oscar & Cameron, feel free to add
>> pages -- e.g.
>> Development/IdentifierQuoting, Development/IdentityMap -- to
>> outline how
>> these systems could be implemented; it might be helpful to have some
>> single points of reference that aggregates & addresses our what-if
>> concerns with these solutions.
> I'd like to add two points:
> * Utilizing dynamic __call/__get/__set in BaseObject/BasePeer classes
> and kill much generated code from the Object/Peer classes for
> get*/set*/add*
> * Making the copy() method more flexibel (limiting the level of
> deepcopy, adding table-excludes)
> If noone dislikes this I'll add two dev discussion pages to the wiki.

Adding the pages sounds good to me. The only concern I have (which I
can mention in comments on wiki too) is that certain methods (temporal
methods) take additional parameters -- which might present a problem
__call/__get/__set, unless we just standardize on an API that does not
support these. Just something to discuss.

We may also want to have the "lightweight" OM classes be an option.
It'd be nice to have several different options for types of classes to
generate, but I also recognize that these would have to be maintained :)