I am requesting a CVS account in order to start a new project centered around using the SolrJS library to provide AJAX search capabilities to the Apachesolr Search module.
This new module will load all facets in place of the apachesolr module and allow for direct communication with the Solr server, which takes load off of the drupal site and allows for content distribution over multiple servers. As another options, the javascript can still route it's queries through Drupal as a menu callback. This enables higher security while still reducing the server load. I will also create a secondary file that would minimally bootstrap drupal in order to look up info in the db and still provide the security options.
Another positive is that queries can be routed to a secondary server, meaning that you could have one solr instance running through the apachesolr module for indexing, but have a replication server for the javascript to connect to.
The SolrJS library itself seems to no longer be in active development by the original developer, but hopefully I will be able to reach him eventually. I have made extensive modifications to the library and will be including that in the module as well.
The original code supports a javascript class extension method that allows for the creation of new classes that extend others. Using this functionality, the Drupal specific functions have been separated into their own files. A benefit of this design is that it means that any other module developer could override functions to create their own widget js files and create instances of these widgets in the page. So for instance, if you wanted to add a link after every search result, you could create a custom widget that extends the result widget, and implement the rendering function, allowing you to theme the output of the results.
I also JUST discovered that Drupal has support for basic theming via the 'Drupal.theme' javascript function, which I may end up using.
More info on SolrJS can be found here. http://wiki.apache.org/solr/SolrJS
More info on ApacheSolr can be found here. http://drupal.org/project/apachesolr
The module has been under development for several weeks now, and a demo can be found here on our dev server. http://solrjsdemo.ewdev.ca/search/apachesolr_search/luptatum
My last application was denied because of a single place where the #required was being set in a way that was unsatisfactory. I was conditionally setting it because the fields are only required under certain circumstances. I've asked on IRC and people told me that using $form_state['post'] in the form generation function isn't a good idea. I have looked at the FAPI documentation a lot, but there isn't much on the required flag. Now, I was settings it based on either the form_state or the variable_set values. It worked fine and I don't know how else I could possibly set a boolean variable.
Anyway, at this point I have removed the required flags entirely and taken a better route around the general problem anyway, so there is no need to require the fields anyway.
Thanks much,
Logan Smyth
Evolving Web
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | solrjs.tgz | 13.25 KB | loganfsmyth |
Comments
Comment #1
loganfsmyth commentedHere's the most up to date code!
Comment #2
avpadernoThe previous application was #552908: loganfsmyth [loganfsmyth].
There is a simple way to flag a form field as required, and it doesn't need to write any additional code, nor to check
$form_state['post'].[Edited - removed a wrong conclusion]
Comment #3
loganfsmyth commentedHey, I'm not trying to be rude, but did you actually read my posts? I know you can set #required without requiring any additional code. The reason I added more code was because it isn't always required, so I needed to set #required only under certain circumstances. Those circumstance depend on the $form_state array, or in the case that it is empty(first viewing) they depend on the solrjs variables.
Anyway, I'd be happy to talk to you more via irc if you would like. I'm be on freenode most of the time from 10-6 EST.
Logan
Comment #4
loganfsmyth commentedYou are suggesting that I do this:
but that doesn't accomplish my goals, because I only want it to be required sometimes.
I did this, but you said it was wrong. I just don't see how, since I am using the #required field as you suggested. I also was sure to check form_state properly.
What is it that this snippet is missing?
Comment #5
avpadernoI apologize for having misunderstood what you were trying to accomplish.
The author of the JavaScript code is not replying to the email I sent him, and the original code doesn't report the license under which the code has been released; I also checked the web site from where it is possible to download it, and there is no reference to the code license. As the code doesn't even report a copyright note, I would guess the code is released under the public domain.
Comment #6
loganfsmyth commentedNo problem, don't worry about it :P You have a LOT of applications to look at. I'm impressed that you manage to look through so many. Plus, the logic in post comment 4 was a bit more straightforward than my in comment #12 of the last thread.
I heard back from the author yesterday, so hopefully I'll be able to work with him a bit. He was away on vacation and has now said that he'd get back to me in a day few days once he has worked through all his email. You are right about the licensing stuff. I made the same assumption. I couldn't find licensing info anywhere, so it's most likely public.
You know better than I do. If I created a project page now for a "SolrJS" project, but then had to change the name, would that be really complicated? I can hold off on creating the project page until I talk to the first author a bit more if renaming would be an issue.
Thanks.
Comment #7
loganfsmyth commentedI thought about it a bit more and it seems likely that the original Solrjs code is probably under the Apache license, which should not be an issue. According to this page, http://www.apache.org/licenses/GPL-compatibility.html, Apache license code can be included in GPL projects.
Comment #8
avpadernoAccording to Why drupal.org doesn't host GPL-"compatible" code (which reports the words of Dries Buytaert):
The Apache License v2.0 is reported to be compatible with GPL License v3, while Drupal uses GPL License v2; I am not sure if Apache License v2 is compatible with GPL Licence v2.
I think that is better, also for what reported about compatible licenses, to not host the code derived from code under Apache License into the repository. You should put a link in the project page to allow users to download the file you created from Apache License code.
Comment #9
avpadernoComment #10
avpadernoIt is always possible to rename a project page. it's not possible to rename the CVS directory containing the project files, anyway; it is better to choose for the project a name, and a short name that you don't have to change.
Comment #11
avpadernoThe author of SolJS reported that his code is licensed under Apache License; any derivative code is still under that license, and it cannot be hosted on CVS.
I am setting this report as fixed because the CVS application has been approved. Where to host a file is a detail that doesn't influence the decision taken to grant a CVS account.
Comment #14
avpaderno