Re: [fw-general] LIKE query in Zend_Db_Table_Select
thanks Renan & Nick, works like a dream.
Jayson, I totally agree on the scalability comment. I just want to get
something quick working, I may move to Zend_Search_Lucene for this in
the future.
thanks for the help,
Si
On 25 Jan 2010, at 18:03, Renan de Lima wrote:
no, it doesnt :-)
try this:
$table = new TableClass();
$select = $table->select()->where('name LIKE ?', '%' . $keyword .
'%');
$rowset = $table->fetchAll($select);
[fw-general] LIKE query in Zend_Db_Table_Select
hi Is it possible to do a: SELECT * FROM users WHERE name LIKE '%keywords%' style query via Zend_Db_Table_Select? I'm trying to write a simple search to return Zend_Db_Table_Rowset results. best wishes, Simon
[fw-general] Zend_Loader_Autoloader_Resource namespace with underscore character
hi again, I've been trying to use Zend_Application_Module_Autoloader recently with a namespace containing a _ such as: Module_User Now, the namespace appears to be set by Zend_Loader_Autoloader_Resource::setNamespace() which just takes the string, removes any trailing _ and assigns it to the _namespace property. That bit works fine. However, the autoload fails because Zend_Application_Module_Autoloader::getClassPath() checks to see whether the top namespace part (separated by _) matches the _namespace argument (l. 148). In my example this tries to match 'Module' with 'Module_User' and understandably fails. My question is, is Zend_Loader_Autoloader_Resource supposed to support namespaces which contain _ characters in the middle of the text? Or am I pushing things a little too far with this example? If namespaces shouldn't contain _ in the middle of the text can I suggest some validation is added to setNamespace() to make detecting this issue a little easier :) best wishes, Si
Re: [fw-general] Resource autoloading for modules via Zend_Application
Thanks Mon & Graham, Yes, once I'd added the module-specific Bootstrap the resource autoloader worked. However, that's not how I understood the documentation. The line: "By default, an instance of Zend_Application_Module_Autoloader will be created for the module, using the module name and directory to initialize it." could be read (by me at least!) that module autoloading is a separate feature of Zend_Application_Resource_Modules. I thought, incorrectly obviously, that enabling the module resource would support the autoloader. But I see now, you have to enable the ini setting AND have a Bootstrap to use the module bootstrap resource. What the documentation certainly doesn't say, and should, is that the module Bootstrap has to extend Zend_Application_Module_Bootstrap in order to make all this work. If that is correct, I may suggest some alterations to the module resource docs to make this clearer (perhaps a small code example would help). Should I send that to this list / zf-docs / or just post an issue on JIRA? best wishes, Simon I'm confused. Did it work or did it not work after creating a module bootstrap? Because that's how it's supposed to work. The module autoloader is registered by the bootstrap and not the modules resource plugin, so simply activating the plugin is not enough. If it didn't work, maybe your bootstrap class name is wrong. The class name should be _Bootstrap and the file should be named Bootstrap.php and live in the module directory. -- Mon
Re: [fw-general] Resource autoloading for modules via Zend_Application
to partially answer my own question "resources.modules[] =" did work, not sure what I was doing. However, it appears only to work if I have a custom module Bootstrap, is that expected behaviour since its not clear in the docs? Unless I'm not reading it properly best wishes, Si On 14 Jan 2010, at 12:02, Simon R Jones wrote: hi, I'm trying to get the resource autoloader working with Zend_App, my application.ini has: resources.frontController.moduleDirectory = APPLICATION_PATH "/ modules" resources.modules[] = And I'm expecting that a class called Test_Model_User would map to modules/test/models/User.php However, the class cannot be found. Looking at the code (v1.9.5) it appears that the resource autoloader is only instantiated for a module if that module has a custom Bootstrap which extends Zend_Application_Module_Bootstrap. Tried that, still nothing. Am a little confused, since the docs suggest simply this will do: resources.modules[] = Any help appreciated :) best wishes, Si
[fw-general] Resource autoloading for modules via Zend_Application
hi, I'm trying to get the resource autoloader working with Zend_App, my application.ini has: resources.frontController.moduleDirectory = APPLICATION_PATH "/modules" resources.modules[] = And I'm expecting that a class called Test_Model_User would map to modules/test/models/User.php However, the class cannot be found. Looking at the code (v1.9.5) it appears that the resource autoloader is only instantiated for a module if that module has a custom Bootstrap which extends Zend_Application_Module_Bootstrap. Tried that, still nothing. Am a little confused, since the docs suggest simply this will do: resources.modules[] = Any help appreciated :) best wishes, Si
Re: [fw-general] External Modules
hi Paul, We have the same requirement at Studio 24: basically wanting to store a re-usable module which has core, usually non-editable code which can then be extended/customised for a client project. I agree the normal ZF modules don't really cover this use case. At present we place this kind of reusable module in "library/Modules". A brief explanation of how we use it is below (an email originally sent to the contributors list). It's something I plan to write a blog post on soon to get feedback from others. Hopefully early in Jan :) Some sort of standard for reusable modules in ZF would be helpful to encourage sharing of modules in the community, if this use case is agreed to be common enough to need it. I personally think this kind of pluggability would be really useful. The second requirement we have is to have re-usable modules that we can install for a client, customise, and ideally upgrade in the future if we have a bug patch. The classic use case being user management. To do this we have a library/modules/ folder. This has sub-folders which basically contain a full MVC app with the normal ZF folder structure. I.e. for user management this has library/modules/user When used for a client site we SVN external the library/modules folders and treat this codebase as non-changeable (so we can update it in the future if we wished to). We then have some Zend_Application code which sorts out the autoloading and simply extend a few skeleton controllers in the normal app/modules/ folders to actually hook into the library module functionality. So app/modules/user/controllers/LoginController.php will extend library/Modules/User/application/default/controllers/Login.php We also have a view helper which looks in the library/modules folder first for views, then can be overridden by the local app/modules folder. This idea of organised admin modules/URLs and extendable library modules is one we've struggled a little with recently but is very important to a web agency like us who develop a lot of common stuff for clients - and need to customise it on a project-by-project basis. Zend Framework has been good for us in many ways, it's just sometimes difficult working out the best way to achieve this kind of re-usable module setup. On a final note the cascade is important in this scenario, local controllers need to override the base controller, local views need to override the base views, so the developer is always able to override functionality/view if they so desire. I've used Kohana framework a bit which has a nice cascade system. best wishes, Simon On 23 Dec 2009, at 05:49, Paul wrote: I know this has been discussed before, but was is the best way to handle external modules? I not asking for a place to find modules or for ZF to have a site dedicated to modules, just want to know what the standard is for installing a module into your existing system. To me the library directory in the project structure makes it very obvious that the classes inside are used as a base library of classes for your application. By having external modules in your application directory, it makes it harder for someone who is less familiar with the history of the project to know that the code in the "acl" module is external when compared to the "user" module which was created inside the project. I guess the issue comes to maintaining a system. As a developer working on a project you do not want to edit core / external code. For example if I need to alter the Zend_View, i just don't go into that class and alter it's behavior. I can use view helpers or extend the class. As a developer its clear that code in the library folder should not be touched. In the example above, the new developer would not want to touch the acl module as it is external to the system, whereas the user module is okay. It comes down to what do we think a Zend Framework module is? A self contained group of code that can be dropped in to any ZF app? Or is it just a better way to organize and set the boundaries your applications domain? Should we have another folder under the root of the project .. maybe extensions ? I know of ways to achieve this, but I feel, like many others, that the next big step for ZF (besides v2.0), are 3rd party modules/ extensions/plugin (like joomla, wordpress, drupal, jquery, etc), and I don't want to break away to much from the standard project structure to make it as easy as possible to upgrade. cheers, pbo
Re: [fw-general] problems updating ZF SVN trunk
hi Pádraic, totally agree case-insensitivity is a pain on a Mac. But that's the way it is. A fresh checkout seems to work fine now :) best wishes, Simon --- On 18 Dec 2009, at 12:10, Pádraic Brady wrote: Delete the file and re-up if you are on a case insensitive OS. There is no actual fix without restoring the original filename, and that would be a violation of the coding standard. The SVN trunk is NOT broken - it's a valid name change. The only thing "broken" is your operating system which can't tell the difference between "a" and "A" ;). Presumably this also affects Windows. Pádraic Brady
Re: [fw-general] problems updating ZF SVN trunk
I'm on the command line (Terminal on the mac), and doing the suggestion in Tortoise will alter the ZF SVN repository. I am sure there is someone working on this component so I just wanted to highlight the SVN trunk appears to be broken for case-insensitive machines at present. Happy to help resolve it, if given permission :-) best wishes, Si I have same problem with tortoise. Regards, Saša Stamenković On Fri, Dec 18, 2009 at 12:18 PM, Daniel Latter wrote: Hi, are you using TortoiseSVN? if so maybe this will help: http://tortoisesvn.net/node/285
[fw-general] problems updating ZF SVN trunk
hi there, I am using Mac OS 10.5.8 and am trying to update the SVN trunk for ZF and I get this error: Naming issue in trunk - ABarcode/Upca.php ABarcode/UpcA.php svn: In directory 'Barcode' svn: Can't open file 'Barcode/.svn/tmp/text-base/UpcA.php.svn-base': No such file or directory Looks like UpcA.php was renamed to Upca.php (which is good) but it seems to be causing some issue on my Mac. As you may know Macs are helpfully case-insensitive. Any tips on how to resolve this? A fresh checkout doesn't help. Also Zend_Validate_Barcode_Upca appears to have a hell of a lot less code than Zend_Validate_Barcode_UpcA (in 1.9.6). Is that intentional? thanks, Simon
[fw-general] Setting one message on failed validation for Zend_Validate
hi there,
I have a common requirement for setting one error message on the
failed validation of a form element, for example an email address.
Sometimes I just want to set something like 'Enter a valid email
address' rather than have the many different error messages that
Zend_Validate_EmailAddress offers.
I know you seem to be able to set a single error message on a form
element via $element->addErrorMessage('string..') but that appears to
set one error message for all validators on a form element.
If I just want to set one error message per validator the only way to
do so appears to be to setMessage for each message key that exists for
that validator. Which is a bit verbose of course :)
Would it be a reasonable use case to add a new function to
Zend_Validate_Abstract to do this, for example:
public function setSingleMessage ($messageString)
{
foreach ($this->getMessageTemplates() as $messageKey =>
$message) {
$this->setMessage($messageString, $messageKey);
}
return $this;
}
If so, is this the right place to suggest the new method??
best wishes,
Si
Re: [fw-general] Zend_Translate DB support
Thomas, not at all - please don't take any offence! I haven't used Zend_Translate a whole lot yet. I'm just asking a general question to see if there is any work on support for managing translated strings within a database (for a model rather than just messages) because I am tackling that as part of a current project. If that's what the SQL adapter is intended to do, that's great. I'll restrict my further comments to that ZF issue. best wishes, Simon On 5 Jun 2008, at 09:32, Thomas Weidner wrote: So you know how I18N works in ZF better than me ? You know how the ZF SQL adapter is designed ? Why did you then ask ? Greetings Thomas Weidner, I18N Team Leader, Zend Framework http://www.thomasweidner.com
Re: [fw-general] Zend_Translate DB support
Thanks Thomas, I might be thinking of something more related to Zend_Db than Zend_Translate, where you can access translated strings in your database model seamlessly. Symphony has a nice model which creates a _i18n table with all text strings by language code. http://www.symfony-project.org/book/1_0/13-I18n-and-L10n#Text Information in the Database I'm thinking something similar could be done that I'm guessing crosses the boundaries of Zend_Db and Zend_Translate. From what I can tell an SQL adapter for Zend_Translate isn't that. best wishes, Simon On 4 Jun 2008, at 20:48, Thomas Weidner wrote: Simon, There is work done. Zend_Translate will get a sql adapter in future. See http://framework.zend.com/issues/browse/ZF-2248 But actually there is no public code available. I've seen some single examples floating around where people have done such themself, but these are not as generic as needed for the official adapter. Greetings Thomas Weidner, I18N Team Leader, Zend Framework http://www.thomasweidner.com
[fw-general] Zend_Translate DB support
hi there Is there any work being done on a database adapter for Zend_Translate? For example, to help support managing translations of database table textual content in different languages? If so, can someone point me in the right direction. thanks, Simon
Re: [fw-general] Zend_Registry is good for?
> Preference to less overhead shouldn't ever be a preference, it should > be job #1 on any developer's mind. Less code, not more, faster code > not slower. OO for the sake of OO is a waste of resources. the aim of any framework (be it in Perl, Java or PHP) is to make development faster and more maintainable across teams. This is generally more valuable than performance savings since it means you can develop quicker and understand someone else's code in a year's time. This is the aim of ZF and it works well in this regard. This obviously comes with a tradeoff in performance (as with all frameworks). But in the long-term is worth it for consistent development. If you don't want to use a framework for these reasons, don't. Or at the very least don't use the bits you don't like. There's no point moaning about it - though this has entertained my Friday morning ;) best wishes, Si
Re: [fw-general] Zend_Registry is good for?
I have to agree with Matthew. A lot of ZF can seem like overkill at times, and obviously you only have to use what you want to, but Zend_Registry is a "good idea" Using globals is how I used to do it, but over 10 years of PHP development I've found it to be a messy and, at times, dangerous technique. By using an OO-approach you always know where your registry items come from, you can't overwrite them accidentally and you can throw exceptions if you try to access things that don't exist (whereas you just get a potentially unpredictable response if you just access an undefined global variable and then try to do things with it - the curse of PHP's loose typing!) Also, if you ever have to join two different PHP apps together using globals can be truly nightmarish (i've done it, when two different apps have used the same global namespace variables). In my opinion, if you keep everything separate using OO it keeps things organised, predictable and in the long term it's a lot simpler. best wishes, Si
Re: [fw-general] _forward() question
thanks for the clarification Matthew, that all makes sense.
I think it would be useful if the documentation covers the situation
where you want to forward to a new action but exit the current one
immediately, with an example along the lines that you detailed in your
email. I.e.
if (!$this->checkLogin() {
return $this-> _forward('index', 'login');
}
That would help to clarify the situation for newcomers to ZF
best wishes,
Si
Re: [fw-general] _forward() question
thanks for the reply Matthew
Can I ask why _forward() stacks and only forwards at the end of the
current controller method? I couldn't find any reference to why it
works this way in the docs so when some of the guys in the office had
used multiple forwards (without returns) the default behaviour was
confusing.
best wishes,
Si
On 13 Feb 2008, at 19:36, Matthew Weier O'Phinney wrote:
Correct -- you need to return. I actually usually write it as:
return $this->_forward('index', 'login');
as the return value of an action is ignored anyways.
The reason it works this way (i.e., you need to return when
forwarding)
is because you can't have a called function force the calling function
to return -- it's a language limitation.
Further to this, if the above is the recommended way to forward and
quit
the current method then this of course becomes problematic if I
abstracted
the login check. I.e. if I called a function to do something like:
$this->checkLogin();
And the function checkLogin() did the necessary ACL check and also
included
the forward() - to avoid DRY.
Unfortunate, but necessary. I typically have methods like this
return a
boolean, so I can then do something like this:
if (!$this->checkLogin() {
return $this->_forward('index', 'login');
}
[fw-general] _forward() question
hi there,
I'm using $this->_forward() in a controller method to forward the
request onto a login page, this can't be done that easily in pre-
dispatch since different methods have different requirements for ACL
and we have a rather complex custom route system going on (part of
which happens in specific controllers). At present we're not using
Zend ACL.
It seems the default behaviour of _forward() is to continue processing
the current method's code, and then forward to the new controller/
action. So if multiple forwards exist in that method's code, only the
last one actually works.
Is this correct? I had presumed _forward() would forward to the new
controller/action and exit the code at that specific point. Is this
possible? Or do I have to just return from the method at that point in
the code? I.e.
$this->_forward("index", "login");
return;
Further to this, if the above is the recommended way to forward and
quit the current method then this of course becomes problematic if I
abstracted the login check. I.e. if I called a function to do
something like:
$this->checkLogin();
And the function checkLogin() did the necessary ACL check and also
included the forward() - to avoid DRY.
comments appreciated!
Simon
RE: [fw-general] RTF
> Is there anyone doing work on an RTF component for Zend Framework? > Are there people interested in such a component? Great idea, though if you mean a WYSIWYG style editing component this is incredibly hard to get right and a huge job if done from scratch. It may be worth using existing tools such as Textile to start with. I guess that wouldn't work under the standard ZF licence but there's nothing to stop individuals creating their own classes. I've used Textile myself for some projects and it's a great solid tool. best wishes, Si
[fw-general] SVN down?
is there a problem with ZF SVN too? In the past I used an external in my ZF projects such as: http://framework.zend.com/svn/framework/tag/release-1.0.1/library/Zend Which now returns: Error: PROPFIND request failed on '/svn/framework/tag/release-1.0.1/library/Zend' Error: Can't set position pointer in file '/usr/local/svn/framework/db/revs/6582': Invalid argument This error seems to be coming from the ZF server itself. best wishes, Simon
RE: [fw-general] Zend Framework Web Application (best practices, structure, skeleton)
I think "best practises" and methods to "quick start" applications would be far more useful to the project than trying to develop an Open Source CMS for ZF at this stage (which is a pretty ambituous aim in any case). Things like Zend_Form, Object Relational Mapping and Scaffolding would be very useful for fast development. Though I seem to recall some reluctance to look at ORM at present for ZF. Documented best practises on techniques for larger app development would be great. I guess that kind of thing will start to develop as more people use ZF anyway. Probably best to comment on Bill's proposal at http://framework.zend.com/wiki/display/ZFPROP/Zend_Application+-+Bill+Karwin at this time. Though I can't seem to access the wiki this morning! best wishes, Si
[fw-general] Zend_PDF exporting as an image
any idea if Zend_PDF can export one page of a PDF as a flat image (i.e. PNG)? thanks, Si
RE: [fw-general] Zend CMS Crisis
Ask yourself do you have any specific requirements you need to solve at your university that makes it easier to develop your own code. Having your own system can make a lot life easier when customising specific features, though I'd advise you keep the core features as simple as possible to make life simpler. It is a lot of work for an individual to develop and maintain a CMS so get others involved if you haven't already. There's nothing better than peer review :-) Open Source CMS software may well do the job for you, but you'd need to evaluate each one carefully. The knowledge you've learnt by developing your own CMS will undoubtedly help you with any such research. Often such software is targeted at certain sectors (i.e. portal sites, intranets) so look at example customers which match your situation. >From a brief look around MySource Matrix seems very comprehensive. It has support for versioning and metadata schema though it is PHP4 (which isn't in itself bad though it means you cannot use Zend Framework with MySource Matrix). And possibly important for you it doesn't seem to have support for multiple languages in the core. Finally bear in mind you have written your CMS already. Unless it's broken or needs very high maintenance it is worth rolling it out to one or two departments for evaluation to see if it will work across your university. best wishes, Si
[fw-general] ISO Country lists / groups
Is there any functionality to create lists of countries based on the ISO country list at present, or any plans to do so? E-Commerce sites we work on tend to require this rather long list of countries, ideally trimmed down to the relevant countries, when customers enter their address. Another requirement is when calculating postage we group countries into regions like UK, Europe, or Rest of World. Certain preset groups exist, though the ability to create your own country groups is very useful. If this doesn't exist at present I'd be interested in working on this. Any thoughts on where it should reside. Or is this more the case of extending Zend_Locale ? The ISO list is available at: http://www.iso.ch/iso/en/prods-services/iso3166ma/02iso-3166-code-lists/inde x.html And geographical regions at: http://unstats.un.org/unsd/methods/m49/m49regin.htm best wishes, Simon
RE: [fw-general] Proposed backward-incompatible changes to Zend_Validate_* classes
Hi Bryce, Lots of activity this month on things like Zend_Filter_Input and your new proposal, which is good. So you know our company are using Zend_Validate quite extensively. We're working on an E-Commerce system based on ZF which obviously we're trying to keep up with any changes as they occur. So I certainly advocate change if it's good for the framework. I've only just seen your proposal (http://framework.zend.com/wiki/display/ZFPROP/Zend_Validate_Builder+-+Bryce +Lohr) so will read through it soon, so apologies if this question is answered in there. My initial question is why do you want to allow an empty string to validate? In the context of, say, validating a URL or email address I really wouldn't want an empty string to pass through. If a form says an element is optional, I'd say you need to declare that in your code. I believe a safer default would be to not allow empty strings through. best wishes, Simon > > Hi all, > > > > I've proposed some changes to Zend_Validate_* classes that would > > not be backward compatible. Specifically, I had proposed to change > > the default behavior all the standard validators to consider the > > empty string a valid value. > > > > Now, I've been operating under the assumption that hardly anyone is > > using the current Zend_Validate_* classes, due to the fact that > > it's a hassle to validate a lot of data at once. I figured that if > > few people were actually using these, then the cost of making this > > backward-incompatible change was low. The benefit of the change is > > that it would provide a lot of flexibility in the proposed > > Zend_Validate_Builder class. > > > > I may be way off base with my assumption here, so I'd like to find > > out how many of you are actually using the current Zend_Validate_* > > classes. Obviously, if a lot of people are, in fact, using them, > > then it's not feasible to make this proposed change. > > > > Regards, > > Bryce Lohr
RE: [fw-general] Zend_Validate
Hi Alexander, Some domain names have been set up to accept international characters, DE domains being one of them. More info on how to use it is on http://framework.zend.com/manual/en/zend.validate.validating_hostnames.html However, there have been reports of it not working reliably for some people. This is likely down to character encoding issues. This has been reported in ZF-1083 ( http://framework.zend.com/issues/browse/ZF-1083 ) and I'm looking into why this isn't working for some people. I had uploaded a test script to that page but the upload process messed up the character encoding so that doesn't work. I plan to write up some tests and host them myself to help resolve this. I'll send you a link once I've done this. best wishes, Simon
RE: [fw-general] Zend_Filter_Input...
I agree users should definitely know where their data comes from. Obviously reliance simply on POST is silly. That's where Zend_Validate/Filter type functions come into play. I think Chris is getting at the fact GET shouldn't be used for actions that change data (i.e. delete, add records, etc). Though many apps do this, it is against the HTTP spec and can lead to unpredictable results (i.e. when Google Accelerator followed all links in a document and started actioning delete links). I've been guilty of this myself in the past. I originally made this comment since it seemed that functions within ZF were returning POST variables not purely from POST, but from a mulch of POST/GET/URL. If the function exists, chances are users will use them. And that seems to promote bad practise. I'm in favour of users sticking to good old $_POST and $_GET so they know exactly where things come from and can plan their security appropriately. The old Zend_Filter_Input used to give users access to $_POST and unset _POST so they were encouraged to filter all incoming data. That seemed useful, though I understand progress has made that undesirable now. If any ZF functions do return POST to the user for their own scripts, they should have a good reason for doing so (and ideally add functionality / or encourage security practises) otherwise it seems simpler to just stick with existing superglobals that people understand. Security is a big thing, more so perhaps in the PHP world where there has been bad press in the past. Seems like a good topic for a tutorial, or even an additional manual section, for ZF 1.0 ... best wishes, Si
RE: [fw-general] Zend_Filter_Input...
> It was never intended as a general-purpose object for > input filtering -- that's a goal for a later iteration, which will still > need to account for the variety of sources when dealing with routing. That's fine, just as long as new users always use $_POST or getPost() to retrieve POST variables so they know where they are coming from. Just something that may be worth highlighting in the manual for 1.0 - Presumably there will be/is a small section saying where to get various things when using the Router (i.e. URL parameters, GET vars, POST vars)? best wishes, Si
RE: [fw-general] Zend_Filter_Input...
> You can use $this->_getParam('key', 'default'); in a Controller, because
> _getParam() use the Request->getParam() method, which tries first to
> load the param from the url, then from $_GET and after this from $_POST.
If $this->_getParam() looks at the URL, GET and POST isn't it a potential
security issue to use it for POST variables since you don't know exactly
where your input variables are coming from?
Seems rather similar to $_REQUEST to me which should also be avoided for
similar reasons -
http://shiflett.org/articles/ideology
A quick look at the (nicely growing) manual it seems you can do the
following which does the job nicely for POST variables:
$myVar = $this->getPost('name');
(See API docs / Zend_Controller_Request_Http for more)
There do seem to be a lot of methods that return variables from GET, POST,
COOKIE, etc. I think it would be a good idea to mention the security
implications of depending on these in the manual..
Si
RE: [fw-general] Great work with 0.9
I third that! We looked around hard and wide for a decent framework to use for our company and settled on Zend Framework 6 months ago. The progress since then has been fabulous and has certainly validating my decision to go with ZF. Excellent work everyone :-) Si
RE: [fw-general] Zend_Filter_Input / accessing $_POST
Thanks for the speedy reply Tony best wishes, Simon
[fw-general] Zend_Filter_Input / accessing $_POST
Quick question I hope isn't too dumb..
I've noticed ZF 0.9 has dropped the functionality of accessing the $_POST
superglobal via Zend_Filter_Input. Pre 0.9 once you'd accessed POST via
Zend_Filter_Input you were forced to access POST subsequently via
Zend_Filter_Input. This seemed to me, at the time, a good idea.
Now POST vars are left where they always were, i.e. $_POST[{name}] or
$this->_request->getPost('{name}'). I missed any mailing list discussion on
this, so can I ask what the reasoning behind this was so I can understand
why it's now structured in this way
thanks,
Si
RE: [fw-general] Zend_Search_Lucene partial word match
Thanks for the feedback Alexander Is there any planned schedule for supporting this in Zend Lucene at present? best wishes, Simon
RE: [fw-general] YAZFA
Very nice site redesign Chris Have you written any articles on your use of Zend Framework? Best wishes, Si
RE: [fw-general] Allowing return strings to be translated
Thanks for the response In my usage in Zend_Validate I'm returning messages more to indicate why validation failed, an exception is only raised if an internal error is hit. I would guess if a code value was also returned this may help others to translate text. Presumably the returned messages/codes system could be consistently implemented along with exception messages/codes? My immediate thought is that message codes could be set up as class constants to help references. Anyway, I look forward to more discussion on this after 1.0 Si
[fw-general] Zend_Search_Lucene partial word match
Is it possible for Zend_Search_Lucene to match partial words, for example "simp" to match "simply"? best wishes, Si
[fw-general] Allowing return strings to be translated
In relation to http://framework.zend.com/issues/browse/ZF-904 Is there any agreed method to return strings from ZF methods to allow them to be translated? For example, I mean an error message from Zend_Validate. >From looking at the issue above it seems not at present. best wishes, Si
[fw-general] Validate Hostname
I've added MX checking functionality to Zend_Validate_EmailAddress with dns_get_mx() and have added IDN domain support to Zend_Validate_Hostname to match a domain such as bürger.de However I've had some real problems getting the Hostname Unit Test to run and validate an IDN domain. Most of these seem to be due to UTF-8 characters in the test file getting mucked up (encoding is great fun!). So far I cannot actually run my Unit Tests successfully (I am on Windows with WAMP and so far have not managed to get PHPUnit running on a Unix box here) but if I copy the code into standalone test scripts using the actual Zend Framework validate functions they pass fine. Test scripts which validate a hostname via POST also work fine (given form encoding is working OK). I would like someone with more experience of PHPUnit to run my tests to see if they pass OK. If so, I'll submit the code into the repository and hopefully all will be well. Otherwise is it OK to commit this new feature without a Unit Test? I rather suspect even if we can sort out encoding in one file Subversion may muck up the encoding and thus make it impossible to get a stable Unit test for this in the trunk. I've linked the files from: http://framework.zend.com/issues/browse/ZF-881 Comments on MX checking for emails on: http://framework.zend.com/issues/browse/ZF-42 Off for dinner now :-) will be back in an hour or two Thanks, Si
RE: [fw-general] Zend.php proposal
>From my experience in using registry style systems I've only ever used them
statically, I can't see the point for using it as an object, i.e.
$registry = new Zend_Registry();
I think from reading the above that is being proposed as an option. If I've
understood correctly, I'd strongly vote against it. The whole point of the
registry is to provide access to variables across an app from within
different classes without having to resort to global variables. If you don't
need access across classes, why bother using the registry?
I agree with Bill that:
$r = Zend_Registry::get();
Invites a level of confusion to usage.
$r = Zend_Registry::getInstance();
Is far better to understand. I've also asked a newbie developer here and I
quickly explained the getInstance functionality and how the code would look
under both circumstance. He found the method name quite understandable and
he has no idea what singleton patterns are. So I think the method name is
logical.
However, I would normally use the registry as so:
$config = Zend_Registry::get('config');
$dbname = $config->db->name;
Though I can see how accessing multiple objects stored in a registry in one
controller is easier (and less code) by using:
$r = Zend_Registry::getInstance();
$dbname = $r->config->db->name;
$bar = $r->foo->bar;
So the current proposal sounds very good to me :-)
However, I have no idea what this is for:
$foo = $r->offsetGet('foo');
best wishes,
Si
RE: [fw-general] Zend.php proposal
I agree, solution E sounds fine best wishes, Simon
RE: [fw-general] Request for feedback: moving Zend.php to Zend/Zend.php
Keeping this functionality in one class makes sense to me. The main change
we'd need to make to our code is changing lines like:
$db = Zend::registry('db');
to:
$db = Zend_Registry::registry('db');
I guess I could suggest simplifying the register/registry method names since
the duplication of the word "registry" is a little verbose. If this is in
its own class presumably this would be as good?..
$db = Zend_Registry::get('db');
and:
Zend_Registry::set('db', $db);
best wishes,
Si
RE: [fw-general] Request for feedback: moving Zend.php to Zend/Zend.php
+1 with Ralf, ZF is designed to be used as a component system, so why not drop Zend.php if this is realistic to do so for 0.9. The minor changes required to our files is quite worth it. best wishes, Simon
RE: [fw-general] Zend Framework 0.8 code freeze
hands up - that's my fault
I changed the default functionality of Zend_Validate_Hostname to only check
for DNS hostnames since I felt that was a more common real-world scenario.
Sorry if I've broken existing functionality, I should have checked across
the codebase
I can either change that default functionality back to ALLOW_ALL or can
someone implement Olivier's fix please?
I notice Zend_Filter also has a reference to Zend_Validate_Hostname
public static function isHostname($value, $allow = self::HOST_ALLOW_ALL)
{
require_once 'Zend/Validate/Hostname.php';
$validator = new Zend_Validate_Hostname($allow);
return $validator->isValid($value);
}
best wishes,
Si
[fw-general] Accessing class methods dynamically
I'm working on Zend_Validate_Hostname and have a need to access a method
within a class to get TLD specific regular expression characters. I don't
know the exact class name since it depends on the TLD in the hostname.
In Zend_Validate_Hostname::isValid() it works like so:
$className = 'Zend_Validate_Hostname_' . ucfirst($valueTld);
Zend::loadClass($className);
$obj = new $className;
$labelChars .= $obj->getCharacters();
With the class specifying the characters looking something like this:
class Zend_Validate_Hostname_De implements Zend_Validate_Hostname_Interface
{
public function getCharacters()
{
return '\x{00E1}...\x{00FE}';
}
}
I have no need to actually instantiate the class object, but I cannot see
any other way to access the getCharacters() method. Ideally I'd just do:
Zend::loadClass($className);
$labelChars .= $className::getCharacters();
But variable variables and classes doesn't work in PHP.
Any bright ideas on a better way to access the getCharacters() method. Or is
my current approach fine?
best wishes,
Si
RE: [fw-general] Basic db model question
Xavier, I agree wholly depending on ORM isn't always a great idea, I tend to always code SQL manually for front-end (higher usage) parts of sites. For admin systems that often have low usage ORM can be fantastically useful. In your method returning a predictable array from each get method certainly makes sense. My thought was to return an object for the data as well (i.e. perhaps have a separate data access object and data object). An array is simpler to work with, though you can enforce certain rules into an object. Presumably methods could be prefixed with the standard CRUD terminology (i.e. createNews, retreiveNews, updateNews, deleteNews) though that depends on us spelling things right! I would think that any method that updates/inserts, would also need to populate a detailed amount of error messages to inform on things like failed validation, failed DB insert, etc. Presumably that could all be coded into a parent DAO class. thanks for your thoughts, Si
[fw-general] Basic db model question
hi, I wanted to pick your brains on what people consider best practise on how to organise SQL queries / database models in a ZF application. The docs note the following folder: /application /models Do people create a data model per "database object" to define what the representation of the data object is? A data model may represent one table (i.e. category) or more likely data across multiple tables (i.e. a user with a user group, etc). Do you include the SQL statements to get, update, etc, the data to populate this object in the same data model file - or a separate one to keep things tidier? Any thoughts appreciated, Si
RE: [fw-general] Modular directory structure
> For me it's common practice to have a controller per > "subject". For instance, a NewsController, BlogController, > FooController, etc, etc... > > A controller processes and responds to events (typically user > actions), and these "processes" vary for each subject/module > pair, you usually end up having the same controller in each > module, but with different business logic. > > website/NewsController.php > admin/NewsController.php > super-admin/NewsController.php > super-duper-admin/NewsController.php > > Where "website", "admin", "super-admin", "super-duper-admin", > are the so called "modules", which are actually just folders > > I hope this makes a little sense? Yes, makes total sense. Though I think you're assuming a module is a type of access in your case. In the way I'm thinking of modules is for completely separate applications. Can I clarify, what do people consider a 'module' is? A separate application based on the same framework, or something else? The initial issue was that under normal ZF working the controller has all the business logic, and where you have functions like admininstration that can get very bloated very quickly. Hence why I like to sub-folder the controller folder into 'sections' A requirement for me is to have modular apps in totally separate folders to aid maintenance and updating. For example one apps with the admin controllers Items and Reporting may exist in the same 'admin' module folder under one interpretation of the module structure. Ie: app/controllers/admin/reporting.php app/controllers/admin/items.php If a second modular app also has a reporting admin function where does it go? app/controllers/admin/module2-reporting.php gets messy obviously. That's why I like the idea of the currently documented modular structure which would allow for: app/module-1/controllers/admin/reporting.php app/module-2/controllers/admin/reporting.php This is similar to the approach Jeremy described earlier. I've added a second depth of controller files here for organisation. Unfortunately my discussion is a little circular, since the obvious question is what would the URL be for the end user? For public front-end stuff it seems pretty straightforward since different modules would likely be in separate document root folders, however it's nicer to keep admin stuff in one root folder (i.e. '/admin/'). Presumably custom routes could be set up to point admin URLs (i.e. /admin/module-1/reporting/view) to the correct controller. I think this modular folder structure stuff can get quite complex when trying to truly keep things separate and easily interchangeable. I'll keep trying things out.. best wishes, Simon
RE: [fw-general] Modular directory structure
Hi
Basically our project is in a lot of flux over the next few weeks so I
thought it would be a bit pointless trying to detail what we're doing since
it'll just end up changing a lot! We're just trying to develop a system
which has two modular bits so it's really interesting to see this stuff
discussed on the mailing list at present..
I noticed the 'module' support in ZF too, it seems this line will also
support it without an additional route:
$frontController->setParam('useModules', true);
see:
http://framework.zend.com/manual/en/zend.controller.html#zend.controller.ove
rview.routing-process
My initial worry with this is that a 'module' is great to separate code for
different applications, but what if one part of your application has too
much code to fit into one controller file?
In ZF most of the business logic ends up in the controller file, so an
AdminController.php, in my experience so far, becomes quickly unweildy if
there is only one controller file to manage admin tasks (i.e. reporting,
adding/editing items).
So I've used what I called 'sections' to split admin controllers up into a
sub-folder. This to me isn't the same as modules. I wonder what ideas other
people have on that? I hope I'm making myself clear
best wishes,
Si
[fw-general] Lucene and UTF-8
brief question.. What's the status of Zend_Search_Lucene and UTF-8 support? Is it currently supported by version 0.7, or is it planned for the future (if so, any idea of when?) thanks, Si
RE: [fw-general] Modular directory structure
We're basically extending bits of ZF to provide this functionality. A bit like the Zend_App class that I seem to recall being mentioned on this list in the past. It's a bit difficult to go into lots of detail at present since we're in the middle of this project and it has another month of development left. But I can write up a tutorial on the useful points once we're done if it would be helpful. best wishes, Si
RE: [fw-general] Modular directory structure
Hi Nick, Thanks for that info. I've just reviewed our own folder structure based on the 'Conventional modular' layout and made some improvements. Here's what we are currently using for a modular project: /app /config / /config /controllers / /models /lib /Zend / /tmp /cache /sessions /views_compiled /web /app_views .htaccess /layouts / / /assets /css /img /js / / /css /img /js / .htaccess index.php I certainly like the idea of the global and modular config folders, seems a sensible way of doing things. We use sections to allow for longer URLs, the obvious example being public front-end and the admin back-end. If the application web homepage is: www.domain.com/shop/ then we may use a section called 'admin' to have: www.domain.com/shop/admin/ This then allows a URL like www.domain.com/shop/admin/reporting.html which resolves into the controller at: controllers/admin/ReportingController.php Splitting up controllers into sections allows to reduce very long controller files, I am sure this has been mentioned a few times on this list before. We've created library code to automatically route things to the correct paths based on a "(optional section)/controller/action/(optional id)" route. You'll note we place the views in the web root. Simple reason really: most templates need to be edited by our designers or web production team who use Dreamweaver to manage things. Thus the files need to be in the web root in order to do this effectively (DW has things like templates which auto-fix links if you use it correctly). There's an .htaccess file to deny public access to this folder. Views are split up into layouts (templates for the skeleton of the site, and then sub-folders for each modular application for the inner-HTML or other templates (ie. emails). Again, section names are used to mirror the controller section name folder structure. Assets (images, CSS, JavaScript, etc) are placed in a single assets folder for neatness. This is simply how we've always managed websites and reduces clutter. Global css,img,js folders exist for the main site and then modular application names exist to store application-specific assets. We also use a theme folder (the default one being called 'default' unsuprisingly) to allow us to build up different themes for an application based on CSS and images, and to then allow us to switch themes for an app easily in the future. Finally, the application web root is in a sub-folder. This allows us to mix multiple modular apps easily. Obviously if ZF managed the whole site this could be considered a flaw, though I suspect it would still work (presumably if the root folder had a .htaccess redirecting to the root bootstrap any sub-folders with new .htaccess rules would override the root .htaccess file) Hope that makes some sense! best wishes, Simon
RE: [fw-general] isEmail status?
> Thanks for your contributions; I plan to complete the three > classes listed as skeletons at the beginning of this message > today. The e-mail address validator will likely get more > attention after it's fleshed out for people to review, test, > and suggest improvements. OK, sounds a sensible approach Darby, I've already placed the initial email validation into the Zend_Filter_EmailAddress class, would it make sense to commit this to the lab and continue working on it to flesh out its full functionality (inc. MX checking). Or shall I just carry on and let you know once a full version is ready?.. best wishes, Simon
RE: [fw-general] isEmail status?
I've taken a look at the new Zend_Filter structure in the lab and it seems most class files are just skeletons at present. So I presume until all these are fleshed out we can't push it into the incubator? Or can we push the stop-gap version of Zend_Filer_Validation_EmailAddress into the incubator? Also, is there any use in publishing a stop-gap version of isEmail for the current implementation of Zend_Filter for 0.7 so people can start using it? However, given the usage of Zend_Filter may change completely if the new system in the lab is implemented is there any point? I have uploaded a sample stop-gap file for the current implementation of isEmail at http://framework.zend.com/issues/browse/ZF-42 best wishes, Simon
RE: [fw-general] isEmail status?
> First, any validator is its own class under the new design, > rather than being a single method of a larger scope, > general-purpose validation class (as in the implementation > currently in the framework core trunk). Darby - do you have any information about how this new encapsulation works since I've not seen it before, and how Zend_Validate_EmailAddress would be called from a calling script? I can then fill up some of the blanks in the class skeleton you've provided. best wishes, Simon
RE: [fw-general] isEmail status?
I've been looking into this and have developed what could be called a "stop-gap" version which validates against the recommended dot-atom character set for email addresses. http://framework.zend.com/issues/browse/ZF-42 After Gavin's comments I'm looking into Perl's Email::Valid which also optionally checks domain validity. Which will take a little longer, but I'll try to get an update back later this week I'm not sure whether Zend want a "stop-gap" version or just the whole thing put into the framework.. best wishes, Simon > -Original Message- > From: Andrew Yager [mailto:[EMAIL PROTECTED] > Sent: 13 January 2007 06:45 > To: fw-general@lists.zend.com > Subject: [fw-general] isEmail status? > > Hi, > > With 0.7 coming up, I was curious to know what progress was > being made towards an implementation for isEmail. > > I've noticed that work on the new Zend_Filter and > Zend_Validate classes is underway, and it appears as though > these will have greater options to address the fuller issues > of email address parsing (e.g. > domain and address validation). However, I am curious as to > whether there will be a stop gap implementation in the mean > time - even if it is imperfect? > > If there is no plans to implement something for isEmail > before the new class is brought into the incubator and then > library, would it be in fact better to remove the current > function from the current Zend_Filter class? > > I imagine most people who are after this functionality have > already sub-classed Zend_Filter or written/"borrowed" their > own parsing function. > > Thanks, > Andrew
RE: [fw-general] Zend_Filter::isEmail, re. issue ZF-42
Now JIRA is back up I've added our comments to http://framework.zend.com/issues/browse/ZF-42 Which I guess is the best place for them. It seems I didn't copy in the PHP code correctly since its lost all the space formatting - sorry! best wishes, Simon
RE: [fw-general] Zend_Filter::isEmail, re. issue ZF-42
Hi Bruno, Thanks for the links on isHostname format validity - I'll check them out. On checking the actual validity of an email address, I agree it would be great to give instant feedback to a user that the actual entered email address is invalid. However, I believe for most apps this would slow down the validation process too much (could easily be seconds). Forcing this to be within isEmail would be a bad thing in my opinion. I think this is more an application design issue, and any functionality to actually check a real email should be in some kind of network library (or another method in Zend_Filter). Then developers have the choice of using isEmail to check the syntax and also a network tool to check for the real email. Some developers may wish to do this when the user enters their email, some may wish to leave this task to an automated script to eliminate bad emails. Also, wouldn't the most reliable way to determine if an email is valid via the network be first get the MX domain which is used for that email address, and then open a connection to the domain on port 25 and send some sample commands, i.e. # dig MX yourdomain.com - returns mail.yourdomain.com as the answer to this DNS query # telnet mail.yourdomain.com 25 # HELO mydomain.com # MAIL FROM:[EMAIL PROTECTED] # RCPT TO:[EMAIL PROTECTED] This would usually return a status of 250 if the email address is valid. best wishes, Si
[fw-general] Zend_Filter::isEmail, re. issue ZF-42
Hi there,
I've been taking a brief look at Zend_Filter::isEmail over the Xmas hol to
see if I can tackle it and have a suggested starting point, which I've
copied below.
I was going to add this to the Issue Tracker, but I've had some problems
accessing it this morning. This issue also seems to have been reported by
Andris Paikens.
The method below splits up the email address and uses the existing test
Zend_Filter::isHostname to match the domain (which I think may need checking
against the RFC).
The local part of the email is then matched first against dot-atom
characters, which should cover 99% of all email addresses. The RFC also
states emails can also be in the quoted form or an obsolete form. Previous
email checkers I've reviewed seem to create regexes to match all 3 possible
formats, but since 99% of all email addresses will be covered by the
standard dot-atom I think it's better to first check for that. Which I also
think will be faster.
You'll see from the code below if the dot-atom characters aren't matched
further checks could be made against the quoted format and obselete ones -
though I haven't done those yet. The current code below will work for most
common emails, so with some testing could arguably be implemented now to
provide some email testing functionality.
--
public static function isEmail($value)
{
// Split email address up
if (preg_match('/^([EMAIL PROTECTED])@([EMAIL PROTECTED])$/', $value,
$matches)) {
$localPart = $matches[1];
$domain = $matches[2];
// Match domain part (allow hostnames and IP addresses)
$domainResult = self::isHostname($domain, 3);
// First try to match the local part on dot-atom characters
// since this is the most common format
$localResult = false;
// Dot-atom characters
// ALPHA / DIGIT / and "!", "#", "$", "%", "&", "'", "*", "+",
// "-", "/", "=", "?", "^", "_", "`", "{", "|", "}", "~", "."
// Dot character "." must be surrounded by other non-dot characters
$dotAtom = '[a-zA-Z0-9\x21\x23\x24\x25\x26\x27\x2a\x2b\x2d\x2f\x3d';
$dotAtom .= '\x3f\x5e\x5f\x60\x7b\x7c\x7d\x7e\x2e]';
// TODO: speed test strpos instead of preg_match for dot in start
and end of string
if ( (preg_match('/^' . $dotAtom . '+$/', $localPart)) &&
(!preg_match('/^\x2e/', $localPart)) && (!preg_match('/\x2e$/',
$localPart)) ) {
$localResult = true;
}
// If not matched, try quoted string format
if (!$localResult) {
// TODO
}
// if not matched, try obsolete format
if (!$localResult) {
// TODO
}
if ($localResult && $domainResult) {
return true;
}
}
return $false;
}
--
There was also some mention of this method checking the network to see if
the email address actually is valid. I am not sure if that is actually
required, though I don't beleive this is the best place for that kind of
check.
An email address tester should simply check the format, a separate network
tool would be required to actually test for a valid email. Network checking
would also impose a time delay so is probably best used asynchronously in a
separate cron script.
best wishes,
Simon
RE: [fw-general] Configuring Zend Framework with IIS
> This would definitely have to fall under the "hack" area, > because it is > a feature that would require additional configuration, and in other > words, is not a "pure" PHP implementation. Therefore, it is > unable to > be resolved solely through the Zend Framework. I don't know > if this is > a requirement, but I'm sure finding a solution solely through > ZF would > be superior... Well Apache requires configuration to get URL rewriting working too, so I don't think its likely that a pure PHP implementation is possible for Apache or IIS. Using a module like Isapi Rewrite seems the best option, especially since it uses the same syntax as Apache mod_rewrite. Though I was wondering if making use of the Error404 system in IIS was a valid way to get the basic re-routing to work in IIS without having to depend on third-party software. best wishes, Si
RE: [fw-general] Configuring Zend Framework with IIS
hi The URL format http://www.domain.com/index.php/test/my/vars works fine in IIS and copies the value "/index.php/test/my/vars" to $_SERVER['REQUEST_URI'] so I guess the standard *without rewrite* implementation should work without a hitch. Apart from using an ISAPI module (or ASP.NET for which you can code a simple rewrite apparently relatively easily from the tutorials I've seen around) one idea would be to hook into the use of an Error 404 page. I did a quick test on IIS 6.0 and for one test folder I set the Error 404 page to be sent to the absolute URL: /test/router.php So a fictional URL within my test folder: http://www.domain.com/test/view/apples/5 Resolves happily to the /test/router.php file and populates $_SERVER['REQUEST_URI'] with: /test/router.php?404;http://www.domain.com:80/test/view/apples/5 This may be an option, though I don't know if others would consider this too much of a hack in IIS? best wishes, Si
RE: [fw-general] Weird Issue (Slightly OT)
I can't claim to know how Zend Platform works but I don't see how: return isset($this->_vars[$key]) ? $this->_vars[$key] : null; would attempt to return $this->_vars[$key] by reference. Wouldn't the normal behaviour be to return a copy of that variable's content in PHP? If Zend Platform is changing behaviours that is odd. Perhaps a check of the exact PHP version on your laptop and Zend Platform server would be useful and posting that info plus the exact error messages to the list. best wishes, Si
RE: [fw-general] Anyone using/planning to use Zend_Db_Table?
[Chris..] > I use CakePHP for a project at work and all those queries only happen > when you're in debugging mode and it's not caching anything. In > production mode, it will cache all those queries that tell it what the > database structure is. Ah OK, that's better then! > It's important to realize that any sort of DB wrapper comes with > overhead. Indeed. As does the existence of a framework in the first place - but it saves developer time and makes things easier to maintain which is the whole point. [Markus..] > Personally, I prefer the "convention-over-configuration" style anyway > these days. I totally agree, and believe convention should be used wherever possible in ZF to make life easier (ie. default view template names, etc). > It becomes more difficult when trying to use a legacy schema > where you have no influence in the naming of your table columns. In Rails, for example, you can specify table and field names to get over this. As long as ZF has this kind of flexibility all will be fine. Si
RE: [fw-general] Anyone using/planning to use Zend_Db_Table?
> This is suboptimal for production because you insert yet another > layer (parsing) > impacting on performance. You'd better have a generator divided in > two parts. > One to read database schema and one to output it, so the second can > be made > to output php code or xml plus php code to parse it. Fair point. My idea is really guided by trying to keep the configuration of such a db mapping file as simple as possible since db automation will likely be a very popular core feature that new users will use in ZF. best wishes, Si
RE: [fw-general] Anyone using/planning to use Zend_Db_Table?
To answer your first question Nick, we are using Zend_Db_Table on two live e-commerce sites successfully, though only for the admin side of things. We have used Cake framework in the past and have been rather shocked at the number of SQL requests it makes to understand a table structure. So I'm certainly unhappy about doing that on a front-end site. So Markus's thought of using a mapping file of some kind to describe the data makes a lot of sense. A nice in-between method may be to include a command line scaffold script that auto-creates such DB mapping files to help new users build a site quickly. If such a file didn't exist, it could be generated on the fly at request time. Related to this do we have a "saved" folder concept within ZF where the app can save file data to, or is this just an application thing? Rails uses simple commands to manually associate foreign keys and linking tables together. However, most of the time these work on conventions (i.e. foreign key to a table called "clients" would be "clients_id" or perhaps the singular "client_id") so it is theoretically possible to automate this via a scaffold script. I understand Stefan's point on extending PHP classes, though I don't see that DB mapping requires the complexity of PHP. It may be neater to use a format such as XML or YAML to achieve this. I see the point of auto-complete but unless I've missed something that doesn't work when you use a factory to generate a class object since there is no direct link with the class name and object variable. And I would assume a DB class would use the factory method to instantiate such an object? One step further, if I was optimising such a system to work really quickly I'd cache any mapping information from an XML file to a serialised array for fast access. I don't know if such serialised file caching functionality already exists within ZF. best wishes, Simon
RE: [fw-general] Zend_Filter::isEmail() status
> I'll contact Cal. Assuming he agrees to sign the CLA, that should mean > that any of us can review and compare his implementation, right? If any help is required looking at these implementations I'd be happy to do some work on this. Been meaning to commit some time to ZF some time soon :) best wishes, Simon
[fw-general] Zend_Log_Adapter_File exception thrown in __destruct
Hi there, I'm sorry to say I haven't been keeping up with the mailing list that much of late due to client work, though I do plan to try and get some free time soon to help out more. Anyhow - I've been using Zend::log and was testing it by attempting to register a logfile which is not writeable by the web user - I found the __destruct() method of Zend_Log_Adapter_File calls $this->flush() which throws an exception if the file cannot be written to. Since __destruct() is not allowed to throw an exception this crashes PHP with the error: Fatal error: Exception thrown without a stack frame in Unknown on line 0 Is this a known issue? If not should I post to the issue tracker? best wishes, Simon www.studio24.net
