headers
Jonathan Puckey | 1 Nov 14:36

convert image to grayscale

I needed a function that would convert an image to grayscale, after  
trying 6 different functions this one seems to be the fastest:

function convertToGrayscale(img){
	var img = img.getBufferedImage();
	var w=img.getWidth();
	var h=img.getHeight();
	var type = java.awt.image.BufferedImage.TYPE_BYTE_GRAY;
	var grayImage = new java.awt.image.BufferedImage(w, h, type);
	var g = grayImage.createGraphics();
	g.drawRenderedImage(img, null);
	g.dispose();
	return new Image(grayImage);
}

So I thought I would share..

grts-
Jonathan
Permalink | Reply | 0 comments |
headers
Michael Platzer | 2 Nov 09:37
Picon

Re: _extends & _prototype

Jonathan Puckey schrieb:
> Ack.. This isn't working in the way I wanted it to after all..
> When I restart my app and point to /Exhibitions/archive/2005/this-is- 
> the-title/, it uses the Page prototype and not the ArchivePage  
> prototype..
> And then sometimes it does use the right one.. Flakey at best!
>
> So I need a different approach, I guess..
>   
yes, using the inheritance-mechanism doesnt help you at all in your 
situation, since you are dealing with the same object. no matter how you 
access it via your URL.
> What would be the best way to have the main.hac that is fired be  
> dependent on the collection that it resides in?
>   
lets assume 'archive' is a Prototype named 'ArchiveMgr'. Then you could 
do the following:
function main_action() {
  if (path.ArchiveMgr) {
    ...  // we accessed the Page via the archive
  } else {
    ... // we accessed the Page directly
  }
}

hth,
  michi
Permalink | Reply | 1 comment |
headers
Jonathan Puckey | 2 Nov 19:51

Re: _extends & _prototype

Hi Michi,
Great, I get it now. I had seen the Mgr prototype idea mentioned  
before, but I never understood the idea behind it. Very handy.
Thanks alot!

I do have a little follow-up question:
How do I now go about making the href() function create the right url  
for the pages depending on which collection they are in?

i.e. when I'm in the archive, I want to link to pages as /category- 
title/archive/2006/page-title/
and when I'm in a category I want to link to pages as '/category- 
title/page-title/

I've tried:
_parent = cat, cat.archive

But it always uses the first one as the href (when I put  
'cat.archive' as the first, it just always renders te hrefs to that)

I've considered just hacking this by creating the hrefs myself with  
string concatenation, but I would really like to try to keep doing  
this the Helma way..

grts-
Jonathan

type.properties files for reference:

Category type.properties:
_db = myDataSource
_table = CATEGORY
_id = ID
_parent = root

_children = collection(Page)
_children.local = ID
_children.foreign = PAGE_CAT
_children.accessname = URLTITLE

archive = collection(Page)
archive.group = YEAR
archive.local = ID
archive.foreign = PAGE_CAT
archive.accessname = URLTITLE
archive.group.prototype= ArchiveMgr
archive.group.order = YEAR desc

Page type.properties:
_db = myDataSource
_table = PAGE
_id = ID

_parent = cat, cat.archive

cat=object(Category)
cat.local=PAGE_CAT
cat.foreign=ID


*



> Jonathan Puckey schrieb:
>> Ack.. This isn't working in the way I wanted it to after all..
>> When I restart my app and point to /Exhibitions/archive/2005/this-is-
>> the-title/, it uses the Page prototype and not the ArchivePage
>> prototype..
>> And then sometimes it does use the right one.. Flakey at best!
>>
>> So I need a different approach, I guess..
>>
> yes, using the inheritance-mechanism doesnt help you at all in your
> situation, since you are dealing with the same object. no matter  
> how you
> access it via your URL.
>> What would be the best way to have the main.hac that is fired be
>> dependent on the collection that it resides in?
>>
> lets assume 'archive' is a Prototype named 'ArchiveMgr'. Then you  
> could
> do the following:
> function main_action() {
>   if (path.ArchiveMgr) {
>     ...  // we accessed the Page via the archive
>   } else {
>     ... // we accessed the Page directly
>   }
> }
>
> hth,
>   michi
>
> _______________________________________________
> Helma-user mailing list
> Helma-user <at> helma.org
> http://helma.org/mailman/listinfo/helma-user
>
> !DSPAM:4549ae74112961887183730!
>
Permalink | Reply | 0 comments |
headers
Juerg Lehni | 8 Nov 02:30
Favicon

Javascript Template Engine, Sub Templates

I added the possibility of sub templates to my template engine today,  
as a proof of concept:

http://dev.helma.org/Wiki/JavaScript+Template+Engine/

The syntax and naming is not fixed, but so far it works well for me,  
so I thought I should share it.

This also had the side-effect that templates can now be created from  
strings like this:

new Template(str);

I think it should be very easy to create a JS only version from the  
current code that could run on the client side.

One discussion that is still open is the problem with closing tags  
for nested content (</%>). In my email from 27.10.06 that remained  
unreplied so far I wrote about this, among many other open template  
questions:

http://grazia.helma.at/pipermail/helma-dev/2006-October/003166.html

- Nested content: So far it has been said they should use <% end %>
instead of </%> as the end tag, for more consistency. I just realized
today why this is not as easy as we hoped, and why I have come up
with the current scheme. Look for example at this situation:

<% foreach (value in list) %>
	<% value.macro %>
	Some HTML
<% end %>

It would be good to hear reactions about this problem, and also about  
the other questions in my post.

Bellow some examples of sub templates. Comments are welcome.

Jürg

---

Definition:

   <% template "name">
   This is a sub-template. It can call <% macros %> and write <%=  
param.value %> too!
   </%>

Rendering:

   <% render "name" value="variables" %>

Rendering of normal templates:

   <% this.render "name" foo="bar" %>

Definition and rendering into a variable in one command:

   <% set "text">
   Render this text into 'name'. <% macros %> can be called.
   </%>

This can now be used like a normal variable, and for example be  
passed as
the default value in another macro:

   <%= text %>

   <% do_something default=text %>
Permalink | Reply | 2 comments |
headers
paul | 9 Nov 23:26
Favicon

"mounting" helma app behind apache

Hi all,

I hope this is not an RTFM....
What I'd like to do is to "mount" multiple helma applications somewhere
in the PATH of my domain:

<VirtualHost foo.test.home:80>
  ServerName foo.test.home
  ...

  <Location />
     ProxyPass http://localhost:8080/ #thats jetty's http listener
  </Location>

this *seems* to work OK though I'm not entirely sure 'cause I was unable
to access the "manage" app. However:

  <Location /helma>
     ProxyPass http://localhost:8080/
  </Location>

lets me access helma from http://foo.test.home/helma but css breaks and
links don't work... I tried to set in apps.properties:

manage.mountpoint = /helma/manage
...
welcome.mountpoint = /helma

which results in:
HTTP ERROR: 404 %2F%2F+Not+Found
RequestURI=//
Powered by Jetty://

Question is basically how to make this work. I'm not bound to mod_proxy
in any way so any method is fine. I just feel I'm still missing the big
picture how this is supposed to work. Any advice, pointers to
docs/howtos are much appreciated.

thanks
 Paul
Permalink | Reply | 3 comments |
headers
VividVisions, Walter Krivanek | 9 Nov 23:36
Picon

Re: "mounting" helma app behind apache

Hi,

I think you'll have to set "baseUri" in app.properties.
http://helma.org/docs/guide/properties/listall#baseURI

Another Apache HowTo:
http://helma.org/docs/howtos/mod_jk/

Best,
Walter

Am 9. Nov 2006 um 23:26 schrieb paul:


*



> Hi all,
>
> I hope this is not an RTFM....
> What I'd like to do is to "mount" multiple helma applications  
> somewhere
> in the PATH of my domain:
>
> <VirtualHost foo.test.home:80>
>   ServerName foo.test.home
>   ...
>
>   <Location />
>      ProxyPass http://localhost:8080/ #thats jetty's http listener
>   </Location>
>
> this *seems* to work OK though I'm not entirely sure 'cause I was  
> unable
> to access the "manage" app. However:
>
>   <Location /helma>
>      ProxyPass http://localhost:8080/
>   </Location>
>
> lets me access helma from http://foo.test.home/helma but css breaks  
> and
> links don't work... I tried to set in apps.properties:
>
> manage.mountpoint = /helma/manage
> ...
> welcome.mountpoint = /helma
>
> which results in:
> HTTP ERROR: 404 %2F%2F+Not+Found
> RequestURI=//
> Powered by Jetty://
>
>
> Question is basically how to make this work. I'm not bound to  
> mod_proxy
> in any way so any method is fine. I just feel I'm still missing the  
> big
> picture how this is supposed to work. Any advice, pointers to
> docs/howtos are much appreciated.
>
> thanks
>  Paul
>
> _______________________________________________
> Helma-user mailing list
> Helma-user <at> helma.org
> http://helma.org/mailman/listinfo/helma-user
>
Permalink | Reply | 2 comments |
headers
Maksim Lin for technical support mailling lists | 9 Nov 23:46
Picon

Re: "mounting" helma app behind apache

Hi Paul,

A pretty much only use the mod_jk connector to put helma behind apache
and it seems to work very well.
Its probably a bit more complicated then the method your using but
theres a very good howto on this at:

http://helma.org/docs/howtos/mod_jk/

If you are using linux, you might find that your distro already has
mod_jk prepackaged (I'm on RHES/FC 4 and they have it as an rpm).

Though its not too difficult to compile it yourself (I've done that
before on an older server).

Also I think the instructions in the link above are for apache 1.3 and I
use apache 2, so if you do too, you dont need the 'AddModule mod_jk.c'
line in the httpd.conf but you do need to have config parameters
surronded in an IfModule tag like so:

<IfModule mod_jk.c>
        # Configure mod_jk
        JkWorkersFile /usr/local/helma-1.5.x/workers.properties
        JkLogFile     /var/log/httpd/mod_jk.log
        JkLogLevel    error

        # mount on default host
        JkMount /forms/*  helma
</IfModule>

Hope that helps,

Maks.

________________________________

From: helma-user-bounces <at> helma.org [mailto:helma-user-bounces <at> helma.org]
On Behalf Of paul
Sent: Friday, 10 November 2006 9:27 AM
To: helma-user <at> helma.org
Subject: [Helma-user] "mounting" helma app behind apache

Hi all,

I hope this is not an RTFM....
What I'd like to do is to "mount" multiple helma applications somewhere
in the PATH of my domain:

<VirtualHost foo.test.home:80>
  ServerName foo.test.home
  ...

  <Location />
     ProxyPass http://localhost:8080/ #thats jetty's http listener
  </Location>

this *seems* to work OK though I'm not entirely sure 'cause I was unable
to access the "manage" app. However:

  <Location /helma>
     ProxyPass http://localhost:8080/
  </Location>

lets me access helma from http://foo.test.home/helma but css breaks and
links don't work... I tried to set in apps.properties:

manage.mountpoint = /helma/manage
...
welcome.mountpoint = /helma

which results in:
HTTP ERROR: 404 %2F%2F+Not+Found
RequestURI=//
Powered by Jetty://

Question is basically how to make this work. I'm not bound to mod_proxy
in any way so any method is fine. I just feel I'm still missing the big
picture how this is supposed to work. Any advice, pointers to
docs/howtos are much appreciated.

thanks
 Paul

_______________________________________________
Helma-user mailing list
Helma-user <at> helma.org
http://helma.org/mailman/listinfo/helma-user
Permalink | Reply | 0 comments |
headers
paul | 10 Nov 20:03
Favicon

Re: "mounting" helma app behind apache

Hello Walter,

VividVisions, Walter Krivanek schrieb:
> I think you'll have to set "baseUri" in app.properties.
> http://helma.org/docs/guide/properties/listall#baseURI
Thanks, links are fixed now but there are still issues:

Config is now:
>> <VirtualHost helma.test.home:80>
>>   ServerName helma.test.home
>>   ...
>>
>>   <Location /helma>
>>      ProxyPass http://localhost:8080/ #thats jetty's http listener
>>   </Location>

reference installation accesses helma directly over
http://localhost:8080, the only difference wrt server.properties is
"baseURI = /helma" for the "behind apache" version.

Problems with "behind apache" and baseURI = /helma:

- links for static content are incorrect, e.g. /static/helmaheader.png
is not found.

- accessing /manage over http://helma.test.home/manage doesn't work, I'm
 just getting the welcome-page no matter what URL the browser asks for.
Haven't tested other apps for now.

So either there are still some knobs and levers I haven't touched (to
many over here ;)) or this setup simply doesn't work and you need one
<VirtualHost> for each helma instance, thats basically what I need to know.

We had some stability issues with mod_jk in the past, but I'm certainly
willing to try it again if it solves the "need one vhost per helma
instance" problem. On a sidenode, mod_jk doesn't seem to be available
for apache-2.2 (used here) and my tests with mod_proxy_ajp and
helma-1.5.2 showed some protocol incompatibilities wrt AJP13, so this is
a no-go ATM...

thanks
 Paul
Permalink | Reply | 1 comment |
headers
Julian Tree | 11 Nov 21:53
Picon

Re: helma startup script on FreeBSD

Just to follow up on this, in case others having the same problem getting helma to automatically starting up  on freebsd. I recently has the "privileg" of visiting where the actually server is located. Trust me, it was not by choice.  

I witness the startup process on the monitor, and I notice that when the startup scripts hit the helma startup.sh,  it complained "java not found", everything all the sudden just make sense.

I just added the following line in the helma/start.sh (it is actually commented out)

JAVA_HOME=/usr/local

of course you should set it to the proper location where java is installed.

And now it works.  Below is my simple script for helma auto startup on freebsd 6.1. 

/usr/local/etc/rc.d/helma.sh

#!/bin/sh
#
#

echo "Starting Helma"
daemon '/helma/start.sh'

exit 0


On Oct 18, 2006, at 6:35 AM, Chris Zumbrunn wrote:


On Oct 18, 2006, at 12:22 , Julian Tree wrote:


daemon su -m userName -c '/helma/start.sh'

hmm, I tried that. Some how it doesn't seem to work.  If i call it on the command line, then it works, but not when I put it in the /etc/rc.conf

I'm doing this in jails and I have one jail where I couldn't get it to work either. It just didn't do anything and failed quietly. I have no idea why. 

Chris


On Oct 18, 2006, at 5:43 AM, Chris Zumbrunn wrote:


On Oct 18, 2006, at 11:31 , Julian Tree wrote:

Is anyone using Helma on FreeBSD?  Anyone has a start up script on  
FreeBSD to share?   I modified  one of the linux start up script on  
the mailing list, but it is not working on freebsd.  I have to  
manually restart helma everything system reboots.

I just have entries like below in my /etc/rc.conf file and don't go  
through a startup script:

daemon su -m userName -c '/path/to/helma/start.sh'

Chris

_______________________________________________
Helma-user mailing list

Julian Tree

_______________________________________________
Helma-user mailing list

_______________________________________________
Helma-user mailing list

Julian Tree

 

_______________________________________________
Helma-user mailing list
Helma-user <at> helma.org
http://helma.org/mailman/listinfo/helma-user
Permalink | Reply | 0 comments |
headers
Hannes Wallnoefer | 13 Nov 14:32
Picon
Gravatar

Helma 1.5.3 released

Hi, I just switched the download page to make the last 1.5.3 release
candidate into 1.5.3 final

http://helma.org/download/

As usual, this is the best Helma release so far, so go and get it.

hannes
Permalink | Reply | 0 comments |

Gmane