Re: [fw-general] Trouble with Zend_Layout
require_once "Zend/Layout.php";
Looks like you already manually included the file, but the autoloader is
trying to load it. I'd comment this line out and try again.
Kevin
On 10/3/08 2:33 PM, "Matthew Weier O'Phinney" <[EMAIL PROTECTED]> wrote:
> -- mezoni <[EMAIL PROTECTED]> wrote
> (on Friday, 03 October 2008, 11:00 AM -0700):
>> PluginLoader cannot load Zend_Layout.
>>
>> In my bootstrap.ph I use the following code:
>>
>> require_once "Zend/Layout.php";
>> Zend_Layout::startMvc(array('layoutPath' => self::$path .
>> '/application/modules/default/views/scripts'));
>> Zend_Layout::getMvcInstance()->getView()->addScriptPath(self::$path
>> . '/application/modules/default/views/scripts');
>>
>> But in layout.phtm at this line...
>>
>> layout()->content ?>
>>
>> ...PluginLoader to do the following...
>>
>> Zend_Loader::loadFile($classFile, $paths);
>>
>> ...and Zend_Loader add to paths paths from get_include_path()
>>
>> An I get the error
>>
>> Cannot redeclare class Zend_Layout
>
> Can you send your include_path, plus the helper paths from your view
> object ($view->getHelperPaths()), and indicate on what path your ZF
> install is? That wil help us diagnose better.
>
> Also, what version of ZF are you using? if it's from svn, can you tell
> us what revision ('svn info' in the top of the ZF checkout will give
> that info).
Re: [fw-general] controler + throw exception
Did you try assigning the exception message to a view variable in a javascript block at the top of your file? Kevin On 8/1/08 1:45 PM, "Samuel Verdier" <[EMAIL PROTECTED]> wrote: > Hi, > > I would like display an exception in javascript. > If an exception is lift in the controller, i want stay in the current page > and display the exception in javascript alert. > How can I do that ? > > > Samuel verdier Directeur technique > [EMAIL PROTECTED] > > www.pyxis.org > 150, allée du Pays d¹Oc, 34080 Montpellier - Tél. 04 67 10 77 88 - Fax > 04 67 10 77 87 > 41, rue Meslay, 75003 Paris - Tél. 01 42 85 55 04 - Fax 01 42 85 56 30 > >
[fw-general] Zend_Search_Lucene in shared memory
Has anyone ever tried storing a lucene index in shared memory? If we properly use semaphores to control access, are we going to have any problems? We have a huge lucene index, and we're trying to get its memory footprint smaller. Unfortunately, we didn't really follow best practices when we designed our search engine and we indexed a lot of non-text fields. As a result, Zend_Search_Lucene runs amok; it uses a TON of ram (lmore than 1GB). The obvious solution is to reduce the number of non-text fields we index. However, we'd really like to avoid that kind of refactoring at this stage in our app development. I'm trying to explore our other options. So, does anyone have any suggestions for using shared memory and/or reducing our memory footprint using Zend_Search_Lucene? Thank you, Kevin
RE: [fw-general] Establishing naming conventions for Zend Framework 2.0
> Drupal includes a migration script as well. > No, it's an update feature for end users so they can update their > database to the new schema/content. No, there IS a migration review script. It's not included in the core, but they do have a migration module. It's called coder (code-review). It reviews all your code for deprecated functionality and lets you go through and update it. However, since it's the only solution available for migrating modules and custom functionality it is a defacto standard. http://drupal.org/project/coder In the case of both Rails and Drupal, there are scripts that analyze your code and tell you were a deprecated function is used. I'm sure any example you can provide with a large install base will have something similar available. Kevin Hallmark PHP Developer Bonnier Corporation -Original Message- From: Amr Mostafa [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 27, 2008 2:44 PM To: Kevin Hallmark Cc: fw-general@lists.zend.com Subject: Re: [fw-general] Establishing naming conventions for Zend Framework 2.0 On Tue, May 27, 2008 at 7:43 PM, Kevin Hallmark <[EMAIL PROTECTED]> wrote: > On Tue, May 27, 2008 at 4:40 PM, Eric Marden <[EMAIL PROTECTED]> wrote: > I would not hold up Drupal as an example of any best practice. The fact that > there are basically three versions (4.x, 5.x, 6.2) in the wild running > simultaneously is insanity for anyone who has to do serious work with it. I'm not sure what you meant by 3 versions of Drupal. The only active version is 6.2, 5.x is only security supported so folks can take their time to upgrade to 6.2. Pretty normal. Even if you disagree with whatever policy they got, I'm just trying to make a point: Other *successful* [1] [2] [3] projects has been doing that and it never was a problem for their growth. Anyway, no more Drupal-talk from my side, it was just an evident "by the numbers" example nearby which I hoped would make you loosen your BC fears. Cheers, - Amr [1] http://www.webware.com/8301-13546_109-9913290-29.html [2] http://www.packtpub.com/award [3] http://drupal.org/drupal-wins-9-horizon-interactive-awards-studio-module-pingVision > > Upgrading to Rails 2.0 or Drupal 5.x -> 6.x would be difficult without them. > > Are details about the migration scripts going to be included in the proposal? > > Kevin Hallmark > PHP Developer > Bonnier Corporation > > > -Original Message- > From: Pádraic Brady [mailto:[EMAIL PROTECTED] > Sent: Tuesday, May 27, 2008 12:26 PM > To: fw-general@lists.zend.com > Subject: RE: [fw-general] Establishing naming conventions for Zend Framework > 2.0 > > > Hmm. Rails? ;) > > > Kevin Hallmark wrote: > > > > "I hope no harm done in taking other equally successful projects as good > > examples to reassure anyone with doubts" > > > > Do you have any other examples? Drupal isn't exactly the best example in > > my eyes. > > > > Kevin Hallmark > > > > > > > - > Pádraic Brady > > http://blog.astrumfutura.com > http://www.patternsforphp.com > OpenID Europe Foundation - Irish Representative > -- > View this message in context: > http://www.nabble.com/Establishing-naming-conventions-for-Zend-Framework-2.0-tp17332797p17494407.html > Sent from the Zend Framework mailing list archive at Nabble.com. > -- Amr Mostafa Head of Software Development, IT Synergy [EMAIL PROTECTED] http://itsyn.com +(2012)1700502 +(202)35371020
RE: [fw-general] Establishing naming conventions for Zend Framework 2.0
Rails 2.0 includes 'rake deprecated' Drupal includes a migration script as well. Upgrading to Rails 2.0 or Drupal 5.x -> 6.x would be difficult without them. Are details about the migration scripts going to be included in the proposal? Kevin Hallmark PHP Developer Bonnier Corporation -Original Message- From: Pádraic Brady [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 27, 2008 12:26 PM To: fw-general@lists.zend.com Subject: RE: [fw-general] Establishing naming conventions for Zend Framework 2.0 Hmm. Rails? ;) Kevin Hallmark wrote: > > "I hope no harm done in taking other equally successful projects as good > examples to reassure anyone with doubts" > > Do you have any other examples? Drupal isn't exactly the best example in > my eyes. > > Kevin Hallmark > > - Pádraic Brady http://blog.astrumfutura.com http://www.patternsforphp.com OpenID Europe Foundation - Irish Representative -- View this message in context: http://www.nabble.com/Establishing-naming-conventions-for-Zend-Framework-2.0-tp17332797p17494407.html Sent from the Zend Framework mailing list archive at Nabble.com.
RE: [fw-general] Establishing naming conventions for Zend Framework 2.0
Are there any technical advantages to changing the names? Are the names of classes holding the development of Zend Framework back? How many times a day do you go to the documentation to lookup a function or class name? Not for the arguments, or usage examples, but the NAME. Kevin From: Matthew Ratzloff [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 21, 2008 5:19 PM To: Kevin Hallmark Cc: Zend Framework General Subject: Re: [fw-general] Establishing naming conventions for Zend Framework 2.0 Really, your arguments come down to this: Advantages 1. Consistent naming is less confusing so you don't have to go to the API Disadvantages 1. Breaks backwards-compatibility (the degree to which is undetermined at present) A migration tool is only useful if the community wants it, and it's not as if someone working on it would necessarily be working on something else for the project. Finally, you have mentioned a "compatibility layer" several times now. Can someone explain how such a layer would work? If I create a new instance of Zend_Example, I'm not going to get a Zend_Sample object back. -Matt On Wed, May 21, 2008 at 1:17 PM, Kevin Hallmark <[EMAIL PROTECTED]> wrote: So I went back and culled the advantages and disadvantages of changing the names of classes and methods. This is what I found. Advantages are: 1. Consistent naming is less confusing so you don't have to go to the API Disadvantages are: 1. breaking existing applications using ZF 2. force the developers who have been working with ZF (customers) to relearn the api 3. extra community/developer resources spent writing the "migration tool" or compatibility layer instead of adding new features 4. increasing the cost of upgrading ZF By forcing all the developers to relearn the API, we're all going to have to check the docs for a while anyway. Those people with a good handle on the API already don't need to go to the docs. This effectively negates the one advantage. Are any features being inhibited by the current naming scheme? Why should we do this again? The negatives seem to far outweigh the positives. Can someone list any more than one advantage? Kevin Hallmark PHP Developer Bonnier Corporation
RE: [fw-general] Establishing naming conventions for Zend Framework 2.0
So I went back and culled the advantages and disadvantages of changing the names of classes and methods. This is what I found. Advantages are: 1. Consistent naming is less confusing so you don't have to go to the API Disadvantages are: 1. breaking existing applications using ZF 2. force the developers who have been working with ZF (customers) to relearn the api 3. extra community/developer resources spent writing the "migration tool" or compatibility layer instead of adding new features 4. increasing the cost of upgrading ZF By forcing all the developers to relearn the API, we're all going to have to check the docs for a while anyway. Those people with a good handle on the API already don't need to go to the docs. This effectively negates the one advantage. Are any features being inhibited by the current naming scheme? Why should we do this again? The negatives seem to far outweigh the positives. Can someone list any more than one advantage? Kevin Hallmark PHP Developer Bonnier Corporation From: Pádraic Brady [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 21, 2008 3:20 PM To: Matthew Ratzloff Cc: Zend Framework General Subject: Re: [fw-general] Establishing naming conventions for Zend Framework 2.0 I think people should bear in mind the specifics - we're talking about name changes only. There's nothing here a few seconds with regular expressions with a token engine (if even that), which Matthew has already stated is a likely pre-condition for a migration tool, can't fix. Your entire problem with running new tests is likewise inconsequential. Even a minor version update needs the same treatment as good practice. Pádraic Brady http://blog.astrumfutura.com http://www.patternsforphp.com OpenID Europe Foundation Member-Subscriber <http://www.openideurope.eu/> - Original Message From: Matthew Ratzloff <[EMAIL PROTECTED]> To: Kevin Hallmark <[EMAIL PROTECTED]> Cc: Zend Framework General Sent: Wednesday, May 21, 2008 4:56:11 PM Subject: Re: [fw-general] Establishing naming conventions for Zend Framework 2.0 On Wed, May 21, 2008 at 7:36 AM, Kevin Hallmark <[EMAIL PROTECTED]> wrote: > > How big are your applications..? The one I'm working on right now has 30 > different controllers, 25 models and 100 view scripts. That's more than an > hour... without considering any sort of software quality assurance procedure. A search and replace for a handful of names should only take a few microseconds longer in a large application versus a small one. "Zend_Example_Class" to "Zend_Sample_Class" is an unambiguous change, and as Matthew O. stated, an automated tool should exist to assist you in the transition. > This may not be as much of a concern for small shops with a couple > small-medium size applications, but in a large company with many applications > having uptime and quality requirements you have a software quality assurance > lifecycle process to take into account. The whole process of testing and > verifying code changes is not trivial, it can take weeks or months to get a > release vetted and ready. In an environment like you describe, a change like this should be rolled into a feature upgrade that requires Zend Framework 2.0. > If I had just added the new feature the time to test the changed areas of the > code is minimal, but large changes cause the entire application to go though > these large testing phases AGAIN (because they already went through it when > the site launched). This increases the time horizon for what should be an > easy feature to weeks or months. If I need feature foo within days or a week, > API changes make foo impossible. Think of the costs in time, money, and > resources these ultimately aesthetic changes can cause. Upgrading > applications that use ZF to a new API would involve no less than 10-15 > different people. That's expensive. Upgrading to any new version of something as deep-rooted as a framework requires a complete regression pass anyway, and 2.0 will be no different regardless of naming standards. Software must be able to change in order to improve. Given what I said above, I don't think that such a change would be an undue burden. -Matt
RE: [fw-general] Establishing naming conventions for Zend Framework 2.0
Eek. I wasn't done with that yet. I guess my points still stand, but they are not as well composed as I would like. Sorry about that. Kevin -Original Message- From: Kevin Hallmark [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 21, 2008 12:58 PM To: Matthew Ratzloff Cc: Zend Framework General Subject: RE: [fw-general] Establishing naming conventions for Zend Framework 2.0 I'll summarize this post in saying that there really should be a compatibility period. Rebuttal: First Adam: It is guaranteed that all changes will be unambiguous? "an automated tool should exist to assist you in the transition." I still have to manually verify the results of the tool. In all likelihood, a tool could even do more damage to the code. The question then becomes, is it easier to do it by hand or verify the results of the tool. Either way, I still have to look at just about every single line of code. "In an environment like you describe, a change like this should be rolled into a feature upgrade that requires Zend Framework 2.0." I'm confused... feature foo WOULD be an upgrade that requires ZF2. So yeah, it would be rolled into a feature upgrade that requires ZF2. "Upgrading to any new version of something as deep-rooted as a framework requires a complete regression pass anyway, and 2.0 will be no different regardless of naming standards." You're right, it will require regression testing. But there is a difference between testing code that is unchanged, and testing code that is changed. With a compatibility layer, I can be reasonably assured that my legacy code will continue to function. As we make upgrades in the future, we can migrate each area we work on to the new naming conventions. Ideally, that regression pass should only occur once, and should produce few if any bugs. The question is, how much time should people be given to shoulder the burden of changing the naming conventions. Without a compatibility layer, that time horizon is short. With a compatibility layer, sites can be upgraded incrementally. A perfect example of how this should be done is Zend_Db. From ZF1.0 -> 1.5, they introduced a new way of doing thing. All my code now uses the 1.5 way, but the old one still worked. When upgrading to 1.5, we made 0 code changes. Zero. And that's how a well designed upgrade should behave. Kevin -Original Message- From: Matthew Ratzloff [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 21, 2008 11:56 AM To: Kevin Hallmark Cc: Zend Framework General Subject: Re: [fw-general] Establishing naming conventions for Zend Framework 2.0 On Wed, May 21, 2008 at 7:36 AM, Kevin Hallmark <[EMAIL PROTECTED]> wrote: > > How big are your applications..? The one I'm working on right now has 30 different controllers, 25 models and 100 view scripts. That's more than an hour... without considering any sort of software quality assurance procedure. A search and replace for a handful of names should only take a few microseconds longer in a large application versus a small one. "Zend_Example_Class" to "Zend_Sample_Class" is an unambiguous change, and as Matthew O. stated, an automated tool should exist to assist you in the transition. > This may not be as much of a concern for small shops with a couple small-medium size applications, but in a large company with many applications having uptime and quality requirements you have a software quality assurance lifecycle process to take into account. The whole process of testing and verifying code changes is not trivial, it can take weeks or months to get a release vetted and ready. In an environment like you describe, a change like this should be rolled into a feature upgrade that requires Zend Framework 2.0. > If I had just added the new feature the time to test the changed areas of the code is minimal, but large changes cause the entire application to go though these large testing phases AGAIN (because they already went through it when the site launched). This increases the time horizon for what should be an easy feature to weeks or months. If I need feature foo within days or a week, API changes make foo impossible. Think of the costs in time, money, and resources these ultimately aesthetic changes can cause. Upgrading applications that use ZF to a new API would involve no less than 10-15 different people. That's expensive. Upgrading to any new version of something as deep-rooted as a framework requires a complete regression pass anyway, and 2.0 will be no different regardless of naming standards. Software must be able to change in order to improve. Given what I said above, I don't think that such a change would be an undue burden. -Matt
RE: [fw-general] Establishing naming conventions for Zend Framework 2.0
I'll summarize this post in saying that there really should be a compatibility period. Rebuttal: First Adam: It is guaranteed that all changes will be unambiguous? "an automated tool should exist to assist you in the transition." I still have to manually verify the results of the tool. In all likelihood, a tool could even do more damage to the code. The question then becomes, is it easier to do it by hand or verify the results of the tool. Either way, I still have to look at just about every single line of code. "In an environment like you describe, a change like this should be rolled into a feature upgrade that requires Zend Framework 2.0." I'm confused... feature foo WOULD be an upgrade that requires ZF2. So yeah, it would be rolled into a feature upgrade that requires ZF2. "Upgrading to any new version of something as deep-rooted as a framework requires a complete regression pass anyway, and 2.0 will be no different regardless of naming standards." You're right, it will require regression testing. But there is a difference between testing code that is unchanged, and testing code that is changed. With a compatibility layer, I can be reasonably assured that my legacy code will continue to function. As we make upgrades in the future, we can migrate each area we work on to the new naming conventions. Ideally, that regression pass should only occur once, and should produce few if any bugs. The question is, how much time should people be given to shoulder the burden of changing the naming conventions. Without a compatibility layer, that time horizon is short. With a compatibility layer, sites can be upgraded incrementally. A perfect example of how this should be done is Zend_Db. From ZF1.0 -> 1.5, they introduced a new way of doing thing. All my code now uses the 1.5 way, but the old one still worked. When upgrading to 1.5, we made 0 code changes. Zero. And that's how a well designed upgrade should behave. Kevin -Original Message- From: Matthew Ratzloff [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 21, 2008 11:56 AM To: Kevin Hallmark Cc: Zend Framework General Subject: Re: [fw-general] Establishing naming conventions for Zend Framework 2.0 On Wed, May 21, 2008 at 7:36 AM, Kevin Hallmark <[EMAIL PROTECTED]> wrote: > > How big are your applications..? The one I'm working on right now has 30 different controllers, 25 models and 100 view scripts. That's more than an hour... without considering any sort of software quality assurance procedure. A search and replace for a handful of names should only take a few microseconds longer in a large application versus a small one. "Zend_Example_Class" to "Zend_Sample_Class" is an unambiguous change, and as Matthew O. stated, an automated tool should exist to assist you in the transition. > This may not be as much of a concern for small shops with a couple small-medium size applications, but in a large company with many applications having uptime and quality requirements you have a software quality assurance lifecycle process to take into account. The whole process of testing and verifying code changes is not trivial, it can take weeks or months to get a release vetted and ready. In an environment like you describe, a change like this should be rolled into a feature upgrade that requires Zend Framework 2.0. > If I had just added the new feature the time to test the changed areas of the code is minimal, but large changes cause the entire application to go though these large testing phases AGAIN (because they already went through it when the site launched). This increases the time horizon for what should be an easy feature to weeks or months. If I need feature foo within days or a week, API changes make foo impossible. Think of the costs in time, money, and resources these ultimately aesthetic changes can cause. Upgrading applications that use ZF to a new API would involve no less than 10-15 different people. That's expensive. Upgrading to any new version of something as deep-rooted as a framework requires a complete regression pass anyway, and 2.0 will be no different regardless of naming standards. Software must be able to change in order to improve. Given what I said above, I don't think that such a change would be an undue burden. -Matt
RE: [fw-general] Establishing naming conventions for Zend Framework 2.0
+1 for API changes with a transition period -1 for API changes without a transition period. "Personally, I welcome BC breaks of any kind if they result in a better framework. In my opinion a better framework that'll make my life easier in the long run is far more important than an hour or so updating my application to work with it." - Jack How big are your applications..? The one I'm working on right now has 30 different controllers, 25 models and 100 view scripts. That's more than an hour... without considering any sort of software quality assurance procedure. In an ideal world, there would be time to refactor code for technical reasons. However, in the real world, there are time and resource constraints. If I need a feature 'foo' that is only available in ZF2.0, I'll be forced to spend hours rushing to upgrade an entire application for that one feature. That has the potential to introduce regression bugs, and other errors into an otherwise perfectly functional application. That takes me away from other critical development I might need to do. This may not be as much of a concern for small shops with a couple small-medium size applications, but in a large company with many applications having uptime and quality requirements you have a software quality assurance lifecycle process to take into account. The whole process of testing and verifying code changes is not trivial, it can take weeks or months to get a release vetted and ready. If I had just added the new feature the time to test the changed areas of the code is minimal, but large changes cause the entire application to go though these large testing phases AGAIN (because they already went through it when the site launched). This increases the time horizon for what should be an easy feature to weeks or months. If I need feature foo within days or a week, API changes make foo impossible. Think of the costs in time, money, and resources these ultimately aesthetic changes can cause. Upgrading applications that use ZF to a new API would involve no less than 10-15 different people. That's expensive. I'm all for visible benefits for the developer, however changing names for what really amounts to aesthetics while breaking BC is NOT a benefit; it's a detriment. It's NOT 'easier'. My work increases 100 fold with needless API changes, especially without a compatibility layer. At least with a compatibility layer, I can refactor my code in incremental releases over several months. If ZF2.0 completely breaks my application, then I'll have to do a rushed job converting the code just to get feature foo. Ultimately, changing API's is an incredibly expensive proposition. "If by afraid you mean 'spend more resources fixing something that was not broken without a visible and real benefit for the customer' yes I am terrified" - mbneto I think that hits the nail right on the head. Especially when you consider that you and I are the 'customers' of Zend Framework. ZF would be changing, with little benefit to its customers. At least a compatibility layer gives us time to make and test our changes. Kevin From: Jack Sleight [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 21, 2008 8:18 AM Cc: Zend Framework General Subject: Re: [fw-general] Establishing naming conventions for Zend Framework 2.0 If by afraid you mean 'spend more resources fixing something that was not broken without a visible and real benefit for the customer' yes I am terrified :) What's wrong with a visible and real benefit for the developer? Sure, your customers won't see any change, but that doesn't mean you shouldn't try to make your own life easier. Personally, I welcome BC breaks of any kind if they result in a better framework. In my opinion a better framework that'll make my life easier in the long run is far more important than an hour or so updating my application to work with it. -- Jack
RE: [fw-general] INSERT IF NOT EXISTS with Zend_Db_Table_Row
I actually ended up solving my problem at the SQL level.
I was tracking statistics. I'm tracking each and every hit of 6
different types to an incredibly simple table. I also needed to track
the daily aggregate of hit types, per 'page' per day ('page' is the data
I'm tracking for). For ease of generating reports, I wanted all the
different hit types in one row. (Generating the report I needed would
have required 6 queries per row for 'page' listings sometimes totaling
hundreds of 'pages' so 6*x where x is the number of 'pages' in the list)
The reason I needed 'ignore' was so I could insert the 'page'/date keyed
row no matter what (making sure it's there). Then increment the
appropriate tally.
It turns out the best solution was an AFTER INSERT trigger. I wrote a
little stored procedure to INSERT IGNORE and then UPDATE the appropriate
hit type. Then I just call that SP from the trigger.
Kevin Hallmark
PHP Developer
Bonnier Corporation
-Original Message-
From: Bart McLeod [mailto:[EMAIL PROTECTED]
Sent: Thursday, May 15, 2008 4:01 AM
To: Kevin Hallmark
Cc: fw-general@lists.zend.com
Subject: Re: [fw-general] INSERT IF NOT EXISTS with Zend_Db_Table_Row
I handle this at the level of the model using an exists($keys : Array)
method on a generic DataObject. A dataobject is like an active record.
That way you can check myDataObject->exists() to find out what you have
to do.
Regards,
Bart McLeod
Kevin Hallmark schreef:
>
> For future reference for anyone who has my problem:
>
> http://www.nabble.com/REPLACE-queries-on-Zend_Db-td15617859.html
>
> Basically, as far as I can tell, Zend_Db doesn't support 'INSERT
> IGNORE' or 'ON DUPLICATE KEY UPDATE' syntax using Zend_Db_Table and
> Zend_Db_Table_Row.
>
> You're only choice is to use the query method of the Zend_Db_Adapter
> class of your choice and manually creating the query.
>
> Kevin Hallmark
>
>
>
> *From:* Kevin Hallmark [mailto:[EMAIL PROTECTED]
> *Sent:* Tuesday, May 13, 2008 9:53 AM
> *To:* fw-general@lists.zend.com
> *Subject:* [fw-general] INSERT IF NOT EXISTS with Zend_Db_Table_Row
>
> Is it possible to INSERT IF NOT EXITSTS using a Zend_Db_Table_Row or
> should I generate the query by hand?
>
> I searched the docs but I couldn't find anything.
>
> Kevin Hallmark
>
RE: [fw-general] Dumb Question
I usually access the database through my table objects.
However, recently I've needed to do things directly with the database
object. I found the simplest choice was $GLOBALS['db'] = $db.
It's so rare that I directly use it, and a global lookup is pretty cheap
(right?). Anytime I need an object instantiated in my bootstrap I'll
assign it to a global. If I access it more than once in a function, I'll
either localize the variable or try and get it a more reliable way.
I didn't think about using:
Zend_Db_Table_Abstract::getDefaultAdapter();
That seems like it might be a good alternative choice.
Kevin Hallmark
PHP Developer
Bonnier Corporation
-Original Message-
From: Jim Scherer [mailto:[EMAIL PROTECTED]
Sent: Thursday, May 15, 2008 10:12 AM
To: fw-general@lists.zend.com
Subject: Re: [fw-general] Dumb Question
if you are using Zend_Controller_Front as I am you can set it as a
parameter:
$frontController = Zend_Controller_Front::getInstance();
$frontController->setParam('db', $db)
and then in your controller:
$this->getFrontController()->getParam('db')
So many ways to skin a cat.
Jim
Joseph Crawford wrote:
>
> In my index.php bootstrap file I setup the database connection into a
> variable $db. Now I need to access this in other controllers. This
> seems like a dumb question to me but do I need to global $db; before I
> can access it in the indexAction method of the controller or is it in
> the global scope by default?
>
> Thanks,
> Joseph Crawford
>
>
--
View this message in context:
http://www.nabble.com/Dumb-Question-tp17253025p17254165.html
Sent from the Zend Framework mailing list archive at Nabble.com.
RE: [fw-general] MVC - where can I learn more about the "model"?
Here is a little advice for people who want some guidance on creating
their a model layer:
NOTE: This is merely a simple example, for guidance only. YMMV. There
are a million different ways to do this kind of thing, this is merely
one I have found effective.
In my apps, I generally create a BaseModel class, from which all others
inherit. In this class, I'll define a basic API that I want all models
to subscribe to. This is usually something like __get, __set,
setDataFromArray, validate (verify data is correct), filter (filter
input data), save and other common methods.
This setup lets you change the backend storage mechanism easily. If all
your model objects use the same API, you can change the underlying
storage code of all your models simultaneously and your app is
none-the-wiser.
An example:
Say I begin by using an array to store my data. Suddenly, I realize I
want to store my data inside a database. I can change all the methods in
my model to set data to a database object. Later in the project, I
decide that XML would be a better choice. I can change my methods to
write to an XML data file, and once again I don't have to change my
application code.
You can implement custom behavior by overriding methods and using the
'parent' keyword to call the BaseModel method implementation.
In most apps these days, my BaseModel class directly extends
Zend_Db_Table_Row. Extending Zend_Db_Table_Row allows my model objects,
with all their custom functionality, to be returned directly by
Zend_Db_Table function calls. Creating lists is much faster when you
don't have to iterate the result set a second time to create model
objects from them.
I usually won't override the methods I want to use from
Zend_Db_Table_Row (__get, __set, setDataFromArray). If I needed to
change my storage engine I would implement these methods in my BaseModel
to access the new data storage mechanism.
In each of my BaseModel subclasses, I'll usually add some static getter
methods.
For example:
Class User extends BaseModel {
Public static function getUser($user_id = null) {
//return a setup model object
$table = new users();//where users is your table class
If($user_id === null) {
$return = $table->createRow();
} else {
//get row from db
}
Return $return;
}
This function would return the model object for '$user_id', or an empty
object if null. You can call this method with
Each model then has a single point of origin. If I decide to change my
implementation, I can be assured that "User::getUser" always will give
me a fully qualified User object.
You can also create similar functions the will return a list of rows.
Hope this small bit of advice helps get your started.
Kevin Hallmark
PHP Developer
Bonnier Corporation
460 N Orlando Ave Suite 200
Winter Park, FL 32789
(407) 571-4960
[EMAIL PROTECTED]
-Original Message-
From: Karol Grecki [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 13, 2008 2:24 PM
To: fw-general@lists.zend.com
Subject: Re: [fw-general] MVC - where can I learn more about the
"model"?
Rishi
You're not the first nor the last to be confused by this, but it's
actually
very simple once you realise it. If you remove views and controller,
what's
left? Business logic, data and anything specific to your application.
Let
say you need to represent a user in your system, or a client, those are
your
models. Often they are persistent in a database, some people even use
Zend_Db_Table as a model, but it can be anything, there are no rules of
what
model is, it's up to you and it will be determined by what you're
building.
Karol
Rishi Daryanani wrote:
>
> Hi,
> I'm a total newbie, but I am reading up on the Zend
> framework and trying out some tutorials, very useful..
> However everything I've read/tried involves the
> "application/views" and "application/controllers"
> directories to create views and controllers. I have
> not yet come across any mention of the "models"
> subdirectory.
>
> Where can I learn more about this and what it's used
> for?
>
> Am I right in assuming that I can build my own
> functionality (e.g. user login form, CMS) entirely
> with the concept of a controller and view? (but not a
> model)
>
> Many thanks
>
>
>
>
>
--
View this message in context:
http://www.nabble.com/MVC---where-can-I-learn-more-about-the-%22model%22
--tp17211735p17215213.html
Sent from the Zend Framework mailing list archive at Nabble.com.
RE: [fw-general] INSERT IF NOT EXISTS with Zend_Db_Table_Row
For future reference for anyone who has my problem: http://www.nabble.com/REPLACE-queries-on-Zend_Db-td15617859.html Basically, as far as I can tell, Zend_Db doesn't support 'INSERT IGNORE' or 'ON DUPLICATE KEY UPDATE' syntax using Zend_Db_Table and Zend_Db_Table_Row. You're only choice is to use the query method of the Zend_Db_Adapter class of your choice and manually creating the query. Kevin Hallmark ____ From: Kevin Hallmark [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 13, 2008 9:53 AM To: fw-general@lists.zend.com Subject: [fw-general] INSERT IF NOT EXISTS with Zend_Db_Table_Row Is it possible to INSERT IF NOT EXITSTS using a Zend_Db_Table_Row or should I generate the query by hand? I searched the docs but I couldn't find anything. Kevin Hallmark
[fw-general] INSERT IF NOT EXISTS with Zend_Db_Table_Row
Is it possible to INSERT IF NOT EXITSTS using a Zend_Db_Table_Row or should I generate the query by hand? I searched the docs but I couldn't find anything. Kevin Hallmark
RE: [fw-general] Datagrid in Zend Framework
Filpe, I'm planning to split off the site specific code and release my TableMaker script this weekend. I'll be happy to let you know when that is done. I'll try and draft together a little usage example explaining the different aspects of the helper. I'll make an announcement on this list for interested parties. Since this is my work e-mail, I won't make the announcement on this list until Monday. Kevin Hallmark PHP Developer Bonnier Corporation 460 N Orlando Ave Suite 200 Winter Park, FL 32789 (407) 571-4960 [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> From: Eric Marden Sent: Wednesday, May 07, 2008 3:52 PM To: fw-general@lists.zend.com Subject: RE: [fw-general] Datagrid in Zend Framework One of our developers created a helper that is model aware and outputs a table with those features. Its pretty flexible, and generic and are using it for many different models (i.e. its not tied to something, but instead ready to work with any of our model object). There is some talk about cleaning this up and releasing it for free, but its not quite ready for that yet. -- Eric Marden From: Filipe Carvalho [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 07, 2008 11:40 AM To: fw-general@lists.zend.com Subject: [fw-general] Datagrid in Zend Framework Hi all, I'm looking for something like phpGrid (http://www.phpgrid.com/). Not so advanced... i will be happy in having out the box features like: - Paging - Sorting columns - Capability to create links values of some columns It is not hard to do it, but using model-view-controller pattern I can't realize how to do something clean and reusable. Can you give some clues how to do it? Best Regards, Filipe Carvalho
