Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.
Module Name: Dreatly IDX - http://www.camidoo.com/drealty.tar.gz
Recently written an IDX solution for Drupal, and would like to release it into the wild!
The module was written to allow RETS and flat file feeds from MLS servers to be imported as nodes. This module differs from them in that it allows for multiple server connections, meaning it can connect to and import data from more than one MLS server. It also allows for the importing of open house, agent, and office imports. The goal of Drealty IDX is to mature into a full fledged IDX solution built on top of Drupal.
Before writing this module I researched existing modules to see if there was one that was similar that could used to fulfill the requirements of a project I'm currently working on. Only found 1 project MLS ( http://www.drupal.org/project/mls ) that was geared towards an IDX solution. There hasn't been a commit on that project in over a year and it wasn't really what i was looking for, so i set off to write one that met the requirements my clients had set out. About three quarters of the way through the development of that module Garrett Albright ( http://drupal.org/user/191212 ) released PIRETS ( http://www.drupal.org/project/pirets ). When this was released i suspended development of the module i was working on to investigate what he had done and to see if PIRETS would work for my current project. My initial thoughts were that this is an awesome module and it could definitely be enhanced to suit my needs. I quickly started working with PIRETS and set out to contribute some enhancements and improvements.
After reporting some issues and submitting some patches for PIRETS, I announced my desire to contribute to the module and help further it along as there are really no strong contrib modules that are geared towards the Real Estate market. Here's a thread on the issue queue for PIRETS where I've offered to implement some enhancements and some dialog between the module's author and myself. ( http://drupal.org/node/726392 ).
After speaking with sun (tha_sun) in IRC one evening, concerning applying for cvs access and policies concerning modules that duplicate functionality and code, It was suggested that I make a few more attempts in convincing Garrett / PIRETS into maybe incorporating my additions / enhancements into PIRETS instead of releasing another module loosely based on PIRETS that just (in a nut shell) extended the functionality. So I set out to initiate more dialog with Garrett and see about just rolling up these enhancements into PIRETS and moving on, as I completely agreed with sun, and cvs would be a much better place without duplicated functionality / code. However, after some lengthy consideration, and a particular comment by Garrett ( http://drupal.org/node/726392#comment-2692402 ). I've decided to go ahead and apply for cvs access as the module that i'm submitting, is loosely similar to PIRETS in functionality, it is enhanced and modified at a level that to incorporate the changes into PIRETS would mean a complete re-write for that module, which is quite possibly counter productive, in that he has clients that are using the PIRETS module in production.
A note concerning 3rd party libraries:
Drealty IDX currently uses a 3rd party library called phRets (http://troda.com/projects/phrets/index.php?title=Main_Page). I've read and understand completely: http://drupal.org/node/422996. According to this policy an exception can be made if (see 3.1) "Exceptions can be made if the 3rd party library:" ... "had to be modified to work with Drupal and this modifications wasn't accepted by the original author".
I've spoken with the library's author Troy Davisson (troy.davisson@gmail.com) about including phRets in the module and about the possibility of accepting changes to the library that make it compatible with Drupal. He was fine with the library being included, however he wasn't interested in maintaining an alternative version of the library targeted to a specific framework. The modifications that were needed to be compatible with Drupal were merely replacing die() calls with watchdog(); return false; entries so that the library would gracefully handle errors and not bring Drupal to a screeching halt. If this isn't an acceptable exception to the 3rd party library inclusion policy for CVS i'll be happy to remove the library from the module and make it available outside of the CVS.
Hopefully this is enough information to consider me for cvs access on this module! Thanks and have a great day! In the event that more information is needed chris@camidoo.com irc: camidoo normally in #drupal / #drupal-support / #drupal-contrib
| Comment | File | Size | Author |
|---|---|---|---|
| #21 | drealty-6.x-1.0-beta-11.zip | 70.11 KB | camidoo |
| #19 | drealty-6.x-1.0-beta-10.zip | 70.1 KB | camidoo |
| #16 | drealty-6.x-1.0-beta-9.zip | 70.07 KB | camidoo |
| #11 | drealty-6.x-1.0-beta-7.zip | 49.57 KB | camidoo |
| #10 | drealty-6.x-1.0-beta6.zip | 46.97 KB | camidoo |
Comments
Comment #1
camidoo commentedattaching module.
Comment #2
camidoo commentedstatus changed to needs review
Comment #3
camidoo commentedAfter reading my motivation snippet i figured it might be worth while to include a list of features:
dReatly IDX offers the following functionality:
Comment #4
avpadernoHello, and thanks for applying for a CVS account. I am adding the review tags, and some volunteers will review your code, pointing out what needs to be changed.
As per CVS application requirements, the proposed module must not duplicate existing work; as you made references to two different modules, you should report the differences between the existing projects, and the proposed one.
Comment #5
camidoo commentedIt differs from the MLS module in that it can consume a RETS feed directly. The MLS module (self admittedly) has some major design flaws which prevent it from working with various MLS services and advises users to either be a php developer, know one, or be prepared to hire one to make his module work correctly. (taken from http://www.drupal.org/project/mls )
Further, neither of the two modules i referenced allows for the setup and consumption of multiple MLS servers, both only allow for the consumption of a single feed, a 1:1 relationship if you will. Where as dRealty IDX allows for the setup of many-to-one relationship, allowing brokers that service different MLS areas to consume MLS services from more than one association, as many belong to multiple associations. This is a pretty big design difference.
MLS is a d5 module as well, where as this is a D6 module.
PIRETS only allows for importing Property Listings, which is only a subset of the data that is provided by the various MLS services. dRealty IDX allows for the importing of all standard data types provided by the various IDX / MLS / RETS specifications.
Neither of the modules provide for a way to import and export connection profiles.
Neither of the modules provide for a way to customize the cck field types that are created upon feed creation.
Comment #6
Macronomicus commentedHi ive been testing the drealty module for a project of mine and am currently using it in my projects development.
Just wanted to share a few thoughts... I would go as far as to say that neither of the aforementioned modules perform anywhere near as fast as drealty; nor do they have a stated focus on performance. Drealty will also include methods and means for using solr to browse the properties, this seems like a logical fit as nothings worse than a slow real estate search.
While I dont like code repetition, I doubt you could fairly say that is the case here; drealty as it is now and certainly in what its to become is a unique tool that goes beyond the scope of whats out there without invalidating their purpose. I think all three of these options are more than capable of co-existing in the drupalsphere and servicing different target users with their varying levels of functionality/purpose. Besides that real estate stuff for drupal is too far and few between... were talking about the only three modules targeted towards one of the largest web-design market segments there are.
Cheers!
Comment #7
avpadernoI am changing status basing on the previous comment.
Comment #8
camidoo commentedSome clean up from the original submission.
Comment #9
camidoo commentedanother updated version
Comment #10
camidoo commentedmore updates..
Comment #11
camidoo commentednew file, some updates / fixes, added text to the readme
Comment #12
Macronomicus commentedIm marking this as rtbc since I have been working with it for a while now and it definitely works ... it would be nice to have an issues cue and such to go along with this so we can track and fix bugs and features etc.
Comment #13
avpadernoI am changing status basing on the previous comment.
Comment #14
camidoo commentedis the community not suppose to review these? how exactly is one suppose to gain cvs access?
"wait your turn?"
definetly needs to be changed to read the actual time it takes, about a month "or so".
How does one remove their application as well? Suppose i decide i don't want to release this and place it into drupal cvs?
Comment #15
ksenzeeThe community is more than welcome to review CVS applications - but we need code reviews in additional to functional reviews. It's great to know that a module works, but we also need to know there aren't glaring security holes or indications that the module author knows nothing about Drupal's APIs and coding standards.
I did a quick code review and I think it looks good - anyone who's implementing Batch API and integrating with apache_solr has obviously been around the Drupal block. I have two concerns:
1) There's an eval() call that should be converted to use drupal_eval() and require explicit permissions to execute PHP. The recent Views SA was in part due to exactly this.
2) It looks to me like there's more than an optional dependency on permissions_api that should perhaps be declared in the .info file, but I could be wrong - I'm not sure where all the functions that use permissions_api are being called from.
As soon as #1 is resolved this is RTBC.
Comment #16
camidoo commentedthanks ksenzee,
added a new perm 'import drealty configuration' and added that perm to the menu item in hook_menu() for the import function. Additionally i explicitly check the permission again on submit, just incase. And then replaced my @eval with drupal_eval().
as for the permissions_api, any calls to that api are preceeded by a module_exists() checking to see if content_permissions and permissions_api are both present and enabled. The intent is to have built in support for the modules, while not forcing users to use them if they prefer not to.
thanks for the review!
Comment #17
dave reidYes #1 is really the only thing holding this up since that's a pretty major issue. See also my short handbook guide about eval(): http://drupal.org/node/715010.
Comment #18
dave reidPlease make sure your permission name includes 'PHP'. Something like 'import drealty configuration using PHP'.
Comment #19
camidoo commentedchanged the permission name per dave's request. Completely makes sense
Comment #20
camidoo commentedoh switching the status back to needs review
Comment #21
camidoo commentedupdate
Comment #22
camidoo commentedany movement on this? made all the changes requested over a week ago...
Comment #23
Macronomicus commentedYes he indeed made all requested changes. :)
Comment #24
camidoo commentedany movement on this? again? i'm starting to think that i should start asking who i need to pay to get a cvs account...
Comment #25
dwwThis clearly needs to happen before we piss off camidoo to such an extent that he doesn't want to contribute to the Drupal project. ;) Although I normally don't approve CVS applications, I made an exception for this. Sorry for the delays, camidoo! Our whole process is broken here:
#703116: Our CVS account application requirements are obtuse and discourage contributions
Luckily, it's going to radically change in the next few months:
#781264: Decide on an appropriate git analogue to current CVS account workflow
Comment #26
dwwp.s. It's completely insane that we're asking potential contributors to do revisions of their code without the benefits of a revision control system and an issue tracker. Way to train them on the *wrong* way to do things as their first experience with Drupal "development". /me facepalms
Comment #27
camidoo commentedthank you dww!
Comment #28
camidoo commentedComment #29
dww@camidoo: Not that it really matters, but the general idea is you mark things "fixed" when you fix them, and then if they stay fixed without being replied to again, they're automatically moved to "closed" in 2 weeks. This way, recently-fixed things still remain visible to people looking at an issue queue. In here, it doesn't matter so much, since these aren't bugs someone else might be hitting or something, but it's a good habit to get into of just marking things "fixed" and leaving them alone. ;)
Comment #30
osu_bucks commentedHi,
I don't know if I've done anything wrong. But when I enabled drealty-6.x-1.0-beta-11, my website went blank. And this is the error message I got from php error log. I have to delete the drealty folder to get my site back up. What's the best way to uninstall it so I can try again?
[17-May-2010 03:52:00] PHP Fatal error: Cannot redeclare drealty_import_connection_form_submit() (previously declared in /home/public_html/beta.xxxxxx.com/public/sites/all/modules/drealty/drealty.admin.inc:1536) in /home/public_html/beta.xxxxxx.com/public/sites/all/modules/drealty/drealty.admin.inc on line 1583
Thanks,
Comment #31
avpadernoComment #34
avpaderno