Hopbot log for 2009-11-10 - Helma IRC channel: #helma on irc.freenode.net

2009-11-10:

[10:13] <emilis_info> is there a human version I can read about how helma/webapp resolveInConfig() should work? (Helma NG)
[10:13] <triotex> hi! does anybody know why we have a win32 and a linux download? the only diff i see is the missing start.[bat | sh]
[10:14] <triotex> if there is no other reason, we should ship both, the start.sh and the start.bat, in the package and offer a tar.gz and a zip download url.
[10:15] <triotex> which makes much more sense for beginners
[10:30] <simono> emilis_info: it matches the req.path against the given regex. afair parts of the path can be caught in groups and those groups are passed as extra arguments to the action
[10:30] <simono> it's similar to what rails / django do
[10:31] <emilis_info> simono, yes, but when parts of regexp are treated as a function name and when -- as arguments to a function is still a mystery to me
[10:36] <simono> emilis_info: seems to me it tries to match to functions in the given module (or index per default) and everything after that is tread as params
[10:36] <simono> that's at least how jsdoc webapp works
[10:37] <emilis_info> heh
[10:37] <emilis_info> ok
[10:37] <emilis_info> I have a url: /docs/123
[10:38] <emilis_info> how do I translate it to require("MyDocs").showDocument(123) ?
[10:44] <simono> [docs/(.*)', 'MyDocs']
[10:45] <emilis_info> and "showDocument()"?
[10:45] <simono> that doesn't happen in the action? :)
[10:45] <emilis_info> what action?
[10:45] <simono> ah showDocument is the action?
[10:46] <emilis_info> it is an exported function from the "MyDocs" module
[10:46] <simono> ok yes
[10:46] <emilis_info> :)
[10:46] <simono> sorry i'm talking helma1-speek
[10:46] <emilis_info> ah... that's why we don't understand each other :)
[10:47] <simono> but take a look at how jsdoc does it.. it's the same thing jsdoc.actions.index = MyDocs.showDocument
[10:48] <simono> (though the first parameter to showDocument will be req if you use the webapp)
[10:48] <emilis_info> hmh
[10:49] <emilis_info> req is not bad if I can get 123 part easily from it
[10:49] <simono> i think for now it's easier if the functions you export from MyDocs are named like the url-parts
[10:49] <emilis_info> hmm
[10:50] <emilis_info> but MyDocs.index(req) should work?
[10:50] <simono> do you have code to show? :) maybe easier
[10:50] <simono> like your config.js and MyDocs.js
[10:51] <simono> MyDocs.index(req) will be called for the url /docs/index/123 with the urls-array i posted above
[10:52] <simono> you match everything past /docs/ to MyDocs. helma will peek into MyDocs and try to match the next uri-path-element to one of your functions and the rest of the uri will be extra parameters to the fn
[10:56] <emilis_info> http://helma.pastebin.com/m65fba2f8
[10:56] <emilis_info> the thing I have got now
[10:57] <emilis_info> I am looking for ways to simplify it
[10:59] <emilis_info> I tried reading resolveInConfig() but I can't even understand how the current code works
[11:00] <emilis_info> maybe I am too stupid or too tired
[11:00] <emilis_info> :/
[11:20] <simono> sorry lunch, reading now
[11:21] <emilis_info> thank you :)
[11:21] <simono> emilis_info: there should be an easier way, you don't get a 2nd parameter in index() ?
[11:22] <emilis_info> I didn't use parenthesis
[11:22] <emilis_info> now I'll try
[11:22] <simono> hold on i'll show you in pastebin what i mean
[11:22] <simono> like so: http://helma.pastebin.com/m428498ee
[11:23] <simono> i added a regex-group and the 2nd parameter to index
[11:24] <emilis_info> hmm
[11:24] <emilis_info> I'll check what that gives me :-)
[11:25] <emilis_info> yay
[11:25] <emilis_info> at least now I can get the "123" part
[11:26] <emilis_info> what about specifying showDocument() function instead of index() ?
[11:27] <emilis_info> What I'm trying to achieve is route /docs/ to showDocumentList(), /docs/123 to showDocument(123) and /docs/123.json to showDocumentFormat(123, "json")
[11:27] <emilis_info> do I have any hope? :-)
[11:28] <simono> hm probably not with the default resolveInConfig way
[11:29] <emilis_info> heh
[11:29] <simono> one way would be to catch the /docs/ url in a dispatching index-function and resolve anything past /docs/ yourself.. basically replacing resolveInConfig
[11:29] <emilis_info> will have to try something else then
[11:29] <emilis_info> that's what I was doing with Govdoc.index() previously
[11:29] <emilis_info> L(
[11:29] <emilis_info> :)
[11:29] <simono> afaik what you have now is how it currently is supposed to work in ng:
[11:30] <simono> :)
[11:30] <simono> i see
[11:31] <simono> well currently the action (or the view function.. however you want to call it) is visible in the uri
[11:31] <emilis_info> is it possible to replace resolveInConfig() with my own function without touching or reimplementing lots of Helma code?
[11:32] <simono> for now i would do it with a dispatching index() that does this kind of resolving
[11:32] <emilis_info> there could be a third element in url, like [RegExp, ModuleName, FunctionName]
[11:33] <simono> ah i see what you mean, hm
[11:33] <emilis_info> or a way to bypass resolveInConfig
[11:34] <simono> why don't you like the resolver in index() ? b/c of overhead?
[11:34] <emilis_info> but that would require more architecturing and would have some negative side-effects to people trying to share code
[11:35] <emilis_info> I don't like it, because this means, that I may need a resolver for every Controller module
[11:35] <simono> i think resolveInConfig is supposed to be an easy way to get something up & running in a familiar way (it's similar to other controller-routings)
[11:35] <emilis_info> hmm
[11:35] <simono> can't you import the same resolver in every controller? but o/c i don't know much about your app :)
[11:36] <emilis_info> so I can use my own router instead of resolveInConfig?
[11:36] <simono> i can't say if replacing resolveInConfig will be easy
[11:36] <emilis_info> having two routers seems too bloaty to me
[11:36] <emilis_info> ah... ok
[11:36] <simono> for me, writing an extra resolver in a catch-all action was always good enough :)
[11:37] <emilis_info> :)
[11:37] <emilis_info> I understand it
[11:37] <simono> glad i could help
[11:37] <emilis_info> I was used to this kind of structure
[11:37] <emilis_info> yes, thank you very much
[11:37] <emilis_info> at least I understood that I'm not crazy ;)
[11:37] <simono> what framework did you use before?
[11:37] <emilis_info> my own baked PHP framework
[11:38] <emilis_info> some time ago I got tired of all the url routing through multiple routers and dropped url matching completely
[11:38] <emilis_info> nowadays I would just use request params
[11:38] <emilis_info> but I tried to see if Helma had something more to offer
[11:38] <emilis_info> :)
[11:39] <simono> you know helma1 it is much more stable & mature but possible not as sexy as ng
[11:39] <emilis_info> I haven't tried helma1
[11:40] <simono> and it's url routing is very different as the object relations define the url
[11:40] <emilis_info> I just started exploring the SSJS world with HelmaNG
[11:40] <emilis_info> chose NG so I could start with something small and new
[11:40] <emilis_info> :)
[11:40] <simono> good choice :) imo it's the easiest to grasp
[11:41] <emilis_info> I think so too
[11:41] <emilis_info> I also liked the performance
[11:41] <emilis_info> :)
[11:41] <simono> :)
[11:41] <emilis_info> hmm
[11:42] <emilis_info> Are you a NG core developer? :) Do you think there's any way for a feature request for [RegExp, Module, Function] to sneak in?
[11:42] <emilis_info> ;)
[11:43] <simono> i'm an early adaptor just like you... but feature request are welcome on the mailing list
[11:43] <simono> if you have a patch for that feature it's more likely to get attention :)
[11:43] <emilis_info> I think I'll try :)
[11:44] <emilis_info> For waht project are you adopting Helma? :)
[11:46] <simono> helmang? we don't know yet :) we have helma1 in production use for big media-comp websites
[11:46] <simono> media-corp
[11:46] <simono> f
[11:47] <emilis_info> oh... ok :)
[11:47] <simono> you yourself?
[11:48] <emilis_info> I'm writing a scrapper to scrap news and documents from goverment websites and to present them in a simpler fashion
[11:48] <emilis_info> mySociety kind of project
[11:48] <simono> oh nice
[11:48] <simono> got domain yet?
[11:48] <emilis_info> chose SSJS so that we don't have to argue PHP vs Python vs Ruby
[11:48] <emilis_info> not yet
[11:49] <emilis_info> I'll have a demo in a few days online
[11:49] <emilis_info> :)
[11:49] <simono> great, announce on mailinglist :)
[11:49] <emilis_info> ok :)
[11:55] <emilis_info> hmm
[11:56] <emilis_info> I think I will definately propose a patch... the current system also adds trailing slashes to urls: /docs/123 --> /docs/123/
[12:47] <robi42> fyi: imho, botic's helma workshop at the local java student user group of vienna university of technology yesterday (http://jsug.at/wiki/Helma_Workshop_2009) was really good. maybe some new fellow helmatics could be recruited. :)
[12:58] <simono> ack, i too heared it was very win!
[13:16] <emilis_info> simono, http://emilis.net/govsrvr/
[13:16] <emilis_info> I bet you will not understand a word :)
[13:30] <hannesw_> emilis_info, simono: Now reading up on your conversation
[13:31] <hannesw_> the webapp/resolve stuff is still highly movable (i.e. not frozen)
[13:31] <emilis_info> hmm
[13:31] <emilis_info> so, a patch would be welcome?
[13:31] <hannesw_> so I'm happy about feedback
[13:31] <emilis_info> ok :)
[13:31] <hannesw_> sure
[13:31] <simono> emilis_info: right, i dont :) it is served by ng? nice...
[13:32] <emilis_info> simono, ng on some weak server
[13:32] <hannesw_> no guraantee i'll like it, of course :)
[13:32] <emilis_info> hannesw_, I understand :)
[13:33] <hannesw_> robi42: thanks for the info. Great to see botic evangelizing helma 1 :)
[13:36] <robi42> hannesw_, yep, helma could use some dhh kind of guy for evangelizing (preferably less testosterone-driven than that rails guy, tho). ;)
[13:44] <hannesw_> emilis_info: the ability to map an url to a single exported function was lost in some previous rewrite
[13:44] <hannesw_> i could try to re-enable that via something like:
[13:44] <hannesw_> [ /docs\/(.*)/, "modules/Govdoc.docs" ]
[13:45] <emilis_info> hannesw_, that would be very helpful
[13:45] <hannesw_> or maybe [ /docs\/(.*)/, "modules/Govdoc", "docs"] ?
[13:45] <emilis_info> it would save some duplicate code
[13:45] <hannesw_> do you have a suggestion?
[13:45] <emilis_info> I think the second is better
[13:45] <hannesw_> ok, think so too.
[13:46] <emilis_info> but keep in mind that you will have two modes of defining action names -- both in the regexp and in the third element
[13:46] <emilis_info> that may be confusing for someone
[13:48] <hannesw_> hm, what do you mean by define action name in the regexp?
[13:49] <emilis_info> I mean if you have [ /docs/, "modules/Govdoc" ], and the arriving URL is /docs/some_action, the current system would search for function "some_action()" in modules/Govdoc
[13:50] <emilis_info> or do I understand it wrong?
[13:51] <hannesw_> right - because you mapped on a module, not a single function
[13:53] <emilis_info> so... what would happen to /docs/some_action when it is matched by [ /docs/, "modules/Govdoc", "other_action" ]?
[13:54] <emilis_info> will "some_action" be lost in the process
[13:54] <hannesw_> if there's nothing defined for some_action in the regexp, it won't match
[13:54] <hannesw_> hm, wait, actually I'm not sure :)
[13:54] <hannesw_> yep, i think it won't match, unless it's defined in the regexp
[13:55] <hannesw_> and the urls array is iterated until something matches.
[14:00] <emilis_info> technicly the "/docs/some_action".match(/docs/) should return true
[14:03] <hannesw_> ok, actually it's all different :)
[14:03] <hannesw_> simono: you don't need regexp groups to capture extra arguments
[14:04] <hannesw_> all you need to do is add extra formal arguments to the action function
[14:04] <simono> oh, thx for info
[14:04] <simono> right.. we talked about that.. it checks the arguments of the action
[14:04] <hannesw_> so you just define the arguments, and if the extra path elements can be stuffed into it, the function is considered to match
[14:05] <simono> re: url-routing. i like neither and propose a third way, which would be: always map to functions not modules. less ambigious
[14:05] <emilis_info> but you won't remove regexp groups?
[14:05] <hannesw_> currently, regexp groups aren't used at all
[14:06] <simono> ok so it splits on / and those are extra arguments, i get it
[14:06] <emilis_info> I want to have [ /docs\/(\d+)\.(json|xml)/, "modules/Govdoc", "showDocumentFormat" ]
[14:06] <emilis_info> hmmm
[14:06] <hannesw_> simono: we had that at some point, but adding a route for each action is to verbose IMO
[14:06] <emilis_info> ah oh
[14:06] <emilis_info> pl
[14:06] <emilis_info> ok
[14:07] <simono> hannesw_: ok, no biggy. i'm just still not so convinced that relative urls will always work and that hooks into my problem with how we currently define urls
[14:07] <simono> we will see
[14:07] <hannesw_> emilis_info: I'm working on a pastebin item that shows what should currently work...
[14:07] <emilis_info> hannesw_, thank you :)
[14:08] <robi42> re url routing: second that adding a route for each action would be too verbose.
[14:10] <simono> ok :) you lazy devs
[14:12] <robi42> simono, it's not about laziness but about convenience and all that fuzzy warm feeling. ;)
[14:13] <simono> :)
[14:17] <hannesw_> emilis_info: so the following should work:
[14:17] <hannesw_> http://helma.pastebin.com/d7d0797d4
[14:18] <hannesw_> it maps /docs to the index function of modules/Govdoc.js
[14:18] <hannesw_> and you don't need to do any further checks
[14:19] <hannesw_> (you know the request has the docs prefix, and you get the extra id argument because you defined an extra argument in the function)
[14:19] <emilis_info> hmm
[14:19] <emilis_info> thanks
[14:20] <hannesw_> wait, have to check if it works :)
[14:20] <emilis_info> :)
[14:22] <hannesw_> hm, something's wrong...
[14:22] <emilis_info> aha
[14:23] <emilis_info> that's good
[14:23] <hannesw_> it works with /docs/index/2324234 ...
[14:24] <hannesw_> fixing it now...
[14:25] <emilis_info> are you sure the fix will work correctly
[14:26] <emilis_info> I'm not sure, but the whole resolveInConfig() was quite confusing to me... may be it needs clean-up?
[14:34] <hannesw_> i think what you really mean is it needs some design, right?
[14:34] <emilis_info> yup
[14:34] <hannesw_> that's not untrue
[14:34] <emilis_info> :)
[14:35] <hannesw_> I'm cleaing it up now
[14:57] <simono> emilis_info: re: class extending would you show me your extendObject
[14:57] <simono> inbrowser and helma1 we do this http://helma.pastebin.com/f5ff72cac .. which is for single "inheritance" only but clean (even crockford is okay with it lol)
[15:30] <emilis_info> simono, http://helma.pastebin.com/me4912e9
[15:33] <emilis_info> http://helma.pastebin.com/d658398f1
[15:33] <emilis_info> added usage example
[15:47] <simono> thx. you don't modify prototype-chain because you want multiple mixins?
[15:55] <emilis_info> simono, that went above my head... I would like mixins, sure, but not for the functions like "extendObject". Actually I just copied the code from helmaglobal.js "clone()" function
[18:00] <emilis_info> is there any way to empty shared module cache?
[18:00] <emilis_info> from the console
[18:00] <emilis_info> Helma NG
[18:00] <emilis_info> :)
[18:05] <robertg> afaik no (apart from exiting the shell and re-entering)
[18:06] <emilis_info> heh
[18:06] <emilis_info> thanks
[18:06] <emilis_info> btw, sometimes starting up Helma lags for a minute or so
[18:06] <emilis_info> I mean NG
[18:07] <robertg> 1 minute to start up? i can hardly believe
[18:08] <emilis_info> yup
[18:10] <emilis_info> http://helma.pastebin.com/d2051bbf1
[18:10] <emilis_info> 33 seconds
[18:17] <botic> @robi42: btw. we got a GO for Helma / tenez.at ;-) after long long discussions.
[18:18] <robi42> botic, great news. congrats. :)
[18:19] <robi42> (and looking forward to continuous integration support solutions for helma) ;)
[18:19] <robertg> @botic: yippee!
[18:19] <botic> BUT there is one more thing:
[18:20] <botic> we should look how maven and helma can play together and how we can perform automated unit tests
[18:21] <robi42> afaik rist already did something into this direction (helma/maven integration, that is). maybe ask him?
[18:25] <botic> oh good to hear. we will for sure. but first we have to create a google code post commit hook to check our repository after every commit
[18:27] <robi42> once told me he got it running so far that he could basically issue "mvn jetty:run" inside the helma dir...
[18:31] <botic> also one drawback: we have to perform a strict "tu-compatible" mvc, which means that the prototypes like Timeslot or Customer are just date access objects
[18:32] <botic> so i need managers for all kind of data: TimeslotMgr, CustomerMgr, ReservationMgr, ....
[18:32] <botic> but okay, that's a deal. better this than JSF, jBoss and other J2EE-stuff
[18:34] <botic> the final application will have the following structure: /apps/base with macros, object-methods; /apps/admin and /apps/frontend with all the actions and special admin/frontend-macros; /db-mapping with all type.properties
[18:35] <robi42> btw, you could also, e.g., impl. JPA annotated domain classes and DAOs in java and use them inside helma via class.properties file.
[18:35] <botic> do you have a link for that?
[18:35] <robi42> there's no documentation. ;)
[18:36] <botic> ohhhhhkay ;-)
[18:36] <robi42> but i think i've got some example prototypic code laying around somewhere.
[18:36] <robi42> will have a look.
[18:37] <robi42> oh, there's some documentation of class.properties: http://helma.org/Documentation/Properties+Files/class.properties/
[18:37] <botic> i just found it
[18:38] <robi42> one of the drawbacks of this approach is that you also have to take care of url routing yourself then.
[18:38] <robi42> by impl. getChildNode()
[18:41] <robi42> anyways, hth. will send you the exemplary code as soon as i find it. ;)
[18:45] <botic> okay i will play around with that after finishing my homework for the romanian course ;-)
[18:46] <botic> that's the reason why the demo app yesterday was called "inafara"
[18:48] <botic> WTF: http://bit.ly/3mYcaS "import axiom.framework.IPathElement;"
[18:48] <botic> have they ever commited code back to helma?
[18:51] <botic> every source file in their axiom.* packages still has as author "hannes"
[21:44] <robi42> botic, found aforementioned class.properties code.
[21:44] <robi42> overall pretty hackish and so on.
[21:45] <robi42> but i guess it shows the idea.
[21:45] <botic> oh nice!
[21:45] <robi42> https://dav.robert42.com/springinator.zip
[21:45] <robi42> and it works. ;)
[21:45] <robi42> just tested it.
[21:46] <robi42> among other things, it uses old-school hibernate xml-mapping files.
[21:47] <robi42> but should be pretty easy to adapt to jpa annotations.
[21:48] <botic> wow - looks nice
[21:49] <robi42> it's only some proof-of-concept kinda thing but thx. :)
[21:50] <robi42> the question is if one would like to go this way anyway.
[21:51] <robi42> i mean, one more or less looses almost all things helmatic this way. ;)
[21:52] <robi42> apart from rendering/actions/macros/skins...
[21:54] <botic> a short question: can i set req.skinpath in the global.onStart()?
[21:54] <botic> or for each request with onRequest?
[21:57] <botic> okay looks like onRequest

 

 

In the channel now:

Logs by date: