Entreprise Software | Hexónio Blog

jQuery Calendar Date Picker in Django Forms

One of Django missing features that all developers miss is the lack of a calendar component that allows a user to select a date from a visual component instead of writing the date in a text field using a predefined format.

The common solution that seems to use the calendar from the administrator graphical interface.
Unfortunately this is a hack that takes too much work for a possible failure, since a Django update may break it all.

While Django does not provide such component, the best option is to use a solid solution, such as using the independent jQuery Calendar Date Picker.
This can be set up in ten minutes and does not depend on Django version.

The first step is to download the jQuery Datepicker component.

Uncompress it and put it in your media directory, so that it looks something like “media/jquery”, or something else that is fits best with your structure. For the current example “media/jquery” will be used.

In your HTML file, include the following scripts:

Please note that the file names will vary according to the jQuery version and the CSS will vary according with the selected template. Don’t forget to confirm the location and file names.

Next, you must bind your form objects with the jQuery Datepicker with the following script. Also include this on your HTML file

Where “form_date_field” should be your form date field, keep the “#id_” because Django precedes the ids with “id_”

If you require internationalization, load the correspondent i18n file after the “jquery…min.js” file:

This will load the appropriate i18n file.

If you try it and it’s not working, check the files location and the name of the object you’re binding to, these are the two most common problems.

Solr for Latin Languages

When configuring Solr in non-english languages, in this case in Portuguese, one usually wants:

words split by white spaces;
word case insensitive match;
stop words removal;

In the case one may wish to stem words, it’s also easy. Though, one should be careful in using stem, since it may produce too much false positives.

To split words by white spaces, use StandardTokenizerFactory or WhitespaceTokenizerFactory.

For case insensitive, use LowerCaseFilterFactory.

For stop words removal, use StopFilterFactory.

In the case of stem, use SnowballPorterFilterFactory.

Here’s an snippet of a Portuguese schema.xml:

    <fieldType name="text_general" class="solr.TextField" positionIncrementGap="100">
      <analyzer type="index">
        <tokenizer class="solr.StandardTokenizerFactory"/>
        <filter class="solr.StopFilterFactory" ignoreCase="true" words="stopwords.txt" enablePositionIncrements="true" />
        <!-- in this example, we will only use synonyms at query time
        <filter class="solr.SynonymFilterFactory" synonyms="index_synonyms.txt" ignoreCase="true" expand="false"/>
        -->
        <filter class="solr.LowerCaseFilterFactory"/>
        <filter class="solr.SnowballPorterFilterFactory" language="Portuguese" />
        <filter class="solr.ASCIIFoldingFilterFactory"/>
      </analyzer>
      <analyzer type="query">
        <tokenizer class="solr.StandardTokenizerFactory"/>
        <filter class="solr.StopFilterFactory" ignoreCase="true" words="stopwords.txt" enablePositionIncrements="true" />
        <filter class="solr.SynonymFilterFactory" synonyms="synonyms.txt" ignoreCase="true" expand="true"/>
        <filter class="solr.LowerCaseFilterFactory"/>
        <filter class="solr.SnowballPorterFilterFactory" language="Portuguese" />
        <filter class="solr.ASCIIFoldingFilterFactory"/>
      </analyzer>
    </fieldType>

Eclipse Application Export Error

While performing an Eclipse Product export, via wizard, the following error came up:

 Cannot complete the install because of a conflicting dependency.
 Software being installed: iCANgraph 1.0.0 (Lumina 1.0.0)
 Only one of the following can be installed at once:
 Cannot satisfy dependency:

Yes, the dependecy that could not be satisfied was not stated, so there was no clue about what was causing this export error…
There was absolutely no more error information. No export log was found, thus this useless error message was all that I had…
It took some time until I realise that the “Generate metadata repository” option was enabled, causing all this problems.
This option enables the “Provisioning platform“, commonly known as P2, which builds P2 repositories and products. It creates a plugins folders (repository\plugins) that contain the same plugins as the folders in the exported application.
My guess, since I was unnable to get suficient information to know for sure, is that the automatic resolution of dependencies between software components, one of P2 features, was not doing things properly, thus the error.

Since all that was needed was a product, the P2 information was unecessary and, obvisouly, redundant and a real trouble maker.
To solve this problem, all that was required was to disable the “Generate metadata repository” option and export the product again.

Interpreting DB2 JDBC error messages

On data migration projects using BD2, sometime there are some awkward DB2/JDBC errors.
It does not matter if it is DB2 on Windows, Unix or iSeries AS/400.

Part of the problem is that the error messages come in localized, on our case in Portuguese, making the debug task a lot harder since it’s almost impossible to find decent help by searching through the error messages. The other part of the problem is that the SQL error codes sometimes are unclear.
Here’s an example of a common problem that we have in data migration projects:

com.ibm.db2.jcc.b.rg: [jcc][t4][102][10040][3.50.152] Non-atomic batch failure. The batch was submitted, but at least one exception occurred
on an individual member of the batch.
Use getNextException() to retrieve the exceptions for specific batched elements.

com.ibm.db2.jcc.b.pm: Error for batch element #1: The current
transaction was rolled back because of error "-289".. SQLCODE=-1476,
SQLSTATE=40506, DRIVER=3.50.152

com.ibm.db2.jcc.b.SqlException: [jcc][103][10843][3.50.152]
[...] ERRORCODE=-4225, SQLSTATE=null

Following DB2 official documentation:

SQLCODE=-1476 means that the current transaction was rolled back because of one of the listed errors, but none of them made much sense since none of the errors identified seem to apply.
SQLSTATE=40506 means that the current transaction was rolled back because of an SQL error, which is basically the same as the SQLCODE above.
ERRORCODE=-4225 means an error occurred when data was sent to a server or received from a server, which is totally useless.

The real useful information is hidden in the second error message, in the ‘transaction was rolled back because of error “-289”‘ message. The key here is the -289 error.
This error means “Unable to allocate new pages in table space“, and this is the real cause for such a big fuss.

In data migration projects it’s common some of the DB2 table spaces to run out of space. But with such an error message, the error itself is kind of hidden in the middle of the stack trace, all that is shown is a loose error code…
For the sake of the developers productivity, the cause of the error should be highlighted and perfectly visible and understood in order to be quickly identified and fixed.

Intenationalize RCP applications

To internationalize (i18n) and Rich Client Platform (RCP) application, also known as Eclipse Application, it’s not enough to download the language package. One also needs to download the language packs for the RCP core.

Here’s what it takes to i18n the core of an RCP application:

Download the language packages from the Babel project using the Eclipse install/update mechanism.
Open the RCP application “.product” file.
Go to the “Configuration” section.
Press “Add Required Plug-ins” button.

This last step is the “magical step”, it includes the i18n plugins to the RCP application.
You can identify the language plugins by their name. They come in the “<plugin>.nl_<language>” format. For instance, Portuguese JFace translation file is “org.eclipse.jface.nl_pt”.

JPA Persistence/Transactions

When involving several calls to your DAO methods in a single transactions, here’s a great place to start: Java Persistence/Transactions

Here’s a small stub for kick-off:

UserTransaction tr = null;
try {
tr = (UserTransaction) new InitialContext().lookup("javax.transaction.UserTransaction");
tr.begin();

bean.op1();
bean.op2();
// ...
bean.opN();

tr.commit();
} catch (Exception e) {
logErrorMessage(e); // log error message

if (tr != null) {
try {
tr.rollback();
} catch (Exception e1) {
logErrorMessage(e); // log error message
}
}
}