I've a question.
Next month I'll have some free time and I'd like to do a completely different version of the code that auto-generates the CRUD forms. I work with very intelligent graphic designers, and they want full control of the HTML and CSS, so its important to us that we have auto- generating CRUD tools that don't generate any HTML inside of PHP methods. I explained my reasoning in these two posts: http://www.category4.com/2007/01/03/whats-wrong-with-commerical-web-application-frameworks/ http://www.category4.com/2007/01/02/the-problem-with-php-frameworks/ So how easy is this to do with Symfony? I know Ruby On Rails has multiple scaffolding projects, both the default one that is built-in, and then a half dozen others that are run as separate open-source projects. With Symonfy, where do I start, to override the default output of the Propel CRUD auto-generation tools? On Feb 12, 2:33 pm, isleshocky77 <[email protected]> wrote: > I wanted to one throw my support behind this idea because I agree with > it and I was just about to recommend the same thing in a ticket but > decided to do a search first. > > Two, I wanted to know if anyone has a way currently of setting the > class attribute of the label tag with the the current 1.2.5-dev other > than rendering the that row individually. I'm looking at the code and > looks like it is impossible because the ->renderLabel() called from > within renderRow() of sfFormField.class.php does not pass along > attributes at all. > > Thanks for any help with this. > > -- > Stephen Ostrow <[email protected]> > > On Feb 9, 3:43 am, Fabien Potencier <fabien.potenc...@symfony- > > project.com> wrote: > > Can you create an enhancement ticket for each issue? > > > Thanks, > > Fabien > > > -- > > Fabien Potencier > > Sensio CEO - symfony lead developer > > sensiolabs.com | symfony-project.org | fabien.potencier.org > > Tél: +33 1 40 99 80 80 > > > avorobiev wrote: > > > Also in the Form framework we need built-in: > > > > - Required asterisk. > > > Today we can do it with overloading BaseForm and > > > sfWidgetFormSchemaFormatter (look at > > >http://groups.google.com/group/symfony-devs/browse_thread/thread/4c81...), > > > but it's not a clean way... If we have possibility to set asterisk as > > > a css class on the parent html-container, or as a class on the input| > > > select tag, that will be good! > > > > - Field groups. > > > It often use in form decoration. If we have $form->render() function > > > why we can't use it for rendering form field groups? > > > In the form class we would set groups for example so: > > > > $this->setWidgets(array( > > > 'fieldGroupName1' => array(sfWigget classes), > > > 'fieldGroupName2' => array(some other sfWigget classes), > > > and other sfWigget classes without field group > > > ) > > > > On Feb 5, 6:02 pm, Tom Boutell <[email protected]> wrote: > > >> Symfony 1.2 offers several levels of control over templates for forms. > > >> In practice, though, only two are useful: > > > >> 1. echo $form > > > >> Handy for quick and dirty testing and for situations where a pure and > > >> simple columnar layout enhanced a bit by CSS is acceptable. But all of > > >> the rows have to be styled in exactly the same way because there is no > > >> individual CSS access to them. > > > >> 2. echo $form['fieldname']->renderLabel(), > > >> $form['fieldname']->render(), $form['fieldname']->renderErrors() > > > >> Allows complete control over the HTML surrounding the row. But you > > >> pretty much have to do it for the entire form, or else do something > > >> ungainly like: > > > >> while (($key, $dummyl) = each($form)) > > >> { > > >> if ($key == 'foo') > > >> { > > >> special handling; > > >> } > > >> else > > >> { > > >> $key->renderRow(); > > >> } > > > >> } > > > >> But what about $form->render(), which can accept a hash of widget > > >> names and HTML attributes for them? What about $form->renderRow(), > > >> which can also do that? > > > >> The problem is that both of these methods only accept attributes for > > >> the widget control itself (the 'input' element, for instance). And > > >> this is not especially useful, because what we typically want to do is > > >> influence the layout of controls relative to one another. But we don't > > >> have any influence over the <tr> or <li> elements the input elements > > >> are embedded in. So we're stuck going all the way to the lowest level. > > > >> I believe ->render() and ->renderRow() would be much more useful if > > >> they accepted attributes intended for the formatting element that > > >> contains the row, not just the attribute itself. > > > >> Then you could write: > > > >> $form->render(array('editors' => array('rowAttributes' => > > >> array('class' => 'floating-column')))); > > > >> ... To set a class on the <li> that encloses that particular row, > > >> allowing meaningful influence over the layout. > > > >> Similar provisions for labelAttributes and errorsAttributes would also > > >> be helpful. > > > >> (It would be nice if grandparent selectors worked in CSS, but they > > >> don't - you really can't look "up the tree" and change the layout of > > >> the element that your input element is contained in. So classes on the > > >> input element are not very useful in laying out a form.) > > > >> -- > > >> Tom Boutell > > > >>www.punkave.comwww.boutell.com --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
