Hello, sfLucenePlugin should work fine with sf1.2 and Propel. However I have added some new features for doctrine but they can be easily port for Propel and they not break the core plugin.
If you want to give a hand, feel free to send me a patch On Thu, Feb 26, 2009 at 7:39 PM, Michael Smith <[email protected]> wrote: > > For info on loading the zend framework see > > http://www.symfony-project.org/jobeet/1_2/Propel/en/16#chapter_16_sub_installing_and_configuring_the_zend_framework > also for using zend search with symfony > http://www.symfony-project.org/jobeet/1_2/Propel/en/17 > > Thanks, > Michael > > On Feb 26, 11:16 am, Java Guy <[email protected]> wrote: > > Hi, > > > > My expertise is in J2EE, I'm new to symfony and PHP, but I'm using > > these for my current side-project. > > > > I am currently trying to integrate symfony 1.2 with the Zend Lucene > > Search library shipped with ZendFramework 1.7.5. I notice that > > symfony has a plugin for this, but it seems to be in a beta release, > > and it also seems to be Doctrine based, whereas I'm using Propel. So > > I am leaning toward interfacing with the Zend libraries myself. > > > > The question I have is how to deal with the Zend's class loading. > > I've added my zend libraries to <project-dir>/lib/vendor/Zend/Search. > > > > However, whenever I instantiate my index, eg: > > > > // Create index > > $index = Zend_Search_Lucene::create(sfConfig::get > > ('app_zend_search_index_location', true)); > > > > I am running into errors because Lucene.php has a ton of require > > statements, based on its own path structure, eg: > > > > require_once 'Zend/Search/Lucene/Search/QueryParser.php'; > > > > What's the best way around this? A few options come to mind: > > > > 1) Simply comment out all the require statements and rely on Symfony's > > autoloading feature. I am not crazy about this option because it is a > > vendor product, and creates maintenance overhead. > > > > 2) Somehow allow Zend to pick up these require statements. I'm not > > quite sure how to go about doing this. I did some reading on the > > autoloader, and if I am going to modify my autoloader, I'd like to get > > an idea for best practices on this front. > > > > For example, I have another vendor product - the Swift mailer. The > > mailer didn't have this kind of issue, because it has its own class > > loader to resolve this stuff. So if I modify the autoloader config, > > I'd like to adopt an approach that works well across the whole > > project. I haven't been able to dig up some good examples to base my > > approach on yet. > > > > Your feedback and discussion is much appreciated. > > > > Thanks, > > Steve > > > -- Thomas Rabaix --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "symfony users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/symfony-users?hl=en -~----------~----~----~----~------~----~------~--~---
