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

Attachment: PGP.sig
Description: This is a digitally signed message part

_______________________________________________
PHPTAL mailing list
PHPTAL@lists.motion-twin.com
http://lists.motion-twin.com/mailman/listinfo/phptal

Reply via email to