Sunday, April 25, 2010

FTP/SFTP support in eclipse with Remote System Explorer

I got tired of using an FTP/SFTP client and switching from it to my IDE. So I went on looking for some FTP and SFTP plugins for Eclipse.

I've seen the Aptana Studio or plugin for Eclipse being recommended and tried to use it. Works ok but they only support SFTP in the professional version. Because of that I tried Remote System Explorer. I was quite happy to discover that not only it supports FTP and SFTP but you actually can also open a ssh terminal or issue ssh commands from Eclipse directly.

Install the Remote System Explorer plugin

First you need to install the plugin. With version 3.5.2, you can follow these steps:
  1. Go to Help -> Install new software
  2. From the "work with" drop-down list select: "Galileo - http://download.eclipse.org/releases/galileo"
  3. In the pane below, expand General Purpose Tools and select the Remote System Explorer end user runtime. 
  4. Click Next and follow the instructions.

Create a SFTP connection

Once installed you can start creating connections. Just do as follows:
  1. switch to Remote System Explorer perspective.
  2. Right-click on the Remote Systems view on the left and choose new -> connection.
  3. Choose FTP only if that's what you need or SSH only if you want SFTP support as I do.
  4. Specify the Host Name and the Connection Name.
  5. Finally keep clicking on next until finished.
Tadam! You should have your remote system on the left pane. From there you can start browsing your files or opening an ssh terminal to the remote system. Of course you don't need to be in the RSE perspective. You can switch to any perspective you like and and open the necessary views through Window -> Show View, etc.

Happy Coding!

Sunday, April 18, 2010

Django whois using the subprocess module

Last month I wrote a post about writing a whois client. This time I want to investigate If it's possible to leverage your operating system for those kind of tasks or if you really need to reinvent the wheel.

So why did I wrote my own crappy whois client in the first place? As you may already have noticed from my blog it's because I want to use the whois client from within Django (web application framework) hence the need to have a python module that can do whois queries.

Ok so the need is pretty clear but there should be a way to call the whois client of my operating system from a python module instead. This would allow me to write less code and I'll probably end up with a more robust whois client. So what possibilities does Python offer to spawn a process and communicate with it?

Since version 2.4 there is the subprocess module. In essence this is exactly what I need. So let's see how we can use it from within Django to provide a web interface to the whois native client.

from django.shortcuts import render_to_response
from django.http import HttpResponse
from django import forms
import subprocess

def whois(domain):
    p = subprocess.Popen(['whois', domain], stdout=subprocess.PIPE)
    answer = p.commmunicate()
    return answer

class WhoisForm(forms.Form):
    domainname = forms.CharField(max_length=100)

if 'whois' in request.POST:
    whois_form = WhoisForm(request.POST, prefix='whois')
    if whois_form.is_valid():
        domainname = whois_form.cleaned_data['domainname']
        answer = whois(domainname)
else:
    whois_form = WhoisForm( prefix='whois')

return render_to_response('index.html', {'whois_form': whois_form,
                                         'answer': answer,})

What happens in the code above is that we spawn the whois subprocess and pipe its output. This enables us to communicate with it and retrieve it's standard output in a variable. We can then pass along the output to the template for the user to view in his browser. Quick and easy!

Ok, so at this point I should be a happy man! I did reach my initial goal of not reinventing the wheel. However  I'm really not sure this is the way to go. Next time we will use the timeit module to see how this one compares to the python whois client regarding performance.

Sunday, April 11, 2010

Javascript debugging

This week-end I had a hard time debugging some javascript code and could hardly find any time for posting. While we wait for the next post I wanted to share a good article I found about javascript debugging:

    http://www.alistapart.com/articles/advanced-debugging-with-javascript/

Debugging javascript can be a real pain. Please feel free to share your tips, techniques and tools in the comments section.

Wednesday, April 7, 2010

Multicolor jQuery Accordion widget

I received a question about having different elements in a jQuery accordion with different colors. There are probably many ways to achieve this. Below I'll show you how to do it with just a little bit of javascript.

$(document).ready(function(){
    $("#accordion").accordion();
    var my_colors = ["aqua", "black", "blue", "fuchsia", "green", "lime"];
    $('.ui-accordion-header').each( function(i) {
        $(this).css("background-color",my_colors[i])
    });
});

What is important to note here is the use of the css classes added by jQuery to an accordion to retrieve all accordion headers. I hope I answered the question... If I can find the time I'll try to put a polished demo on the web with complete source code.

Monday, April 5, 2010

A collection of jQuery Modal Dialog Boxes plugins

Today I was searching for a good Modal dialog Boxes plugin for jQuery in an attempt to improve the overall look and feel of my current project. After some time I ended up on 19 jQuery Modal Boxes to improve your UI.

Since I know how frustrating this kind of search can become. I thought I'd better share this collection with you.

Friday, April 2, 2010

Multiple Django forms in the same view

When you want to handle multiple Django forms within the same view you need some extra coding as opposed to having a single form. This is needed because:

  • You want to identify which form has been submitted to your view.
  • And you don't want to confuse fields from one form with fields from another.
So let's start with identifying the form from your view. You'll first need to add some information to your template to distinguish between the two forms. This can be easily done by giving a unique name to each submit buttons. For the rest of this post we will assume that we have two forms: A and B.

<fieldset>
    <legend>Form A</legend>
    <form method="post">
        {{ A_form.as_p }}
        <input name="A" type="submit" value="Submit" />
    </form>
</fieldset>

<fieldset>
    <legend>Form B</legend>
    <form method="post">
        {{ B_form.as_p }}
        <input name="B" type="submit" value="Submit" />
    </form>
</fieldset>

Now that you uniquely identified both forms you can add some logic to your view to get to know which submit button as been pressed.


if 'A' in request.POST:
    # A form processing
elif 'B' in request.POST:
    # B_form processing

What happens above is that you search the submitted POST data dictionary for the name you gave to your submit buttons. That's all there is to it.

However if for some reason fields in the different forms you present to your users have the same names then you need to add a couple more lines of code to distinguish between them. From the django documentation you can borrow the strategy in using more than one formset in a view. The idea is to prefix each field name with a form identifier. I choose to use the same token for the prefix and for the submit button name.

The end result would be something like this:

class AForm(forms.Form):
    fieldname = forms.CharField(max_length=25)

class BForm(forms.Form):
    fieldname = forms.CharField(max_length=25)

if 'A' in request.POST:
    A_form = AForm(request.POST, prefix='A')
    B_form = BForm(prefix='B')
    # A form processing
elif 'B' in request.POST:
    B_form = BForm(request.POST, prefix='B')
    A_form = AForm(prefix='A')
    # B_form processing