Re: [Postfixadmin-devel] Postfixadmin 2.4

[reg9009 <re...@ya...>]

Christian Boltz schrieb:
> Same from me - feel free to merge it into trunk.
>
>   
ok, I'll do! ;)

> If possible, do a separate commit for the smarty (upstream) code and one 
> for the postfixadmin-related code. This should result in better readable 
> commit mails ;-)
>
>   
I'll try, but as of smarty, it's just a subfolder within root, so it
should be easy to separate. Updates of smarty are easy, just update the
subfolder.
> I didn't look too close at the smarty branch yet (will do when it's in 
> trunk), but I found one issue already:
>
> Your fetchmail template doesn't exactly match the current fetchmail 
> template, even if the resulting HTML looks the same.
> - the current (PHP) template loops over all fields and prints them using 
>   helper functions (per field type, for example "text input" or 
>   "dropdown list")
> - your smarty template contains a more "traditonal" code where each 
>   field is listed separately - at least for displaying the list view.
> - for the edit form, you are using PHP-functions to handle the loops 
>   which is already better, but - can this be changed to smarty code?
>   
I'll have a look. Usually all is done by smarty. Which edit forms do you
mean exactly?
> The advantage of looping over all fields is that it's very easy to add 
> additional fields:
> 1. add the column to the database
> 2. add one line in the $fm_struct array in fetchmail.php
> 3. (optional:) add a line to the $fm_defaults array
> 4. be happy ;-)
>
> It would be good if the smarty template could work the same way, because 
> I want to change all parts of postfixadmin to use a similar way on the 
> long term. (We could then even have common templates for _all_ lists and 
> _all_ edit forms, independent of what to edit or list.)
>
>   
It does. Usually, you assign the array to a smarty array variable. If
you add another filed into it, just use it in the smarty template.

> I think the best solution to do this is to have a template named 
> "common-edit.tpl" (and one named common-list.tpl). 
> It should still be possible to handle some fields in a special way.
>
> The common-edit.tpl could look like this (pseudocode, I still have to 
> learn smarty):
>
> if ($table == foo and $fieldname == bar) # special field handling
>     echo "<td>special field handling</td><td><input type=..."/></td>"
> [... more special handling if needed ...]
> elseif ($fieldtype == text)
>     echo "<td>$label</td><td><input type="text" name="$field"/></td>"
> elseif ($fieldtype == dropdown)
> ...
> else # default for unknown field types
>     echo "<td>$label</td><td><input type="text" name="$field"/></td>"
>
>   
You achieved quite the language already, just leave the echo's...

Me personally, I would keep the templates separated. I like to have as
much logic in the PHP files and just some logic for the displaying part
in smarty itself. But you can include template files within template
files, e.g. in an if-statement.
> This is nothing that blocks the merge to trunk, but please change the 
> fetchmail template to behave this way. (When this is done, we can change 
> more parts to use the common-* templates.)
>
>   
OK.
>> I know cboltz and I have made a few minor changes to trunk since the
>> 2.3 release, so I guess your branch is slightly out of date in that
>> respect.
>>     
>
> My yesterday's commit probably doesn't qualify as "minor change" ;-)
> (but it doesn't change too much in the template)
>
> BTW: your mail address suggests you are living in germany. Where 
> exactly? (I live in the "Pfalz", in Insheim to be exact.)
>
>
>   
Yes, good old Frankfurt...

And I'm a fan of old (and old school) Riesling, btw.
> Regards,
>
> Christian Boltz
>   
Regards,
Sebastian