Hi :) I know exactly where you're coming from and the reason we've re-worked both Zend Views and Zend Forms is specifically to both separate template from php and to make the use of the modules such as Zend Form much more optional :) Within Zend, Form and View are a weird (and not, in my opinion, very MVC) mix of php and html and if you use a View or a Form you are pretty much stuck with doing things the 'Zend' way.
Our take is to replace Zend View entirely with PHPTal and split Zend Form into 2 parts - the logic and the rendering. The logic for Zend Form is the same as in 'normal' Zend and validation and filtering of form elements works as expected. The rendering has been moved to PHPTal and you simply hand a Zend Form instance to a top-level macro to actually do the rendering. If at any point you wish to render a form manually or create a compatible alternative to Zend Form for your own needs this is all possible. It is also possible to specify an alternative macro for individual form elements to override the default - if you wish to do things slightly different for just one form or just one element :) As a side note, we've also integrated Zend_Translate support into PHPTal and created a number of Tales to support plural translations and rendering various Zend elements such as Dates. Robert On 3 Aug 2010, at 09:34, Richard Dyce wrote: > Robert, > > That sounds very interesting, I'll look forward to seeing it. > > I've had a few private emails from people suggesting php pre-rendering with > structures, or using Zend Forms. I thought I should make it clear that the > reason that I'm not looking to go down that path is that that's where I've > come from. (The framework I've been using has 'foxels' analagous to pixels, > which are form elements that can be built using array specs, but which have > renderers for html, xml and json.) This makes it really easy to create lots > of forms where there aren't isn't the need for heavy single-form specific > coding. The benefit I see of doing it this way is that it makes it easier to > create highly complex one-off forms within the system using specific > templates, but to have a generalised forms to hand for most of the rest... > without having to change the backend logic. > > Hope that's as clear as mud... > > On 3 Aug 2010, at 08:39, Robert Goldsmith wrote: > >> Hi all, >> >> Well, we here at Namesco are working hard to get a release package together >> for the Zend/PHPTal integration 'glue' we've developed for our own internal >> codebase (which we've called ZTal) and this has full integration with >> Zend_Form. As such it includes a large number of macros for rendering >> different form elements - although, of course, they expect to be given a >> Zend_Form object :) Even if you are not using Zend it should be reasonably >> easy to re-use the macros :) >> >> The code is ready but the documentation is rather lacking so at a guess I'd >> say it will be a few days before we release. I'll obviously let everyone >> know when everything is live :) >> >> Robert > > > > _______________________________________________ > PHPTAL mailing list > PHPTAL@lists.motion-twin.com > http://lists.motion-twin.com/mailman/listinfo/phptal
Description: This is a digitally signed message part
_______________________________________________ PHPTAL mailing list PHPTAL@lists.motion-twin.com http://lists.motion-twin.com/mailman/listinfo/phptal