[symfony-devs] sfThumbnailPlugin autocropping

I wrote a litte batch for the sfThumbnailPlugin, it now can also be used to autocrop images with 3 parameters: crop (true,false) : enables autocropping and overrides scale cropVAlign(top,middle,bottom): like css for position of the croparea in the source image cropAlign(left,center,right): like cs

[symfony-devs] Re: The new symfony CLI system

Being a CLI system, it does not and even cannot offer such functionality due to the design. Andrejs -Original Message- From: symfony-devs@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Thierry Sent: Friday, July 27, 2007 10:46 PM To: symfony developers Subject: [symfony-devs] Re

[symfony-devs] Re: The new symfony CLI system

When you type just propel without the :build-all you should prompt the user with an interface to select the desired command this would ease the learning process for beginners --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google

[symfony-devs] i18n and POST method bug?

Have a look at the following example in /content module. public function executeContact() { if ($this->getRequest()->getMethod() != sfRequest::POST) { $this->_contactSetContent(); // display the form return sfView::SUCCESS; } $this->sendEmail('email', 'co

[symfony-devs] Re: About the Controller refactoring

Hi, today I commited the recent changed of my controller stuff: http://trac.symfony-project.com/trac/changeset/4734 Key changes compared to trunk are: - Moved sfFrontWebController->dispatch() to sfWebController and separated the actual dispatching into an own execute() method to make it possibl

[symfony-devs] Re: The new symfony CLI system

I have one project using both doctrine & propel, so they can co-exist. On 7月27日, 下午11時09分, "Javier Eguiluz" <[EMAIL PROTECTED]> wrote: > Hi Fabien, > > Regarding database tasks, I don't know if it could be possible to group all > tasks under a generic "db" namespace (like Rake >

[symfony-devs] Re: The new symfony CLI system

I believe aliases should be better for that. For example, keep propel:data-load, and make an alias to db:data-load according to what your ORM preferences are. On Jul 27, 12:09 pm, "Javier Eguiluz" <[EMAIL PROTECTED]> wrote: > Hi Fabien, > > Regarding database tasks, I don't know if it could be p

[symfony-devs] Re: The new symfony CLI system

Hi Fabien, Regarding database tasks, I don't know if it could be possible to group all tasks under a generic "db" namespace (like Rake of Ruby on Rails). Then, symfony CLI should automatically detect if the project uses Propel or Doctri

[symfony-devs] Re: The new symfony CLI system

And you can type: ./symfony list propel to only display the tasks in the Propel namespace. Fabien P.S.: I've just renamed help-summary to list. Dave Dash wrote: > I like the name-spacing as it makes it easier to follow. Especially > when plugins start adding their tasks, e.g. doctrine. We

[symfony-devs] Re: The new symfony CLI system

I like the name-spacing as it makes it easier to follow. Especially when plugins start adding their tasks, e.g. doctrine. We can be sure that doctrine:* are all related to the sfDoctrinePlugin. On 7/27/07, Fabien POTENCIER <[EMAIL PROTECTED]> wrote: > > > As I'm in the process of polishing the n

[symfony-devs] The new symfony CLI system

As I'm in the process of polishing the new symfony CLI, I want to change some symfony tasks to more meaningful names. Old names will still be available as aliases. In the new symfony CLI, tasks can be bundled in namespaces. For example, all Propel tasks are under a propel namespace. So instead

[symfony-devs] Re: debug toolbar with trunk

Yes, the goal is keep the old form handling system in symfony 1.1 and drop it for symfony 1.2. Fabien Matthias N. wrote: > On 26 Jul., 21:00, Fabien POTENCIER <[EMAIL PROTECTED]> > wrote: >> The symfony trunk is and will be a bit unstable for the next couple of >> weeks especially when I will b

[symfony-devs] Re: debug toolbar with trunk

There is no page giving the roadmap for symfony 1.1 and it can still evolve. But here are some points that will be addressed in symfony 1.1: - Refactoring of the symfony CLI All tasks will be converted to classes. pake dependency will be removed as we don't use the "make" like features. pake w

[symfony-devs] Re: debug toolbar with trunk

Fabien POTENCIER wrote: > I will begin the refactoring of the form handling layer. Just FMI is it planned to handle validation at a model or something approching level in core features of Symfony 1.1 (like in the sfPropelValidateBehavior plugin) ? Another question, does a /precise/ roadmap pa

[symfony-devs] Re: debug toolbar with trunk

On 26 Jul., 21:00, Fabien POTENCIER <[EMAIL PROTECTED]> wrote: > The symfony trunk is and will be a bit unstable for the next couple of > weeks especially when I will begin the refactoring of the form handling > layer. So, perhaps there is a problem with the web debug toolbar > position, this is q

[symfony-devs] Re: debug toolbar with trunk

On 26 Jul., 21:00, Fabien POTENCIER <[EMAIL PROTECTED]> wrote: > The symfony trunk is and will be a bit unstable for the next couple of > weeks especially when I will begin the refactoring of the form handling > layer. So, perhaps there is a problem with the web debug toolbar > position, this is q