[Helma-user] Announcement: Jala 1.0

[Robert Gaggl]

hi michi,

Michael Platzer wrote:
> Jala seems to be (yet another) impressive work/contribution from your, 
> resp the orf-side. The provided functionality makes a tidy, uncluttered 
> impression. Congratulations for getting this out! But above all, the 
> excellent documentation of the library is really a great benchmark for 
> all of us.

thanks. we've put quite some efforts not only into developing the 
library itself but also writing the documentation, since for us 
documentation is a key issue in a library project.

>  * jala.History: What is the purpose of this class? I assume that this 
> should help, to send the user automagically back to the correct page 
> after performing some multi-step-workflow, correct? How do you know 
> which one was the last 'non-workflow-page'?

that's something the application should "know". using History it's easy 
to eg. redirect a user back to page 23 of a list after editing an item, 
but it's up to the application to "know" that it should redirect n steps 
back. History is currently just a helpful "browser-like history stack" 
with the ability to initialize temporary additiona stacks (eg. for 
editing sessions that take part both in a main window and a popup).

>   * jala.I18n: Very interesting to see a different i18n-implementation 
> in helma. Making heavy use of the java MessageFormat-class and using the 
> wide-spread PO files is a smart move. So, the english text is used as an 
> identifier for a message. What happens if one decides to slightly change 
> that english message? Do I automatically lose the other translations?

if you change the message key without updating the translation catalogs 
I18n won't find the translations anymore, as there is currently no 
"fuzzy" lookup in I18n (but it might be a good thing to add in the 
future). however, one nice aspect of working with .po files is that many 
po-editor applications notify that a message key has been removed and a 
new one added, so it's easy to keep message catalogs in sync with the 
application.

>  * jala.Mp3Info: The link [http://www.ueberdosis.de/java/id3.html] to 
> the ID3Reader-package seems to be broken here 
> [https://opensvn.csie.org/traccgi/jala/wiki/JalaModules]. We use the 
> MP3SPI-library [http://www.javazoom.net/mp3spi/mp3spi.html] directly for 
> similar purposes.

obviously ueberdosis.de went offline, thanks for the pointer.

>  * jala.RemoteContent: This class mimics a 'forward proxy cache', 
> correct? We also implemented a similar, but less generic functionality 
> for fetching feeds. If such a functionality is used heavily, one might 
> consider implementing a limitation for the size of the cache directoy. 

RemoteContent not only allows to cache on disk, but also in a HopObject 
to create a "in-memory cache" (eg. in app.data). plus, you can pass a 
cleanup-function to the exec() method for eg. removing cache files that 
exceed a certain age.

> One minor tipp regarding the documentation: If you commit the 
> documentation, that is currently contained in the wiki-pages [e.g. 
> https://opensvn.csie.org/traccgi/jala/wiki/JalaModules], into the 
> repository itself, then you will get automated versioning/branching also 
> for the documentation. And Trac allows one to automatically render files 
> with a specific suffix (e.g. '.wiki') in the SVN Browser as regular wiki 
> pages.

thanks for the pointer, we might start with versioned docs in future 
releases of jala.

> As I said, the first look of Jala is very promising. Some of the 
> provided functionality is definitely highly interesting for us. In what 
> form do you want to receive feedback in the future? Should we use this 
> mailing-list, a separate mailing-list or Trac's ticketing system?

reg. bugs and enhancement proposals please file new tickets. we didn't 
set up an own mailing list until now, but it might be a necessary task 
for the future (as this here is the helma mailing list, i'd prefer to 
not misuse it for Jala related discussions).

robert