Glad to know I'm on the right track - or at least there are others out there with the same prejudices!
Btw, I'm not that bothered about waiting for documentation :-))) R On 3 Aug 2010, at 09:53, Robert Goldsmith wrote: > 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 > > _______________________________________________ > PHPTAL mailing list > PHPTAL@lists.motion-twin.com > http://lists.motion-twin.com/mailman/listinfo/phptal _______________________________________________ PHPTAL mailing list PHPTAL@lists.motion-twin.com http://lists.motion-twin.com/mailman/listinfo/phptal
