headers
Thomas Koch | 2 Feb 2007 09:54
Picon

On templates

It's much fun to play around with ezc, but sooner or later you've to present 
sth. to the user. Writing forms by hand sucks. A simple adressbuch which 
takes nearly all possible content of a vCard takes at least six tables. 
The main table subject already contains the columns:
'additional_names', 'birthday', 'family_name', 'fn', 'given_name', 'honorific_prefixes',
'honorific_suffixes', 'id', 'last_modified', 'note', 'organization', 'role', 'room', 'title'

So I need a possibility to create forms more easily then just plain HTML. An 
answere could be to create some kind of custom block:

{field "family_name"}
The custom block now looks up the model definition, where it finds information 
about the descriptive name of the field, the input type, maybe values for a 
select-box or a REQUIRED/OPTIONAL flag. This approach could also allow the 
creation of a view and an edit form from the same source.

Problem: custom blocks are not hardcoded in the compiled template, but 
executed on runtime. But it's to expensive to lookup all these informations 
on runtime.

So right now, I ask myself, which advantage I have by using templates instead 
of writing good old PHP. You know the discussion, that PHP itself already is 
a template language.

One general question: isn't it kind of insane, to write a compiler to output a 
scripting language? Please don't take this doubt to serious...

Right now I think about writing a script, which analyzes my model and writes 
templates for the list, view and edit templates. But isn't that even more 
insane?
(Continue reading)

Permalink | Reply | 4 comments |
headers
Derick Rethans | 2 Feb 2007 10:01
X-Face
Picon
Favicon
Gravatar

Re: On templates

On Fri, 2 Feb 2007, Thomas Koch wrote:

> P.s. Only for gerneral interest: In PHP most people use the Smary 
> Syntax with {...}. Viewing and editing this templates in HTML editors 
> isn't nice. There's another approch in ZOPE/Plone with TAL: All the 
> tempate directives are attributes. This way, viewing the template in a 
> browser could give a much better impression of the final result and is 
> still valid XHTML!

We discussed using TAL when we were designing the Template engine. One 
of the reasons why we didn't go for this is that it has some issues (I 
don't remember which) for some constructs, and another one is that the 
syntax is not familiar by many PHP and eZ publish users.

regards,
Derick
Permalink | Reply | 0 comments |
headers
Thomas Koch | 2 Feb 2007 21:02
Picon

writing nicer models

There's an issue about a writer for model classes like there already is for 
PO-Defs. I have another proposal. See the attached abstract model. By 
implementing it, your model class only needs to contain

private static $PROPERTIES = array('additionalNames', 
                                       'birthday', 
                                        ....
                                       'title' );

and you're done. 
I also wrote a script based on PODBTieIn which prints all the properties of 
all tables of a schema. So you can easily copy'n'paste them in you're model.

Thomas Koch

abstract class egwBaseModel
{
    public $_properties = array();

    public function getState()
    {
        return $_properties;
    }

    public function setState( array $properties )
    {
        $this->_properties = $properties;
    }

    public function __set( $name, $value )
(Continue reading)

Permalink | Reply | 2 comments |
headers
Alexandru Stanoi | 5 Feb 2007 12:13
Picon
Favicon

[Authentication] Please share your ideas about the new Authentication component

Hello,

Soon I will start working on the new Authentication component and I will 
need some input. I am sending this now so there is time for discussion 
before I start.

The comments I have so far are from Stefan Marr (see 
http://issues.ez.no/IssueView.php?Id=9922&activeItem=1), Thomas Koch 
(mail from Dec 22 - 
http://lists.ez.no/pipermail/components/2006-December/002052.html), 
Ammar Ibrahim and Falko Menge (in reply to Thomas' mail).

Questions on which I would like some input:
1. What should the Authentication component do?
2. Is it going to be used by other components which require 
authentication (like Mail, Database)? But that will create a dependency 
between components.
3. How are the passwords going to be stored? Using Database will create 
another dependency.

Thanks,
Alex.

--

-- 
Alex Stanoi
eZ Components System Developer
eZ Systems | http://ez.no
Permalink | Reply | 2 comments |
headers
Frederik Holljen | 5 Feb 2007 12:20
X-Face
Picon
Favicon

Re: [Authentication] Please share your ideas about the new Authentication component


> Questions on which I would like some input:
> 1. What should the Authentication component do?
- session management? (or is that a separate component.. it is definately 
related...)

> 2. Is it going to be used by other components which require
> authentication (like Mail, Database)? But that will create a dependency
> between components.
I'd say no.

> 3. How are the passwords going to be stored? Using Database will create
> another dependency.
Doesn't really matter to me as long as it supports extending the system.

Frederik
Permalink | Reply | 1 comment |
headers
Thomas Koch | 5 Feb 2007 13:13
Picon

Re: [Authentication] Please share your ideas about the new Authentication component

Well christmas is coming. So my wishlist:

* Supported Backends to validate username/password pairs: Database, LDAP, ADS, 
PAM, Config File, Kerberos. HTTP, Systems with chipcards, usb-sticks, 
certificates, RFID-Cards, ... Mail-Server? SAP Server (Pear::Auth does)?
* If supported by the backend: changing my own password or let an admin change 
user passwords
* Store the password so that the application can access it. e.g. to sign in 
into a mail server.
* Support to migrate a userbase from one auth method to ezc. i.g. if not 
already in the primary ezc auth system, lookup in another system and create 
the user account in the primary system in case.

The auth component shouldn't by tied with configuration or permission 
management, as this could be different with every application. So the auth 
component does only:
* give the information, if a user with a given id/pass pair exists and returns 
an user_id.
* has a method addUser( Username, Pass) which returns an id or throws an 
exception if the Username is used already.

Do you also want to start working on preferences, permissions and session 
management?

Regards, Thomas Koch
Permalink | Reply | 0 comments |
headers
Thomas Koch | 5 Feb 2007 13:31
Picon

writing much nicer models

So I eliminated also the repeating of writing the propertynames in every 
model: My models are now
    class ContactSubject extends egwBaseModel{}

I'd like the ezc-framework to support this idea, so that my abstract model 
class could become nicer. i.g. putting the caching in ezc, having the 
propertynames available as array.

Thomas Koch

abstract class egwBaseModel
{
    public $_properties = array();
    public $_class = '';
    public static $_def;
    public static $_propertyNames;

    public function __construct()
    {
        $this->_class = get_class($this);
    }

    public function getState()
    {
        return $_properties;
    }

    public function setState( array $properties )
    {
        $this->_properties = $properties;
(Continue reading)

Permalink | Reply | 1 comment |
headers
Frederik Holljen | 5 Feb 2007 13:48
X-Face
Picon
Favicon

Re: writing much nicer models

Hi Thomas,

> I'd like the ezc-framework to support this idea, so that my abstract model
> class could become nicer. i.g. putting the caching in ezc, having the
> propertynames available as array.

Your idea is quite cool. However, we've tried to avoid exactly this sort of 
construction especially in PersistentObject since we don't want to force 
people to inherit from a base class since that severily limits the use of 
PersistentObject.

However, you are of course free to implement this functionality in your own 
library and spread it to others (which you are doing.. very nice!).

Cheers,
Frederik
Permalink | Reply | 0 comments |
headers
Raymond Bosman | 5 Feb 2007 14:31
X-Face
Picon
Favicon

Re: On templates

Hi Thomas,

> Problem: custom blocks are not hardcoded in the compiled template, but
> executed on runtime. But it's to expensive to lookup all these informations
> on runtime.

I committed to the trunk the 'static' custom block.  An extra option: isStatic 
is added to the CustomBlockDefinition structure. When this value is set 
to 'true' and your template provides 'literal' values (like: string, int, 
bool, etc) then your custom block will be static. The custom block function 
is only called when the template is (re)compiled. 

Is this what you were looking for?

Another solution for the future could be caching. Currently, I am working on 
the template cache, and those custom blocks could be cached in order to omit 
the extra function call. 

> So right now, I ask myself, which advantage I have by using templates
> instead of writing good old PHP. You know the discussion, that PHP itself
> already is a template language.
>
> One general question: isn't it kind of insane, to write a compiler to
> output a scripting language? Please don't take this doubt to serious...

Actually, the question is whether PHP  is good enough as template language. 
And that again depends on the users writing the templates.

The key elements for the template language are:
(Continue reading)

Permalink | Reply | 2 comments |
headers
Thomas Koch | 5 Feb 2007 15:27
Picon

Re: On templates

Thx Raymond. That's cool! 

So if I call a custom block {tr "Translate me"}, the result will be just a 
String "Übersetze mich!". Fine.

If I have a template 
{use $text}
{tr $text}

and tr is still static, what will happen?

> Another solution for the future could be caching. Currently, I am working
> on the template cache, and those custom blocks could be cached in order to
> omit the extra function call.

Do I understand you right? You want to use some reflection to get the code 
from the custom block and put it directly in the compiled template? Could 
also come in very handy for translation.

> > Right now I think about writing a script, which analyzes my model and
> > writes templates for the list, view and edit templates. But isn't that
> > even more insane?
>
> No, that's cool :-).

Well. I'm still not sure... 

Thomas Koch
(Continue reading)

Permalink | Reply | 1 comment |

Gmane