headers
Anton Pirker | 1 Dec 10:56

Handle Errors caused by wrong Url

Hi fellow Helmaoids!

I have an action login at my site: http://www.example.com/login
but when someone enters the url http://www.example.com/login/
he/she gets an ugly sqlexception.

Is it possible to replace this with some custom build error-page? (or 
just redirect to root?)
So when someone enters a wrong url (something helma can't handle) it 
displays an errorpage or just redirects to some predefined page?

thanks in advance
Anton
Permalink | Reply | 1 comment |
headers
Paul Alexandrow | 1 Dec 11:00
Picon

Re: Handle Errors caused by wrong Url

you can define the following parameters in app.properties

# error: The name of the error action in root prototoype
error = errorActionName

# notfound: The name of the notfound action in root prototoype
notfound = notFoundActionName

-p

Anton Pirker wrote:
> Hi fellow Helmaoids!
> 
> I have an action login at my site: http://www.example.com/login
> but when someone enters the url http://www.example.com/login/
> he/she gets an ugly sqlexception.
> 
> Is it possible to replace this with some custom build error-page? (or 
> just redirect to root?)
> So when someone enters a wrong url (something helma can't handle) it 
> displays an errorpage or just redirects to some predefined page?
> 
> thanks in advance
> Anton
> 
> 
> _______________________________________________
> Helma-user mailing list
> Helma-user <at> helma.org
> http://helma.org/mailman/listinfo/helma-user
(Continue reading)

Permalink | Reply | 0 comments |
headers
Hannes Wallnoefer | 1 Dec 17:09
Picon
Gravatar

Re: JavaScript Templating Engine

2005/11/30, Juerg Lehni <juerg <at> scratchdisk.com>:
> Because of my thoughts yesterday evening, I was thinking about
> implementing a template engine directly in JavaScript this morning,
> by creating a RegExp based parser that creates the string for a
> function that would render the given template and then evaluate that
> string, cache the resulting function in a template cache and call it
> each time the template needs to be rendered.

This is basically what .hsp files did in Helma, way before skins and
macros were introduced. Support for .hsp files is still in Helma, so
check it out: Add a file called hsp_action.hsp to your Root proto with
the following content:

1 2 3
<% if (true) %>
   foo
<%= 33 + 234 %>

This will generate a function hsp_action() in the Root proto which,
when invoked via HTTP as /hsp, will render the following output:

1 2 3 foo 267

>From what I understand, even the implementation is very similar to
what you did. See
helma.scripting.rhino.HacHspConverter.processHspBody() for how it's
done in Helma.

>
> I went ahead and created a little test, which showed that the concept
(Continue reading)

Permalink | Reply | 1 comment |
headers
Chris Zumbrunn | 1 Dec 18:12
Gravatar

Re: JavaScript Templating Engine

On Dec 1, 2005, at 5:09 PM, Hannes Wallnoefer wrote:

> This is basically what .hsp files did in Helma, way before skins and
> macros were introduced. Support for .hsp files is still in Helma, so
> check it out: Add a file called hsp_action.hsp to your Root proto with
> the following content:
>
> 1 2 3
> <% if (true) %>
>    foo
> <%= 33 + 234 %>
>
> This will generate a function hsp_action() in the Root proto which,
> when invoked via HTTP as /hsp, will render the following output:
>
> 1 2 3 foo 267

Could we have a renderAsStringUsingOldHspEngine()?

Hsp's were dumped in favor of skins/macros in order to encourage
better coding practices, correct? Maybe forcing the hsp rendering
to be handled analog the current skin handling and inside a separate
JS context (if that turns out to be doable) would be an appropriate
way to achieve that goal without eliminating "the feature"?

Chris
Permalink | Reply | 0 comments |
headers
daniel k. gebhart | 7 Dec 14:34
Picon

non executable unix scripts

Hi!

It would be great to chmod (755 / a+x) the shell scripts in Helma
CVS.

-rw-r--r--   1 dkg  wheel    69  3 Dez  2002 compile.sh
-rw-r--r--   1 dkg  wheel  2134 16 Sep  2003 hop.sh
-rw-r--r--   1 dkg  wheel   825 16 Jul  2002 build/build.sh

Executing compile.sh ends up in permission errors because of the
current file permissions.

best regards,
  daniel
Permalink | Reply | 5 comments |
headers
Chris Zumbrunn | 9 Dec 13:15
Gravatar

Re: non executable unix scripts

On Dec 7, 2005, at 2:34 PM, daniel k. gebhart wrote:

> It would be great to chmod (755 / a+x) the shell scripts in Helma
> CVS.
>
> -rw-r--r--   1 dkg  wheel    69  3 Dez  2002 compile.sh
> -rw-r--r--   1 dkg  wheel  2134 16 Sep  2003 hop.sh
> -rw-r--r--   1 dkg  wheel   825 16 Jul  2002 build/build.sh
>
> Executing compile.sh ends up in permission errors because of the
> current file permissions.

Except for compile.sh they work fine for me directly out of CVS. Must 
be the way you do the checkout/export.

I would change the execution bit on compile.sh as well, if I could 
figure out how to convince CVS to make the new setting stick. Can 
anybody enlighten me?

Chris
Permalink | Reply | 4 comments |
headers
Michael Platzer | 9 Dec 13:27
Picon

Re: non executable unix scripts

Chris Zumbrunn schrieb:

> On Dec 7, 2005, at 2:34 PM, daniel k. gebhart wrote:
>
>> It would be great to chmod (755 / a+x) the shell scripts in Helma
>> CVS.
>>
>> -rw-r--r--   1 dkg  wheel    69  3 Dez  2002 compile.sh
>> -rw-r--r--   1 dkg  wheel  2134 16 Sep  2003 hop.sh
>> -rw-r--r--   1 dkg  wheel   825 16 Jul  2002 build/build.sh
>>
>> Executing compile.sh ends up in permission errors because of the
>> current file permissions.
>
>
> Except for compile.sh they work fine for me directly out of CVS. Must 
> be the way you do the checkout/export.
>
> I would change the execution bit on compile.sh as well, if I could 
> figure out how to convince CVS to make the new setting stick. Can 
> anybody enlighten me?

as far as i know, you can only do this by directly adding +x on the 
cvs-server itself for the according files.

greets,
  michi
Permalink | Reply | 3 comments |
headers
Chris Zumbrunn | 9 Dec 14:27
Gravatar

Re: non executable unix scripts

On Dec 9, 2005, at 1:27 PM, Michael Platzer wrote:

> Chris Zumbrunn schrieb:
>
>> Except for compile.sh they work fine for me directly out of CVS. Must 
>> be the way you do the checkout/export.
>>
>> I would change the execution bit on compile.sh as well, if I could 
>> figure out how to convince CVS to make the new setting stick. Can 
>> anybody enlighten me?
>
> as far as i know, you can only do this by directly adding +x on the 
> cvs-server itself for the according files.

Well, I can't do *that*.  Maybe Hannes will get around to it once.

Chris
Permalink | Reply | 2 comments |
headers
Michael Platzer | 9 Dec 14:37
Picon

Re: non executable unix scripts

Chris Zumbrunn schrieb:

>> as far as i know, you can only do this by directly adding +x on the 
>> cvs-server itself for the according files.
>
> Well, I can't do *that*.  Maybe Hannes will get around to it once.

i think you can :-)
use your cvs-password to connect to adele via ssh.
 > cd /opt/cvs/hop/helma
 > chmod +x compile.sh,v

you (czv) are even the owner of that file, so this should work for you. 
i (michi) do get a 'operation not permitted'

   michi
Permalink | Reply | 1 comment |
headers
Chris Zumbrunn | 9 Dec 14:45
Gravatar

Re: non executable unix scripts

On Dec 9, 2005, at 2:37 PM, Michael Platzer wrote:

> Chris Zumbrunn schrieb:
>
>>> as far as i know, you can only do this by directly adding +x on the 
>>> cvs-server itself for the according files.
>>
>> Well, I can't do *that*.  Maybe Hannes will get around to it once.
>
> i think you can :-)
> use your cvs-password to connect to adele via ssh.
> > cd /opt/cvs/hop/helma
> > chmod +x compile.sh,v
>
> you (czv) are even the owner of that file, so this should work for 
> you. i (michi) do get a 'operation not permitted'

Yep! In deed, it worked. Thanks!

Chris
Permalink | Reply | 0 comments |

Gmane