plugins, multiple schema files & related tables

i think i am correct in saying that it is not possible for
propel to 
handle related tables that exist in different schema files.

i wonder if the propel-build-* commands could gather the
relevant 
schema.xml and .yml files and combine them before passing
the file 
contents to propel. this would enable us to write plugins
that can 
easily extend from the sfGuard user class and so on.

i feel the advantage of using a dao layer is lost if you can
not both 
seperate code into plugins/chunks and keep the ease of use
of 
relatedness in the layer.

feel free to tell me how to do this if i am wrong 

all the best
jason rowe








--
To unsubscribe, e-mail: dev-unsubscribesymfony-project.com
For additional commands, e-mail: dev-helpsymfony-project.com

HiJason

I supplied a patch that fixed this, r2051 and r2053, so you
can  
declare fks in seperate tables, and also override the
plugins  
schema.yml files by prefixing them with the pluginName-, and
placing  
this file in the projects config directory.

Fabien and i are working on a way that will allow you to
override the  
model classes as well, as these IMHO, should be generated in
the  
projects lib/model/pluginName directory instead of in the
plugin lib/ 
model directory, but including access to model methods
defined in the  
plugin.

Combine the above with the new sfMixin class (r2079), that
allows you  
to add methods to factory classes, and you will have a truly
 
extensible plugin system ;)

hope that helps

thanks

joe


On 17 Sep 2006, at 14:55, jason rowe wrote:

> i think i am correct in saying that it is not possible
for propel  
> to handle related tables that exist in different schema
files.
>
> i wonder if the propel-build-* commands could gather
the relevant  
> schema.xml and .yml files and combine them before
passing the file  
> contents to propel. this would enable us to write
plugins that can  
> easily extend from the sfGuard user class and so on.
>
> i feel the advantage of using a dao layer is lost if
you can not  
> both seperate code into plugins/chunks and keep the
ease of use of  
> relatedness in the layer.
>
> feel free to tell me how to do this if i am wrong 
>
> all the best
> jason rowe
>
>
>
>
>
>
>
>
> --
> To unsubscribe, e-mail: dev-unsubscribesymfony-project.com
> For additional commands, e-mail: dev-helpsymfony-project.com
>


--
To unsubscribe, e-mail: dev-unsubscribesymfony-project.com
For additional commands, e-mail: dev-helpsymfony-project.com

excellent news, thanks joe.

i look forward to checking it out,

jae.


Joe Simms wrote:
> HiJason
>
> I supplied a patch that fixed this, r2051 and r2053, so
you can 
> declare fks in seperate tables, and also override the
plugins 
> schema.yml files by prefixing them with the
pluginName-, and placing 
> this file in the projects config directory.
>
> Fabien and i are working on a way that will allow you
to override the 
> model classes as well, as these IMHO, should be
generated in the 
> projects lib/model/pluginName directory instead of in
the plugin 
> lib/model directory, but including access to model
methods defined in 
> the plugin.
>
> Combine the above with the new sfMixin class (r2079),
that allows you 
> to add methods to factory classes, and you will have a
truly 
> extensible plugin system ;)
>
> hope that helps
>
> thanks
>
> joe
>
>
> On 17 Sep 2006, at 14:55, jason rowe wrote:
>
>> i think i am correct in saying that it is not
possible for propel to 
>> handle related tables that exist in different
schema files.
>>
>> i wonder if the propel-build-* commands could
gather the relevant 
>> schema.xml and .yml files and combine them before
passing the file 
>> contents to propel. this would enable us to write
plugins that can 
>> easily extend from the sfGuard user class and so
on.
>>
>> i feel the advantage of using a dao layer is lost
if you can not both 
>> seperate code into plugins/chunks and keep the ease
of use of 
>> relatedness in the layer.
>>
>> feel free to tell me how to do this if i am wrong

>>
>> all the best
>> jason rowe
>>
>>
>>
>>
>>
>>
>>
>>
>> -- 
>> To unsubscribe, e-mail: dev-unsubscribesymfony-project.com
>> For additional commands, e-mail: dev-helpsymfony-project.com
>>
>
>
> -- 
> To unsubscribe, e-mail: dev-unsubscribesymfony-project.com
> For additional commands, e-mail: dev-helpsymfony-project.com
>
>
>
>



--
To unsubscribe, e-mail: dev-unsubscribesymfony-project.com
For additional commands, e-mail: dev-helpsymfony-project.com