headers
Maksim Lin | 3 Apr 02:53
Picon

Re: velocity

Hi Michi,

I am using the Velocity extension at the moment, and have run into
exactly the same issues and am currently working on fixing them but
don't a fix yet, but I'l outline what I've found so far in case others
on the list may be able to help.

The reason $this.href() works but not  $this.account.href() is because
$this.account returns a Java object of class:
helma.objectmodel.db.Node and NOT of helma.scripting.rhino.HopObject
whereas $this DOES return a HopObject object.
Now I havn't been able to figure out why?
Its seems to happen whenever you get a object from a Helma collection
eg. $root.account.get(5) and of course you can't call a helma function
like href() on a Node object because its HopObjects that have it and
other functions.

Now I suspect that there is a way for me to get a hopObject based on a
Node object, but so far I have only been able to find that HopObject
have an associated Node but not the other way around - any ideas from
people familiar with Helmas internals??

And of course once the above issue is solved, you could fix the floats
display issue with just an extra method call like:

$this.invoiceId.toFixed()

Anyways I too am quite eager to test the new&improved JSTemplate from
Jürg but I want to stick with Velocity for now because of my
familiarity with it and good tool support.
(Continue reading)

Permalink | Reply | 6 comments |
headers
Maksim Lin | 4 Apr 01:54
Picon

Re: velocity

Well I think I've found a solution to this problem. In the end it was
simply a matter of checking for objects implementing INode as well as
the Scriptable interface since INode do essentially seem to be just
HopObjects that are in a DB (xml or sql). The thing that stumped me
for a bit awas then what to use as a scope arguement, so in the end
I've just ended us using the threadlocal "global"  variable.
It seems to work fine, though you can't actually do what I proposed in
my earlier email and call a method on HopObjects number property (ie.
$response.data.mycar.wheel.toFixed(1) ) but you can just make this a
"macro" js function and call it like so:

$response.data.mycar.gerWheels()

and in Car folder, macros.js define:

function getWheels() {
  return this.wheels.toFixed(1);
}

Of course putting the function into macros.js is just a convention and
any function defined for a HopObject can be called this way.

Passing arguements to functions also seems to work ok.

I also made asmall change to stop HopObject being 'unwrapped' into
INodes as I don't think this is useful.

I've attached the small patch (against current CVS version)  that
implementd this change, hopefully it can go into CVS if its ok by you
Jürg.
(Continue reading)

Permalink | Reply | 5 comments |
headers
Maksim Lin | 5 Apr 08:46
Picon

Re: velocity

Hi again,

I've made another small addition to the velocity code to allow for use
of velocitys #include directive.
This introduces a new config property (for your app.properties file):
velocity.static

which should have the full system path to the folder containing the
files you want to use with #include or if you dont specify it, it wil
default to looking in "appDir/static".
eg.
velocity.static = c:/helma/apps/myApp/includes

Please note that this patch also includes my patched code from
yesterday but cleaned up (my previous patch file included my project
specific files - sorry about that).

Maks.

On 4/4/06, Maksim Lin <maksim.lin <at> gmail.com> wrote:
> Well I think I've found a solution to this problem. In the end it was
> simply a matter of checking for objects implementing INode as well as
> the Scriptable interface since INode do essentially seem to be just
> HopObjects that are in a DB (xml or sql). The thing that stumped me
> for a bit awas then what to use as a scope arguement, so in the end
> I've just ended us using the threadlocal "global"  variable.
> It seems to work fine, though you can't actually do what I proposed in
> my earlier email and call a method on HopObjects number property (ie.
> $response.data.mycar.wheel.toFixed(1) ) but you can just make this a
> "macro" js function and call it like so:
(Continue reading)

Permalink | Reply | 4 comments |
headers
Michael Platzer | 5 Apr 09:50
Picon

Re: velocity

why wouldn't you want to put your included velocity-files also in the 
prototype-directories?
putting unparsed template files into the static directory just doesn't 
sound like a good idea to me.

besides that, thanks a lot for the patches! These will make that 
extension a lot more powerful!

  michi

Maksim Lin schrieb:
> Hi again,
>
> I've made another small addition to the velocity code to allow for use
> of velocitys #include directive.
> This introduces a new config property (for your app.properties file):
> velocity.static
>
> which should have the full system path to the folder containing the
> files you want to use with #include or if you dont specify it, it wil
> default to looking in "appDir/static".
> eg.
> velocity.static = c:/helma/apps/myApp/includes
>
> Please note that this patch also includes my patched code from
> yesterday but cleaned up (my previous patch file included my project
> specific files - sorry about that).
>
> Maks.
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Maksim Lin | 6 Apr 05:06
Picon

Re: velocity

Hi Michi,

Thanks for the feedback.

The reason I added this was to allow me to pull in global html
"header" & "footer" files that are used in our existing static pages
of our website (served by apache) since I didn't want to have to keep
these updated inside my helma app (and they are maintained by a
webdesigner collegue).

So thats really the explaination of why I chose to use a 'global'
include dir, rather then having them in individual prototype dirs.

It wouldn't be too hard to change the existing code to also load from
prototype dirs un-parsed files but I'm trying to now limit more work
on the velocity extension until I've had a chance to try out the
new&improved JS Template system as if it works well for me, I would
like to eventually switch to it since it really appeals to me as an
elegant solution and I dont think having 3 different templating
systems is good long term (would really confuse new-comers).

Maks.

On 4/5/06, Michael Platzer <michael.platzer <at> knallgrau.at> wrote:
> why wouldn't you want to put your included velocity-files also in the
> prototype-directories?
> putting unparsed template files into the static directory just doesn't
> sound like a good idea to me.
>
> besides that, thanks a lot for the patches! These will make that
(Continue reading)

Permalink | Reply | 0 comments |
headers
Juerg Lehni | 6 Apr 07:38
Gravatar

Re: velocity

Maks,

I haven't had the time to review the patch yet.

But I would say given the amount of work you're putting into this, it  
would make sense if you became the owner of the extension. I am not  
using it for my own projects, so I don't think I will keep working on  
it.

It's nice to see that something I've started is continuing to live on  
its own.

So if you don't have CVS access yet, please contact Hannes about it.  
And then I would say you're free to submit any patches you think make  
sense, after having discussed it with other users of this extension.

Jürg

Am 05.04.2006 um 15:46 schrieb Maksim Lin:

> Hi again,
>
> I've made another small addition to the velocity code to allow for use
> of velocitys #include directive.
> This introduces a new config property (for your app.properties file):
> velocity.static
>
> which should have the full system path to the folder containing the
> files you want to use with #include or if you dont specify it, it wil
> default to looking in "appDir/static".
(Continue reading)

Permalink | Reply | 1 comment |
headers
Maksim Lin | 6 Apr 09:10
Picon

Re: velocity

Thanks Jürg.
As I mentioned in my previous email, I'd like to eventually switch to
your "JSTemplate engine" but at the moment I already have 3 smallish
projects in dev (and soon to go into prod) that are using the Velocity
extension so I'm quite motivated to work on it now and maintain it for
the foreseeable the future.
And thanks again for writing the extension in the first place, its
much easier for me to build on your work then to have tried writing
this from scratch.

Maks.

On 4/6/06, Juerg Lehni <juerg <at> scratchdisk.com> wrote:
> Maks,
>
> I haven't had the time to review the patch yet.
>
> But I would say given the amount of work you're putting into this, it
> would make sense if you became the owner of the extension. I am not
> using it for my own projects, so I don't think I will keep working on
> it.
>
> It's nice to see that something I've started is continuing to live on
> its own.
>
> So if you don't have CVS access yet, please contact Hannes about it.
> And then I would say you're free to submit any patches you think make
> sense, after having discussed it with other users of this extension.
>
> Jürg
(Continue reading)

Permalink | Reply | 0 comments |
headers
Janos BEKESI | 24 Apr 15:14

Date type differences helma 1.4.3 - 1.5.x ?

Hi all,

does anybody know of incompatibilities or differences between helma 
1.4.3 and 1.5.x regarding the handling of dates?

our app throws errors when run by helma 1.5.x with respect to missing 
date values (I think it complains about a date value being undefined or 
null -- helma 1.4.3 has no such complaints, however).

any insight would be highly appreciated, since we would like to switch 
to 1.5.x to use j. lehnis template engine.

bye,

Janos Bekesi
Permalink | Reply | 4 comments |
headers
Chris Zumbrunn | 25 Apr 08:26
Picon

Re: Date type differences helma 1.4.3 - 1.5.x ?


On Apr 24, 2006, at 3:14 PM, Janos BEKESI wrote:

> Hi all,
>
> does anybody know of incompatibilities or differences between helma
> 1.4.3 and 1.5.x regarding the handling of dates?
>
> our app throws errors when run by helma 1.5.x with respect to missing
> date values (I think it complains about a date value being  
> undefined or
> null -- helma 1.4.3 has no such complaints, however).
>
> any insight would be highly appreciated, since we would like to switch
> to 1.5.x to use j. lehnis template engine.

I'm not aware of any such differences. Can you reduce the problem to  
a mini-app, so that it can be easily reproduced?

Chris
Permalink | Reply | 3 comments |
headers
Janos BEKESI | 26 Apr 19:21

Re: Date type differences helma 1.4.3 - 1.5.x ?

after some debugging I found that perhaps a call of

"Node.prototype.constructor.apply( this, [ space, name ] );"

does not work anymore; are there some workarounds or has the convention 
changed in calling constructors of prototypes?

bye, J.

Chris Zumbrunn wrote:
> 
> I'm not aware of any such differences. Can you reduce the problem to  a 
> mini-app, so that it can be easily reproduced?
> 
> Chris
> 
>
Permalink | Reply | 2 comments |

Gmane