Pugdog,
You and Paul were criticize me, because of the code replacings. I would be glad if you were telling your opinion about the features, not about my programming technique.
You are criticizing, but you are not offering alternate solution... I don't know either, so I'm continuing my development on the best known way.
(Paul criticized my error highlight feature, by telling it is re-inventing of the wheel. I think this is not constructive criticism.)
So I'm doing best of my knowledge developing my plugins.
- I'm still using the plugin system without modifying the core code, did I mention it?
- Do you know, that the plugin system makes possible replacement of several hooks, functions?
- Did you read, that I'm aware of the problem of upgrades?
- Did you read, that I write the plugin primarily for my needs? So it mean I have to do it.
- Did I mention, that the hook docs are not enough detailed sometimes?
- Did I mention, that using the PRE and POST hooks the possibilities of altering current features are very limited?
You will be not able to alter current features and extending with real new features, without replacing hooks and maybe some of the functions...
It happens, that there are hard coded things in GT modules... Like the "---" for the select downdrop forms, there are no default value selected. "---" is not enough for me, so I replace with a changeable text (even changeable individually for each select downdrop list)
What do you do in those cases?
Again I do my best, when I develop the plugins and try to solve problems without replacing core codes.
In several cases I do not afraid about my codes, because some of they are more flexible it is in LSQL, and I'm not afraid that LSQL will overgrow in customization of these features.
I quickly remember 2 examples, but there are more:
- the altavista span page can be assembled like a LEGO, almost any part of it is customizable
- my enhanced (and replaced) title_linked function is more customizable, than it could be in LSQL, while it is still backward compatible with the old function calls.
EDIT: So in several functions, evolutional change of replaced LSQL functions will be not very big problem (at least I hope).
Ok. So rather than discussing about my programming techniques, I would be glad to discuss about the features if there are opinions.
Paul says separating error messages to individual tags is unnecessary, the original is better. Having separating error messages there is possible to display red background to those fields, which was not filled by the user as we wanted.
(BTW: the original error display way can be still used as usual, the new features are additionally available to the original ones. And new features can be anytime disabled on admin interface. ).
Other opinions?
Best regards,
Webmaster33
Paid Support from Webmaster33. Expert in Perl programming & Gossamer Threads applications. (click here for prices)
Webmaster33's products (upd.2004.09.26) | Private message | Contact me | Was my post helpful? Donate my help...
You and Paul were criticize me, because of the code replacings. I would be glad if you were telling your opinion about the features, not about my programming technique.
You are criticizing, but you are not offering alternate solution... I don't know either, so I'm continuing my development on the best known way.
(Paul criticized my error highlight feature, by telling it is re-inventing of the wheel. I think this is not constructive criticism.)
So I'm doing best of my knowledge developing my plugins.
- I'm still using the plugin system without modifying the core code, did I mention it?
- Do you know, that the plugin system makes possible replacement of several hooks, functions?
- Did you read, that I'm aware of the problem of upgrades?
- Did you read, that I write the plugin primarily for my needs? So it mean I have to do it.
- Did I mention, that the hook docs are not enough detailed sometimes?
- Did I mention, that using the PRE and POST hooks the possibilities of altering current features are very limited?
You will be not able to alter current features and extending with real new features, without replacing hooks and maybe some of the functions...
It happens, that there are hard coded things in GT modules... Like the "---" for the select downdrop forms, there are no default value selected. "---" is not enough for me, so I replace with a changeable text (even changeable individually for each select downdrop list)
What do you do in those cases?
Again I do my best, when I develop the plugins and try to solve problems without replacing core codes.
In several cases I do not afraid about my codes, because some of they are more flexible it is in LSQL, and I'm not afraid that LSQL will overgrow in customization of these features.
I quickly remember 2 examples, but there are more:
- the altavista span page can be assembled like a LEGO, almost any part of it is customizable
- my enhanced (and replaced) title_linked function is more customizable, than it could be in LSQL, while it is still backward compatible with the old function calls.
EDIT: So in several functions, evolutional change of replaced LSQL functions will be not very big problem (at least I hope
). Ok. So rather than discussing about my programming techniques, I would be glad to discuss about the features if there are opinions.
Paul says separating error messages to individual tags is unnecessary, the original is better. Having separating error messages there is possible to display red background to those fields, which was not filled by the user as we wanted.
(BTW: the original error display way can be still used as usual, the new features are additionally available to the original ones.
And new features can be anytime disabled on admin interface. ). Other opinions?
Best regards,
Webmaster33
Paid Support from Webmaster33. Expert in Perl programming & Gossamer Threads applications. (click here for prices)
Webmaster33's products (upd.2004.09.26) | Private message | Contact me | Was my post helpful? Donate my help...
