Zend Framework : Week of Proposals

[Paul-133]

Hello Andi,

On 6/8/06, Andi Gutmans <[hidden email]> wrote:

You have a powerful cat? :)

Yes. Scheming & Powerful.  Aren't they all ?

You'll have a chance to provide feedback once the proposal is out...
Anyway, the meaning behind those four words is that you should expect
a Propel or a Hibernate, but something more similar to ActiveRecord...

Perhaps it'll be "New & Improved!  With Faster Acting Scrubbing Bubbles!" too.  "On Rails", perhaps ?!  ;-)

Again, I'll look forward to reading the detailed proposal.  From the responses here, others will no doubt as well.

My hope then, as now, will be to see some recognition that success will come not simply from its _own_ merits, but by comparative merit as well, and that there will be a side-by-side.  I'd wager that that's been throughly discussed internally; I just hope that those evaluations/comparisons are shared as well in  the proposal.


Thanks,

Paul

[GavinZend]

Hi Nathan,

Also, the recent work on date, times, and i18n / l10n impacts
Zend_Filter_Input.  As work progresses on those fronts, I expect
consensus for certain improvements to Zend_Filter_Input.

Cheers,
Gavin

Jayson Minard wrote:

> Nathan,
>
> There is still development planned for those areas for another release.
>
> --j
>
>
> On 6/7/06 11:40 PM, "Nathan Bell" <[hidden email]> wrote:
>
>  
>> Is there any development still going on for some of the more basic
>> packages, like Zend_View and Zend_Controller_Action?  Or are those
>> considered fairly stable?
>>
>> I've been using both of those (along with Zend_Db and Zend_InputFilter)
>> fairly extensively on some 'real world' projects and I feel like we
>> still have some flushing out to do on them.  Most of the traffic on the
>> list seems to be about more specialized components (understandably so,
>> they certainly are more exciting to work on), but I don't know if I
>> should take that to mean that the really core components are considered
>> 'stable.'
>>
>> Am I mistaken, is there still development planned for those core components?

[Alex Yuzhakoff]

Hello ,

I'll want to ask the community about proposal of Zend_Upload class.
I'm very busy to write my own proposal, but if I have a little time I
try to do it in this weekend.

The purpose of such class is a generic handling of files uploads and
dealing with $_FILES array. I think in many projects developers
implement this class. So it's a good candidate to become a part of
Zend Framework.


--
Best regards,
  Alexei "SibProgrammer" Yuzhakov,
  Developer, SiteBuilder for Unix,
  SWsoft, Inc.

[Simon Mundy]

I'd be in favour of it, but I'd also want to have it somehow pluggable
with Zend_Form. What specifically did you have in mind - I'm guessing
testing for isUploaded, moveTo, getMimeType  (or similar method names)
and so forth, but I'd also like to see a few extra 'filters' that you
could apply to uploaded files, based on the existing Zend_Filter

E.g.

$imageFilterOptions = array(
    'maxwidth' => 300,
    'maxheight' => 200,
    'constrain' => Zend_Filter_Upload_Image::CONSTRAIN_FIT,
    );

$textFilterOptions = array(
    'lineending' => Zend_Filter_Upload_Text::LINEEND_UNIX,
    'maxlines' => 50,
    );

$upload = new Zend_Upload();
$upload->addField('myfile1'); // an image of some sort
$upload->addField('myfile2'); // a text file
$upload->addFilter('myfile1', 'Zend_Filter_Upload_Image',
$imageFilterOptions);
$upload->addFilter('myfile2', 'Zend_Filter_Upload_Text, $textFilterOptions);
if ($upload->isUploaded()) {
    if ($upload->isValid('myfile1')) {
        $upload->process('myfile1');
        $upload->moveTo('myfile1', '/my/path', 'mynewfilename.gif'); //
Allocate new filename
    }
    if ($upload->isValid('myfile2')) {
        $upload->process('myfile2');
        $upload->moveTo('myfile2, '/my/path', 'mynewfilename.txt'); //
Allocate new filename
    }
}

...or you could simplify the whole process (and be less selective) by
performing:-

$upload = new Zend_Upload();
$upload->addField(array('myfile1', 'myfile2', 'myfile3'));
$upload->addFilter(array('myfile2', 'myfile3'),
'Zend_Filter_Upload_Image', $imageFilterOptions);
if ($upload->isUploaded()) {
    foreach($upload->getFields() as $field) {
        if ($field->isValid()) { // We can query each individual field
as a unique object
            $upload->moveTo($field, '/my/path'); // Original uploaded
filename is retained
        }
    }
}

I'd also imagine that you'd want to extend the Zend_Filter_Input to the
$_FILES superglobal to sanitise input as well.

Look forward to seeing the proposal

Cheerio

> Hello ,
>
> I'll want to ask the community about proposal of Zend_Upload class.
> I'm very busy to write my own proposal, but if I have a little time I
> try to do it in this weekend.
>
> The purpose of such class is a generic handling of files uploads and
> dealing with $_FILES array. I think in many projects developers
> implement this class. So it's a good candidate to become a part of
> Zend Framework.
>
>

--

Simon Mundy | Director | PEPTOLAB

""" " "" """""" "" "" """"""" " "" """"" " """"" " """""" "" "
202/258 Flinders Lane | Melbourne | Victoria | Australia | 3000
Voice [phone] | Mobile [phone] | Fax [phone]
http://www.peptolab.com

[Alex Yuzhakoff]

Hello ,

Friday, June 9, 2006, 9:47:52 AM, you wrote:

SM> I'd be in favour of it, but I'd also want to have it somehow pluggable
SM> with Zend_Form. What specifically did you have in mind - I'm guessing
SM> testing for isUploaded, moveTo, getMimeType  (or similar method names)
SM> and so forth, but I'd also like to see a few extra 'filters' that you
SM> could apply to uploaded files, based on the existing Zend_Filter

Ok. Here is little vision of some key features of this class:

* lightweight class
* easy to extend base class
  * child class for image uploads
* can move uploaded file or put it into database (without moving it)
* can handle multiple files uploads
* validations checks (also must be easily to extend)
  * maybe isValid method (can be overridden in child classes)
  * checks for file extensions
  * checks for mime types
* easy error handling if validation check fails

References (some similar efforts):

PEAR class for Uploads. But is't too old and have some ugly code.
  * http://pear.php.net/package/HTTP_Upload

Upload class for osCommerce. Specific implementation.
  * http://www.oscommerce.info/kb/osCommerce/Developers_Section/Classes/9

Example of writing of upload class. Only for exploration.
  * http://www.phpfreaks.com/tutorials/85/0.php

 
Dependencies on Other Framework Components:
* Zend_Db (optional)
* Zend_Log (optional)


--
Best regards,
  Alexei "SibProgrammer" Yuzhakov,
  Developer, SiteBuilder for Unix,
  SWsoft, Inc.

[GavinZend]

I believe support for upload functionality is definitely needed within
the ZF, and I agree with Simon regarding the importance of this upload
tool playing nicely with Zend_Form .. and our upcoming interpretation of
the Active Record pattern.

FYI:  http://www.zend.com/lists/fw-general/200605/msg00730.html

Cheers,
Gavin

Simon Mundy wrote:

> I'd be in favour of it, but I'd also want to have it somehow pluggable
> with Zend_Form. What specifically did you have in mind - I'm guessing
> testing for isUploaded, moveTo, getMimeType  (or similar method names)
> and so forth, but I'd also like to see a few extra 'filters' that you
> could apply to uploaded files, based on the existing Zend_Filter
>
> E.g.
>
> $imageFilterOptions = array(
>    'maxwidth' => 300,
>    'maxheight' => 200,
>    'constrain' => Zend_Filter_Upload_Image::CONSTRAIN_FIT,
>    );
>
> $textFilterOptions = array(
>    'lineending' => Zend_Filter_Upload_Text::LINEEND_UNIX,
>    'maxlines' => 50,
>    );
>
> $upload = new Zend_Upload();
> $upload->addField('myfile1'); // an image of some sort
> $upload->addField('myfile2'); // a text file
> $upload->addFilter('myfile1', 'Zend_Filter_Upload_Image',
> $imageFilterOptions);
> $upload->addFilter('myfile2', 'Zend_Filter_Upload_Text,
> $textFilterOptions);
> if ($upload->isUploaded()) {
>    if ($upload->isValid('myfile1')) {
>        $upload->process('myfile1');
>        $upload->moveTo('myfile1', '/my/path', 'mynewfilename.gif'); //
> Allocate new filename
>    }
>    if ($upload->isValid('myfile2')) {
>        $upload->process('myfile2');
>        $upload->moveTo('myfile2, '/my/path', 'mynewfilename.txt'); //
> Allocate new filename
>    }
> }
>
> ...or you could simplify the whole process (and be less selective) by
> performing:-
>
> $upload = new Zend_Upload();
> $upload->addField(array('myfile1', 'myfile2', 'myfile3'));
> $upload->addFilter(array('myfile2', 'myfile3'),
> 'Zend_Filter_Upload_Image', $imageFilterOptions);
> if ($upload->isUploaded()) {
>    foreach($upload->getFields() as $field) {
>        if ($field->isValid()) { // We can query each individual field
> as a unique object
>            $upload->moveTo($field, '/my/path'); // Original uploaded
> filename is retained
>        }
>    }
> }
>
> I'd also imagine that you'd want to extend the Zend_Filter_Input to
> the $_FILES superglobal to sanitise input as well.
>
> Look forward to seeing the proposal
>
> Cheerio
>> Hello ,
>>
>> I'll want to ask the community about proposal of Zend_Upload class.
>> I'm very busy to write my own proposal, but if I have a little time I
>> try to do it in this weekend.
>>
>> The purpose of such class is a generic handling of files uploads and
>> dealing with $_FILES array. I think in many projects developers
>> implement this class. So it's a good candidate to become a part of
>> Zend Framework.
>>
>>
>

--
Cheers,
Gavin

Signature of the Week
========================
Have you ever made a small modification to a complex application using a complex framework / MVC ?
Note to self:  Remember.
Goal: Applications using ZF are amenable to changes with minimum effort.

[Christopher Thompson-2]

Jayson Minard wrote:
>>> Our goals for next week (and the week after) are to get in a good solid
>>> list of proposals that fill in remaining gaps in the framework, mainly
>>> looking at the chain of events that occur from receiving a request
>>> through rendering the view.  
I was wondering how things are going on these classes that are executed
on each request. I have checked the incubator and repository, and not
seen much change. I spent a good amount of time in this code and know it
pretty well. I suggested some improvements early on, but Mike said
supporting tests needed to be written before work started.

For me the problem is that code of this type has so many subtleties and
so many far reaching ramifications that it is difficult to effectively
discuss (unlike components which is more modular). There are a lot of
things that need to be done to this group of classes to enable the rest
of the framework to move forward, yet the core has remained fairly
static since the first release.

What is the current status? It would be good to assign a small group to
focus on balancing act of moving these core classes to the next level. I
would be interested -- as probably would others (Jared, Martel, Kevin ?).

[Kevin McArthur-2]

The new zend controller seems ready to roll to me. I'm using it successfully
in our development environment and haven't found any problems with it that
exceed my usage.

I'm testing out zend_config now, will report how that goes; it looks pretty
solid so far. (Might have had a problem with a deliberately null'd key, but
im going to investigate before raising any noise on the list)

These two classes should probably make core for 0.1.4, but 0.1.5 will be a
fairly significant non-api changing service release for most of the
components. Eg we've got a lot of cleaning up to do.

The best thing that could probably be done now, would be tests and docs
which are severely lacking for most of the new stuff, though with a little
hacking one can figure it out.

Also someone should really update the db docs to explain that fetchAll is
not the best way to work with sql queries <grin>. the docs don't fully
explain the implications of buffering a large resultset to memory like this,
nor do they properly document how fetch() by itself will work on a row
cursor and actually fetch data in a buffered way, thus keeping memory usage
to a reasonable level. In fact I don't think fetch() is even documented at
the framework (though it is in pdo, which is fully exposed, if we're going
to fall through to pdo code, we should either mirror the php docs or at
least make it really clear that its a PDO object and can be worked with by
any of the standard pdo methods + plus zfw improvements and link over to the
pdo manual)

$0.02

Kevin
----- Original Message -----
From: "Christopher Thompson" <[hidden email]>
To: "Jayson Minard" <[hidden email]>
Cc: <[hidden email]>
Sent: Monday, June 12, 2006 3:13 PM
Subject: Re: [fw-general] Controllers - Request to View

> Jayson Minard wrote:
>>>> Our goals for next week (and the week after) are to get in a good solid
>>>> list of proposals that fill in remaining gaps in the framework, mainly
>>>> looking at the chain of events that occur from receiving a request
>>>> through rendering the view.
> I was wondering how things are going on these classes that are executed on
> each request. I have checked the incubator and repository, and not seen
> much change. I spent a good amount of time in this code and know it pretty
> well. I suggested some improvements early on, but Mike said supporting
> tests needed to be written before work started.
>
> For me the problem is that code of this type has so many subtleties and so
> many far reaching ramifications that it is difficult to effectively
> discuss (unlike components which is more modular). There are a lot of
> things that need to be done to this group of classes to enable the rest of
> the framework to move forward, yet the core has remained fairly static
> since the first release.
>
> What is the current status? It would be good to assign a small group to
> focus on balancing act of moving these core classes to the next level. I
> would be interested -- as probably would others (Jared, Martel, Kevin ?).

[Christopher Thompson-2]

Great. So things like allowing Front Controllers in to run in sub
directories and allowing you to organize your Action Controllers in a
hierarchy are done. I'll have to check it out.


Kevin McArthur wrote:

> The new zend controller seems ready to roll to me. I'm using it
> successfully in our development environment and haven't found any
> problems with it that exceed my usage.
>
> I'm testing out zend_config now, will report how that goes; it looks
> pretty solid so far. (Might have had a problem with a deliberately
> null'd key, but im going to investigate before raising any noise on
> the list)
>
> These two classes should probably make core for 0.1.4, but 0.1.5 will
> be a fairly significant non-api changing service release for most of
> the components. Eg we've got a lot of cleaning up to do.
>
> The best thing that could probably be done now, would be tests and
> docs which are severely lacking for most of the new stuff, though with
> a little hacking one can figure it out.
>
> Also someone should really update the db docs to explain that fetchAll
> is not the best way to work with sql queries <grin>. the docs don't
> fully explain the implications of buffering a large resultset to
> memory like this, nor do they properly document how fetch() by itself
> will work on a row cursor and actually fetch data in a buffered way,
> thus keeping memory usage to a reasonable level. In fact I don't think
> fetch() is even documented at the framework (though it is in pdo,
> which is fully exposed, if we're going to fall through to pdo code, we
> should either mirror the php docs or at least make it really clear
> that its a PDO object and can be worked with by any of the standard
> pdo methods + plus zfw improvements and link over to the pdo manual)
>
> $0.02
>
> Kevin
> ----- Original Message ----- From: "Christopher Thompson"
> <[hidden email]>
> To: "Jayson Minard" <[hidden email]>
> Cc: <[hidden email]>
> Sent: Monday, June 12, 2006 3:13 PM
> Subject: Re: [fw-general] Controllers - Request to View
>
>
>> Jayson Minard wrote:
>>>>> Our goals for next week (and the week after) are to get in a good
>>>>> solid
>>>>> list of proposals that fill in remaining gaps in the framework,
>>>>> mainly
>>>>> looking at the chain of events that occur from receiving a request
>>>>> through rendering the view.
>> I was wondering how things are going on these classes that are
>> executed on each request. I have checked the incubator and
>> repository, and not seen much change. I spent a good amount of time
>> in this code and know it pretty well. I suggested some improvements
>> early on, but Mike said supporting tests needed to be written before
>> work started.
>>
>> For me the problem is that code of this type has so many subtleties
>> and so many far reaching ramifications that it is difficult to
>> effectively discuss (unlike components which is more modular). There
>> are a lot of things that need to be done to this group of classes to
>> enable the rest of the framework to move forward, yet the core has
>> remained fairly static since the first release.
>>
>> What is the current status? It would be good to assign a small group
>> to focus on balancing act of moving these core classes to the next
>> level. I would be interested -- as probably would others (Jared,
>> Martel, Kevin ?).

[Martel]

Christopher Thompson wrote:

> What is the current status? It would be good to assign a small group to
> focus on balancing act of moving these core classes to the next level. I
> would be interested -- as probably would others (Jared, Martel, Kevin ?).

I'm good to go. Just point in correct direction and I'm going to take them
down, the bastards... oh, wait... different script.

Ready to roll, sir! ;)

--
Martel Valgoerad aka Michal Minicki | [hidden email] | http://aie.pl/martel.asc
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
"Ambition is a poor excuse for not having sense enough to be lazy." -- Edgar
Bergen