SQL Exception when creating a new Object and checking if a collection is present

Hi list,

I've encountered the following problem/feature:

I create a new Thing

{{{
var nthing = new Thing();
}}}

then I do

{{{
nthing.renderSkin("edit");
}}}

in the edit skin I have a macro that checks if a certain collection exists.

{{{
if (this[nameofcollection]) ...
}}}

The I get this helma/SQL Error:

{{{
[ERROR] Error retrieving Node for Thing[[object Object]]
com.mysql.jdbc.exceptions.MySQLSyntaxErrorException: You have an error
in your SQL syntax; check the manual that corresponds to your MySQL
server version for the right syntax to use near '[object Object]' at line 1
}}}

Re: SQL Exception when creating a new Object and checking if a collection is present

Franz Philipp Moser schrieb:
> I found out that when helma creates new Objects, it sets the _id to
> something like t + number (t1, t2, ...)
>
> Because of that the SQL goes wrong.
>
> Now I have to check if the Object was newly created:
> {{{
>    var newRecord = isNaN(parseInt(this._id, 10));
> }}}
>
> Is this standard behavior or a feature? Shouldn't this be changed?
>   
This is afaik standard behavior. We wrote a little global helper method, 
which might also be helpful for you.

function isObjectPersistent(obj) {
   if (!obj || obj._id.substring(0,1) == "t")
      return false;
   else
      return true;
}

greets,
  michi

Announcement: Jala 1.0

Hi everybody,

ORF.at is glad to announce the first version of Jala, another fine,
Helma-related open source project.

Jala is a library and utility project initially developed to ease the
work in the software development department of ORF.at. Jala is what was
previously referred to as (the mysterious) "onLib" on this list.

This initial release version 1.0 of Jala primarily consists of a set of
libraries which we've been using for quite some time now in nearly every
application we've developed so far. Therefor, you can expect the code to
work in a pretty reliable, safe and performant way.

Some highlights of Jala include:

    * jala.I18n, a GNU gettext compatible internationalization library
which makes translating Helma applications a breeze. Even localization
of date and number formats and the ability to inject dynamic content
into localized messages are done with a snap. Due to the full
compatibility with gettext's portable object (po) format you can use any
po-capable editor for your translation tasks. 

    * jala.AsyncRequest allows spawning of asynchronous requests,
providing a neat way to process time-consuming tasks which otherwise
would pose the risk of a request timeout. 

    * jala.ListRenderer, a very flexible library for rendering
collections of HopObjects as lists, including different kinds of
navigation. 

Re: Announcement: Jala 1.0

Wow!

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.

A very quick feedback, mixed with some first question:

 *  jala.AsyncRequest: The need for exactly such a functionality came up 
couple of weeks ago. And we solved this issue quite similar to your 
implementation, by making internal helma-calls in separate threads. We 
might consider switching to this class.

 * 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'?

  * 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?

 * java.ImageFilter: Image-Manipulation is a task that we 'outsourced' 
to ImageMagick, as this is the most powerful tool available for such 
tasks. Similar to ImageMagick we also use external libraries for 
transcoding Videos and Audios.

Re: Announcement: Jala 1.0

Hi Robert,

 

yes thanks very much for publishing this library! I recently implemented a podcast app here and can see alot of the simliar functionality in your lib (I wish I had known about it a few months ago! and that in the future I will switch to instead of my maintaining my own custom written code.

With the mp3 ID3 tags - I wrote an implementation that can also *write out* to ID3 tags, but using a different java library then you do. Would there be any interest for me to clean up my code and contribute it to Jala?

 

Also I have been working on some our small custom pieces of code that might be useful to others but not sure what the best way to put them out -  is there interest in having mode modules added to Jala or should it go into helmaLib or should I just start my own lib project?

 

thanks again for such a great contribution,

 

Maks.

From: helma-user-bounces <at> helma.org [mailto:helma-user-bounces <at> helma.org] On Behalf Of robert.gaggl <at> orf.at
Sent: Tuesday, 6 February 2007 02:19
To: helma-dev <at> helma.org
Cc: helma-user <at> helma.org
Subject: [Helma-user] Announcement: Jala 1.0

Hi everybody,

ORF.at is glad to announce the first version of Jala, another fine,
Helma-related open source project.

Jala is a library and utility project initially developed to ease the
work in the software development department of ORF.at. Jala is what was
previously referred to as (the mysterious) "onLib" on this list.

This initial release version 1.0 of Jala primarily consists of a set of
libraries which we've been using for quite some time now in nearly every
application we've developed so far. Therefor, you can expect the code to
work in a pretty reliable, safe and performant way.

Some highlights of Jala include:

    * jala.I18n, a GNU gettext compatible internationalization library
which makes translating Helma applications a breeze. Even localization
of date and number formats and the ability to inject dynamic content
into localized messages are done with a snap. Due to the full
compatibility with gettext's portable object (po) format you can use any
po-capable editor for your translation tasks.

    * jala.AsyncRequest allows spawning of asynchronous requests,
providing a neat way to process time-consuming tasks which otherwise
would pose the risk of a request timeout.

    * jala.ListRenderer, a very flexible library for rendering
collections of HopObjects as lists, including different kinds of
navigation.

In addition, Jala currently contains an Ant-based set of utilities
called HopKit which automates tasks related to I18n and API
documentation. Moreover, Jala provides a client application useful for
debugging XmlRpc services and requests.

Of course, there's even more on the way, eg. a module for handling forms
and submitted data as well as a unit testing environment for Helma
applications. Stay tuned for further releases!

To obtain information about getting and using Jala please point your
browser to the Jala project site at
https://opensvn.csie.org/traccgi/jala/.

We hope you find Jala as classy and useful as we do. And please take
this announcement as a kind invitation to participate in Jala's further
development.

robert
_______________________________________________
Helma-user mailing list
Helma-user <at> helma.org
http://helma.org/mailman/listinfo/helma-user

_______________________________________________
Helma-user mailing list
Helma-user <at> helma.org
http://helma.org/mailman/listinfo/helma-user

Re: Announcement: Jala 1.0

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

Re: Announcement: Jala 1.0

hi maksim,

> With the mp3 ID3 tags - I wrote an implementation that can also *write 
> out* to ID3 tags, but using a different java library then you do. Would 
> there be any interest for me to clean up my code and contribute it to Jala?
>  
> Also I have been working on some our small custom pieces of code that 
> might be useful to others but not sure what the best way to put them out 
> -  is there interest in having mode modules added to Jala or should it 
> go into helmaLib or should I just start my own lib project? 

reg. contributions: jala is an open-source project, so of course
contributions are warmly welcome. we're currently working on detailed 
information about how to contribute to the further jala development. you 
should find it by tomorrow in the project wiki at 
https://opensvn.csie.org/traccgi/jala/wiki

robert

working with mail server and auto email processing

_______________________________________________
Helma-user mailing list
Helma-user <at> helma.org
http://helma.org/mailman/listinfo/helma-user

Re: working with mail server and auto email processing

hi julian

nice coïncidence: i just thought about a simple helma mail server in the last days, mainly for testing purposes.

the setup you describe in fact is hard to configure, uneasy to maintain and difficult to distribute to other
helma installations.

i also searched for some libraries but only with small effort so far. some resources i found include

https://aspirin.dev.java.net/
http://www.ericdaugherty.com/java/mailserver

http://www.emailman.com/java/index.html
http://www.roseindia.net/opensource/emailservers.php

james crossed my way, too, but i did not look further into it. ("enterprise" turns me off so easily.)

i still wonder wether javax.mail itself can provide the desired functionalities...

a light-weight smtp server which can receive and parse e-mails (imho, there's no real need for relaying or
organising them) would be a valuable addendum to helma's server capabilities.

however, i have yet no idea how it could be implemented.

ciao,
tobi

-----Original Message-----
From: helma-user-bounces <at> helma.org on behalf of Julian Tree
Sent: Sat 17-Feb-07 01:35
To: Helma User Mailing List
Subject: [Helma-user] working with mail server and auto email processing

Does anyone have had experience working with auto email processing in  
Helma?  I want to run a certain process/function when a user send an  
email to a particular email address.

Currently I have this setup with the combination of Postfix,  
Procmail, and PHP script. When an email arrives Postfix hand it to  
Procmail with then pass the message to a PHP script.    It is not  
pretty, and it is error prone.   I am really looking for a more  
integrate solution in Helma.  I have looked at JAMES (Java Apache  
Mail Enterprise Server http://james.apache.org), and wonder if anyone  
have done similar project before who can point me in the right  
direction.

Julian Tree

_______________________________________________
Helma-user mailing list
Helma-user <at> helma.org
http://helma.org/mailman/listinfo/helma-user

Re: working with mail server and auto email processing

hi,

tobias.schaefer <at> orf.at wrote:
> hi julian
> 
> nice coïncidence: i just thought about a simple helma mail server in the last days, mainly for testing purposes.

just stumbled over dumpster (http://quintanasoft.com/dumbster/). there's 
a javaworld article about it too: 
http://www.javaworld.com/javaworld/jw-08-2003/jw-0829-smtp.html. i just 
had a brief look at it, but it appears to be near to what you're looking 
for.

> i still wonder wether javax.mail itself can provide the desired functionalities...

afaik not: "The JavaMail APIs were not intended to help you implement a 
mail server. Nonetheless, some of the utility classes, such as the MIME 
message parsing classes, might be of use to you." 
(http://java.sun.com/products/javamail/FAQ.html#javamailserver)

robert