Hi everybody,
I've some thoughts about DAViCal development which I want to share with all of
you (of course especially with Andrew ;-)
- Regarding the installation guide of DAViCal one requirement is PHP > 5.0
(BTW, what about libawl? Does it have the same requirement?)
I think that's fine, that enables proper use of objects, classes and so on
and should be standard nowadays.
I assume RSCDS didn't have that requirement and worked in some incarnation
also in PHP4 environemnts.
But IMHO it's time to get rid of old habits.
What I want to say with that?
To properly define variables and class methods (usage of private, public,
static, ...),
to use type hints where appropriate, ...
Things that are already used as this, but not coded that PHP is able to
check it.
What do you think?`
And how far should it go? (usage of namespaces, replacement of most
functions without class, ...)
- About the autentication_hook.
Currently it's just a setting in the configuration where you have
to include the source (e.g. drivers_ldap.php), set a function
which'll be called on login.
Wouldn't it be much better to properly define an interface with some
needed class methods which then have to be implemented for a new
authorisatzion method?
You then could also have a standard implementation from which others
derive their classes and only implement what's different.
- Global configuration array $c
Similar thoughts here...
Why not create "config-objects" for this?
Maybe with possibility to add own class dependend configuratiion parameters?
With this you could add specific parameter keys e.g. for the LDAP
authorisation and get them sent through a check method in the
corresponding class during intialisation?
You'll then be able to syntactiacally and logically check the
configuration parameters...
Maybe the configuration objects of a certain application part could
be stored in that part (e.g. as class member)
and additionally in a global configuration class (e.g. as reference)
What do you think about my thoughts?
Am I thinking in a good direction or is it all to complicate?
Be aware that all of the above is only half-baked and not well elaborated,
just a base for a brainstorming...
kind regards,
Matthias
I've some thoughts about DAViCal development which I want to share with all of
you (of course especially with Andrew ;-)
- Regarding the installation guide of DAViCal one requirement is PHP > 5.0
(BTW, what about libawl? Does it have the same requirement?)
I think that's fine, that enables proper use of objects, classes and so on
and should be standard nowadays.
I assume RSCDS didn't have that requirement and worked in some incarnation
also in PHP4 environemnts.
But IMHO it's time to get rid of old habits.
What I want to say with that?
To properly define variables and class methods (usage of private, public,
static, ...),
to use type hints where appropriate, ...
Things that are already used as this, but not coded that PHP is able to
check it.
What do you think?`
And how far should it go? (usage of namespaces, replacement of most
functions without class, ...)
- About the autentication_hook.
Currently it's just a setting in the configuration where you have
to include the source (e.g. drivers_ldap.php), set a function
which'll be called on login.
Wouldn't it be much better to properly define an interface with some
needed class methods which then have to be implemented for a new
authorisatzion method?
You then could also have a standard implementation from which others
derive their classes and only implement what's different.
- Global configuration array $c
Similar thoughts here...
Why not create "config-objects" for this?
Maybe with possibility to add own class dependend configuratiion parameters?
With this you could add specific parameter keys e.g. for the LDAP
authorisation and get them sent through a check method in the
corresponding class during intialisation?
You'll then be able to syntactiacally and logically check the
configuration parameters...
Maybe the configuration objects of a certain application part could
be stored in that part (e.g. as class member)
and additionally in a global configuration class (e.g. as reference)
What do you think about my thoughts?
Am I thinking in a good direction or is it all to complicate?
Be aware that all of the above is only half-baked and not well elaborated,
just a base for a brainstorming...
kind regards,
Matthias