[Helma-NG] Aida - Initial Checkin

[Hannes Wallnoefer]

Hi Matthias,

thanks for checking in from my part as well.

2008/6/4 Matthias Platzer <matthias.platzer at knallgrau.at>:
>
> Currently i'm putting all my modules into aida. That doesn't mean that
> they shouldn't be moved
> to the main /helma modules repository.

One word about module placing and naming. You put your modules into a
directory in your app dir called "modules" and therefore end up with
module names starting with "modules.". This makes it not very easy to
move, reuse etc your modules as the first part of the module name
should be the top level namespace, e.g. "helma" or "aida".

Two possible ways to achieve this: either replace the modules
directory in the app dir with a directory called "aida" (or whatever
your top level namespace is going to be), or move them to a top-level
"modules" directory that you add to the helma module path:

  demo-app
     |-app
     L-modules

And then in directory demo-app:

  java -jar (helma-ng)/run.jar  app  modules

BTW, I see that your app needs to be started from the app directory
because otherwise the APP_DIR variable is going to be wrong. As a
workaround, you could use:

   APP_DIR = new File(getResource(".").name);

Getting the app/module dirs is currently missing in NG, I think we
should add it for 0.3, probably in helma.rhino for the low level api
and helma.app for a higher level api.

>>
>> And since it would depend on a lower level sql module, looks like it
>> will be useful to port the current helma.Database module over to
>> helma-ng.
>>
>
> see:
> http://dev.helma.org/wiki/Helma+NG+Wishlist/
> Anybody who could help on this would be very welcome.
>
>> Its really cool your use of __get__  for html generation! I can
>> imagine
>> now using this code pattern for lots purposes.
>>
>
> Yes, JsAdapters are a cool thing. By the way, i agree with hannes (http://dev.helma.org/wiki/Helma+NG+Wishlist/#RemoveJSAdaptermagicfrommodulescopes
> ) that we should drop the JsAdapter magic from module loading.

I'm really happy that you say this. I thought that since you were
using it you'd like to keep it. But I can't think of any case where a
jsadapter-module couldn't be replaced by a jsadapter defined within a
module. Mostly replacing importModule(mod) with importFromModule(mod,
jsadapterproperty) should be all that's needed.

While we're talking about ng tricks: The thing that makes
understanding aida really hard for me is the usage of the per-thread
global scope. The really really nice thing about module imports is
that you always know where things come from - at least that's the idea
behind it. Using global to define globals really breaks this.

Actually, I just started thinking that we could do without the
per-thread global at all. Since modules are by default instanciated
once per request (unless you set __shared__ = true), so setting stuff
in the module scope could replace the per-thread scope with the added
benefit of making visible where stuff comes from.

For example, the req, res and session variables could be set in the
helma.simpleweb module scope, and then used like this from other
modules:

    importFromModule('helma.simpleweb', 'req', 'res', 'session');

Not that much work IMO. Unfortunately this isn't working from the
shell right now, as each line in the shell is handled like a separate
request/invocation.

> And you should also check out the way i'm using the html module in the
> helper (macro) module:
>
> app/controllers/article_controller.js
> importHelpers("html", "html"); // looks into the /app/helpers/
> directory for html_helpers.js and adds it to the context as "html"
>
> app/views/article/index.html.skin
> <% html.h1 "Welcome to AIDA Blog" %>

Nice, except you could also have written

<h1>Welcome to AIDA Blog</h1>

:-)

>> And the appBuilder.js looks familiar since I built mine
>> (http://dev.helma.org/wiki/Builder+Application/) for helma 1.6 based
>> on
>> reading a description of how that functionality worked in rails :-)
>>
>
> Currently that is just sketching. But it's really easy to accomplish
> migrations.
> It's on my task list.
>
>> Also I really like your use of JSON for things like database config
>> - I
>> think it would be good to standardise on using json in helma-ng
>> anywhere
>> config info is needed as its a richer format then properties files and
>> more in keeping with being js-centric rather then java-centric.
>> I must admit though that my preferences are for more helma 1 style
>> development, expecially now that I have a number of apps in production
>> but this is just personal taste and I know there will be a large
>> number
>> of people who would love to have and use a js-on-rails framework
>> available - just witness the response Steve Yeggae received when he
>> mentioned he had built such a port 'inhouse' for a google project.
>>
>
> I'm also missing some concepts from helma1. Especially the
> "article.comments.href()" easiness to generate URLs.

Yes, the always-there href() method in Helma 1 was comfortable. Of
course it depended on Helma 1 URL handling. I think it should be
possible to implement this for other URL handling schemes.

When I wrote this

http://dev.helma.org/ng/Differences+between+Helma+1+and+Helma+NG/#NoneedforcomplexURLcompositing

I actually thought that there was no need for a href() method in Helma
NG, but I'm not so sure anymore (I had some problems when I wrote the
demo app, I think).

> And another goal should be to be able to use aida side by side with a
> helma1 module.

Why wouldn't this be possible, assuming that the Helma 1 module is
well-behaved and you're willing to make some changes to adapt to Helma
NG specifics?

hannes

> matt
>
>> Maks.
>>