Re: [Postfixadmin-devel] Moving towards 2.3......

[Christian B. <pos...@cb...>]

Hello,

Am Donnerstag, 2. April 2009 schrieb David Goodwin:
> This is just to make sure this mailing list isn't declared dead....

I'm alive, but (too) busy ;-)

> I've just committed a bug fix (I hope) to edit-alias.php so it
> respects the settings in $CONF (particularly special_alias_admin).
>
> Assuming this hasn't introduced any bugs (my limited testing here
> seems to indicate that it's fine....) I'll release rc4 (if that's the
> next one) within the next day or two (this is dependent on me hearing
> back from someone with regards to whether alias editing is now
> working correctly!).

You mean
https://sourceforge.net/tracker/?func=detail&aid=2745147&group_id=191583&atid=937964
? Good to see that I'm not the only one who creates blocker bugs shortly 
before a release ;-)

(Note: I didn't test this myself yet.)

> Development wise - I've pretty much stalled on my effort to integrate
> amavis support, however some busy people are migrating Postfixadmin
> 2.3 to use Smarty (see postfixadmin-smarty branch in subversion). I'm
> not quite sure where this will lead us yet - someone else is
> undertaking a zend framework migration - and the two will probably
> conflict a little...

Not necessarily - given we find some time to do the long-planned code 
redesign, it will be like switching skins in the best case.

I guess we'll have to do lots of abstraction work to keep both frontends 
in sync more or less automatically, but it is doable and might even 
save us time on the long run.

My favorite example: Adding a field for fetchmail.php:
1. add the field in the database / upgrade.php
2. add _one line_ to the fm_struct array
3. add the field title and description to the language files
4. (optional) use the field in fetchmail.pl
Done :-)

When we have all parts of postfixadmin editable in this easy way, 
changes will be easier than today. (This will probably also extremely 
speed up adding amavis support.)

Oh, and we'll need only two templates: "list view" and "edit view" (with 
subtemplates for different field types). These templates can be used 
for all modules - this gives us a common layout in all modules besides 
saving lots of work.

> (In that although you can use smarty with the 
> Zend Framework, it's probably best to stick with Zend_View - or will
> things like Zend_Layout work with Smarty?).

Good question - since I don't know the Zend framework and didn't do much 
with smarty yet, I have no idea.


Regards,

Christian Boltz
-- 
Microsoft is a cross between The Borg and the Ferengi. Unfortunately
they use Borg to do their marketing and Ferengi to do their programming.
                                               [Simon Slavin in the SDM]