Hy Bob,
I will just reply to I18N issues. All others will be answered by the
relevant people.
backends/frontends would be nice. Well that is one component, other
components I feel that were lacking love in were Zend_Translate, Zend_Date
and Zend_Mail could use a getDefaultTransport function to be able to use
the
default transport when sending multiple mails, but that could be
debatable.
* Why should Zend_Translate send emails ???
Zend_Translate is a class which can be used to translate input strings into
output strings.
That is it's only target. Zend_Translate should never send emails. For this
task you should
use Zend_Mail...
The workflow for translating emails (beside the question for what this
should be used in reality)
1.) get input
2.) translate input
3.) generate email
4.) send email
You should always use Zend_Mail for email transportation and not
Zend_Translate.
* Why should Zend_Date send emails ???
Zend_Date was created for handling dates in a simple convinient way.
It accepts dates from emails and it can generate dates in a format which is
necessary for emails.
But Zend_Date should never send emails. We are speaking of handling dates
and not of sending emails.
I never heared of a Date handling class sending emails. This would break
several rules of OOP.
The only class which could be the right place for adding a
defaultTransportation method is Zend_Mail if ever.
Sorry, but I wouldn't see any benefit of integrating email-sending
functionality to any class of the I18N core.
Greetings
Thomas
I18N Team Leader
----- Original Message -----
From: "PotatoBob" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Sunday, December 23, 2007 9:25 AM
Subject: [fw-general] One person's opinion...
*nabble may have formatted the previous message*
NOTE: I am just giving my opinion (biased of course) and hopefully some
constructive criticism. This is because I believe that a project should
have
those who criticize it rather than a complete loyal fan base because
criticism does bring about improvement does it not?
First of all, ZF has made a lot of progress since last year and I am very
happy about the way it turned out. It does seem like there was a real rush
to push 1.0 out the door considering RC2, RC3 and 1.0 were all released in
a
one month period (RC3 to 1.0 was a little over a week if I remember).
While
I do realize that fact that this is a project geared towards enterprise
customers as they do pay the bills :thinking:, I do hope that the target
now
is to fix up some nasty areas and concentrate a little bit more on
developer
friendliness. Of course, there should still be a balance between what you
call "rapid development features" vs "code design". While I am very pro
"code design" rather than using "rapid development tactics" such as
placing
a commonly functions everywhere, I do think that a many people were hoping
for a rails-type feel and a little bit doesn't hurt.
Now that I got that out of the way. There are some things that I feel that
ZF is lacking, hopefully everyone realizes it already. Zend_Cache at the
moment doesn't feel very "up to par" as I saw a few areas that could be
improved such as the removal of the constructor array params checking
which
is inconsistent with other designs such as in Zend_Db. Another wierd thing
question I've got to ask is "Why are the backends and frontends
hardcoded?".
On top of that, being able to provide default configuration for
backends/frontends would be nice. Well that is one component, other
components I feel that were lacking love in were Zend_Translate, Zend_Date
and Zend_Mail could use a getDefaultTransport function to be able to use
the
default transport when sending multiple mails, but that could be
debatable.
One thing that I thought was wierd was this
http://framework.zend.com/issues/browse/ZF-2314 (Thought I'd throw this in
hoping Matthew would explain ;) ). Obviously I have too much to rant
about,
so I'll end it about here and keep you guys from getting bored of reading.
Wishlist:
Abstraction of the Bootstrap process
I do have an attempt at this, although it sounds like you are
heading
towards code generation...
(http://www.assembla.com/wiki/show/zftalk/SpotSec_Application)
Zend_Log_Writer_Syslog
Fix up Zend_Cache quality
Fix wierdness in a few areas of Zend_Db
Ralph, Fix the Zend_Auth_Adapter_DbTable and the object FETCH_MODE bug
Don't make me nag you on #zftalk ;)
Model Loading?
Zend_Acl and Zend_Auth pattern
This seems to be confusing as to a "good" design for many people
Zend_View_Helper_BaseUrl
(returns baseurl) Ok this is kinda on the lazy side, but it does
reduce a lot of typing ;)
That being said, I am looking forward to the future and have followed the
progress of Zend_Layout and Zend_Form since the beginning; however, I do
hope that some of your attention is diverted to the cracks in ZF before
your
next release.
End of ridiculous rant, SpotSec
--
View this message in context:
http://www.nabble.com/One-person%27s-opinion...-tp14476650s16154p14476668.html
Sent from the Zend Framework mailing list archive at Nabble.com.
