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

2009-04-02:

[8:23] <hannesw> is trying to find out how useful/used the getOrderedView feature is...
[8:23] <hannesw> ...because we might want to cut it right away in 1.7 and replace it with getCollection().
[8:25] <simono> we don't use it. sorting is done in java?
[8:26] <hannesw> Yes.
[8:31] <simono> well we can always do that in js ourselves if we have to
[8:32] <hannesw> what?
[8:41] <simono> the sorting.. sorry, trying out limit/offset. was limit always available as an alias to maxSize? i like it
[8:41] <zumbrunn> I'm not using it either
[8:41] <zumbrunn> but those that have requested it probably are using it and liking it, I would think
[8:42] <hannesw> simono: no, i intruduced it together with offset
[8:42] <simono> ok
[8:43] <hannesw> i think it was implemented by manfred andres
[8:44] <hannesw> here's the announcement: http://helma.org/pipermail/helma-dev/2006-March/002665.html
[8:45] <hannesw> simono: is manfred near you? can you ask him if he's still using the updateable collections feature?
[8:46] <hannesw> I'd like to replace it with collections that use limit/offset internally to segment object loading.
[8:46] <simono> he's sick, won't be in this week
[8:46] <simono> i can check our repos if the feature is in use
[8:46] <hannesw> maybe ask robert?
[8:47] <simono> and that :)
[8:50] <hannesw> welcome rist and robi42
[8:50] <rist> guten morgen
[8:54] <simono> hannesw, about getOrderedView.. we don't use it anymore. it was a special case back then
[8:54] <simono> robert says he would rather use getCollection nowadays
[8:54] <hannesw> ok. will kick it then
[8:54] <simono> ok
[8:55] <hannesw> actually, the plan is to use limit/offset queries internally in subnode collections, so partitioned loading happens without any extra work
[8:59] <hannesw> created a new page on the wiki: http://dev.helma.org/wiki/New+features+in+Helma+1.7/
[8:59] <simono> mhm. so that would relief us from maxSize-ing all our collections as helma loads addinitional nodes only when needed?
[8:59] <hannesw> yes.
[9:00] <simono> nice, having to maxSize everything was a problem with archives
[9:00] <hannesw> and maxSize will be more efficient (probably) as it uses the new limit query, whereas before it only used the javax.sql.Statement.setMaxRows() feature
[9:00] <hannesw> only problem is I still have to implement that :-)
[9:01] <simono> hehe
[9:01] <hannesw> I'll have two wiki pages, http://dev.helma.org/wiki/New+features+in+Helma+1.7/ for the features that are actually implemented
[9:01] <hannesw> ... and I'll update http://dev.helma.org/wiki/Helma+1.7+wishlist/ to what I'm actually planning to do.
[9:02] <simono> well offset is solid, i just slapped it on all kinds of collections
[9:02] <hannesw> cool
[9:02] <hannesw> thanks simon
[9:03] <simono> ah about subskins.. do you by chance know if subskins can be overwritten?
[9:03] <hannesw> yes, they can
[9:04] <simono> cool, thx
[9:04] <hannesw> i.e. you can have a skin file down the repository path that only overwrites one/some subkins
[9:06] <simono> yes that's what i meant.
[9:13] <simono> @wishlist.. i don't understand how extending skins and having subskins works together. translating the django way i arrive at smth like this http://helma.pastebin.com/m18ac661d
[9:14] <simono> more like http://helma.pastebin.com/m397b0e4f
[9:15] <hannesw> updated the wishlist page with current status.
[9:16] <hannesw> simono: helma doesn't use #block/#endblock thing
[9:17] <simono> yes just translating 1:1 to make it obviouis how i understand the feature, as i don't understand how you imagine it with subskins :)
[9:18] <hannesw> I'm writing a new pastebin entry to show what I mean.
[9:19] <simono> thanks
[9:20] <hannesw> (note that i removed the rambling about deprecating #subskin naming from the wishlist page)
[9:22] <hannesw> here it is: http://dev.helma.org/bugs/show_bug.cgi?id=540
[9:22] <hannesw> oops, sorry. wrong link.
[9:23] <hannesw> http://helma.pastebin.com/f2ffec49
[9:23] <hannesw> Note that the #header and #content subskins in base.skin are optional, you could easilly make this skin "abstract" by omitting them
[9:30] <simono> now i get it.
[9:31] <hannesw> hm, this brings up another old topic, namely "standard macros" (in this case "render" and "extend")
[9:31] <simono> i like it. that's very close to what we currently but more convinient
[9:32] <hannesw> ok, we have skin_macro in modules/core/HopObject.js.
[9:33] <hannesw> i think i'd like to tie that into the core skin.java implementation
[9:33] <hannesw> extends, render/skin and maybe a few more.
[9:35] <simono> hm, why not do that in JS.. i was just thinking about wether this subskining-example you gave can be done with macros alone
[9:36] <hannesw> if it's possible, I'm all for doing it in js. I'm just thinking it needs close integration/access to Skin.java, but I may be wrong.
[9:38] <simono> if nothing comes up i will try a js-impl later... the way our skins are setup, we are expecting skin-inheritance. we emulate that by having of res.body, res.head, etc in the base.skin
[9:58] <hannesw> created new page: http://dev.helma.org/wiki/Defining+HopObject+mappings+programmatically/
[13:15] <hannesw> Another area I'd like to restructure: helmaTools
[13:15] <hannesw> I'd like to move helmaTools into the modules tree, maybe to modules/tools or whatever
[13:17] <hannesw> and for the sqlshell app, I'd like to move most of the db introspection functionality into the helma/Database.js module
[13:17] <hannesw> any thoughts?
[13:24] * simono just found out about helmaTools
[13:25] <hannesw> simono: helmaTools are under-exposed and partially under-developed :-)
[13:25] <hannesw> that's one of the reasons for moving them to modules
[13:26] <hannesw> actually i think it would be a good idea to move modules into the helma svn tree.
[13:26] <simono> :) i've heared about inspector.. moving to modules is probably a good idea
[13:26] <hannesw> the split-up tree with svn externals is just stupid
[13:26] <simono> @Database/db introspect ... interesting, we fought with that a couple of weeks ago when updating jala
[13:27] <hannesw> database introspection?
[13:27] <simono> e.g. http://dev.orf.at/trac/jala/changeset/353
[13:27] <hannesw> oh, cool!
[13:27] <simono> jala.db.metadata.getTableNames .. getColumns etc
[13:27] <hannesw> looks good. exactly what I wanted to do.
[13:27] <simono> :)
[13:28] <simono> with oracle.. there are problems. for example it doesn't transfer SEQUENCES .. tom explained to me way, didn't make sense. now we just create them in fixtures
[13:28] <hannesw> now the thing is I/we need that in helma core.
[13:29] <simono> you have big plans for 1.7 it seems :)
[13:30] <hannesw> nope, that's not big, just incremental improvements.
[13:31] <simono> don't know if you talked to robert, but skin-inheritance, db-metadata, getCollection are all things we would use / test immediatly
[13:31] <hannesw> nope, didn't talk to robert.
[13:54] <zumbrunn_> well, helmaTools *are* in the modules tree
[13:54] <zumbrunn_> it's just that they are zipped
[13:55] <zumbrunn_> (as part of the distribution packages)
[13:55] <zumbrunn_> I agree it is a good idea to have it in modules/tools without zipping it
[13:55] <hannesw> simono: that's great. getCollection() is already available. Skin-inheritance is coming soonish.
[13:56] <zumbrunn_> and merging them into the same tree in svn is good, too
[13:56] <hannesw> db-metadata would come from jala or sqlshell
[13:56] <hannesw> zumbrunn_: this is really just about svn tree organization.
[13:56] <zumbrunn_> ok
[13:56] <hannesw> i know in the end it's all merged together, i just would prefer to have it all together in the svn tree
[13:57] <hannesw> making a release is really really hard - have to update all svn external references to the release tag of the external package...
[13:57] <hannesw> plus it helps developers who work on the svn tree to actually use that code.

 

 

In the channel now:

Logs by date: