The placement of BaseFormFilterPropel.class.php seems like a bug that  
needs to be fixed in symfony >= 1.2. Or is there a BC concern I'm not  
seeing?

Thanks,
Kris

--

Kris Wallsmith | Release Manager
[email protected]
Portland, Oregon USA

http://twitter.com/kriswallsmith

On Aug 10, 2009, at 3:30 PM, Jake Press wrote:

>
> Hi Evrard
>
> We have had a similar idea, however it would be much better if the
> solution was transparent - having to remember to run a specialized  
> task
> for generation would become problematic over multiple devs/projects.
> If only task namespace/command's could be overloaded.
>
> You might be interested in another thread I started "additional  
> built-in
> events", I am hoping to have something like "task.post_execute" and
> "task.pre_excecute" events added.
> Then we could have our own task work in addition to the std propel  
> ones
> perhaps :)
>
> All of this said, jees this is a lot of work to work-around such a
> simple bug.
> If you see the patch I submitted, it's a 2 line fix haha
>
>
> Cheers for your thoughts
>
> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]] On Behalf Of Evrard Pierrot
> Sent: Tuesday, August 11, 2009 7:20 AM
> To: [email protected]
> Subject: [symfony-devs] Re: work around for incorrectly placed
> BaseFormFilterPropel class
>
>
> Hi,
>
> I've done a lot of stuff by customizing my propel object forms and
> filters generation, so you should be able to customize files that are
> provide by the tasks propel:build-forms and propel:build-filters, but
> this is not an easy way, sorry.
>
> Note that propel forms and filters are generated helping symfony PHP
> generator system, and have nothing except models from Propel.
>
> First step is to create an new task that extends the current task (by
> example propel-extended:build-forms or propel:build-extended-forms).
>
> At this point you can already add some arguments to manage later, as a
> --theme argument (I were doing that just to give abilities to set the
> theme files for generator) that you can pass to the generator manager.
>
> At second step, especially because the current generator does not used
> theme (most generators can already manage different theme, but in this
> case, the generator does not care about the "theme" parameter), you
> must create a new generator that extends the current one.
>
> At this point, you will be able to have your own theming, and, one of
> the most important thing, your own way to manage widgets, validators
> and them options (that was my first purpose, especially to not
> generate updated_at and created_at as date input).
>
> As I told earlier, this is not an easy way, but it does really more
> that you expect.
>
> For example, I've customized the propel filters generation to
> automatically provide a "Search" field that look for the given string
> in every varchar fields of the model.
>
>
> Loops
>
> PS : If you wish some sample files and structure, just let me know.
>
>
>
> >


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"symfony developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/symfony-devs?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to