Hopbot log for 2007-06-27 - Helma IRC channel: #helma on irc.freenode.net
2007-06-27:
[9:06] <fab_> hi[9:07] <zumbrunn> hi fab_
[9:09] <fab_> do you know if there is a "default action" handler, which is used if no child objects match? i could not find such a thing in the documentation
[9:11] <zumbrunn> http://helma.zumbrunn.net/reference/HopObject.html#getChildElement ?
[9:12] <zumbrunn> notfound_action ?
[9:14] <zumbrunn> there is a notfound property you can define: http://helma.org/docs/guide/properties/listall/
[9:14] <fab_> maybe i am using it wrong, but if i define notfound_action, it is only called when i access /blabla/notfound and not when i access /blabla/notexisting
[9:15] <zumbrunn> then you are using it wrong
[9:15] <fab_> ;)
[9:15] <zumbrunn> where did you define it?
[9:16] <zumbrunn> (which prototype)
[9:16] <fab_> i better explain what i try to accomplish: it should be some kind of mini-cms. if a sub-page does not exist, it should show an "create page" dialog
[9:17] <fab_> (the pages should be hierarchical)
[9:17] <fab_> not in the root prototype, but the prototype of the "page" object
[9:18] <zumbrunn> ok... so you have a prototype called "Page"
[9:18] <zumbrunn> and /blabla/ is a page object?
[9:18] <fab_> yes
[9:19] <zumbrunn> and notfound_action or a notfound.hac is defined inside of Page
[9:19] <zumbrunn> ?
[9:19] <fab_> yes, i defined notfound_action
[9:19] <fab_> it works if i call /blabla/notfound
[9:20] <zumbrunn> does it work if you define the notfound_action inside the HopObject prototype instead?
[9:22] <zumbrunn> did you set the notfound property in app.properties or server.properties?
[9:22] <fab_> it works if defined for HopObject
[9:22] <fab_> no, i didnt define it in app or server properties
[9:23] <fab_> but if it is defined in HopObject, one can not easily react according to the parent object
[9:23] <fab_> the mini-cms is only a small part of the page, and the other parts should not allow creating subpages
[9:24] <zumbrunn> hmm, and /blabla/ really is a Page object, right?
[9:24] <fab_> yes
[9:24] <zumbrunn> and you really had defined the notfound action in Page?
[9:24] <fab_> really, i swear! :)
[9:24] <zumbrunn> I would have expected that that should work
[9:27] <zumbrunn> ok, I think this is not a bug, actually
[9:27] <fab_> are you involved in helma development?
[9:27] <fab_> your page is linked from the helma.org documentation
[9:27] <zumbrunn> more in the helma project
[9:27] <zumbrunn> not the java core of helm itself
[9:29] <fab_> how can i work around it, if its not a bug?
[9:29] <zumbrunn> ok, I think it is a bug, actually
[9:29] <zumbrunn> having a hard time making up my mind ;-)
[9:30] <zumbrunn> what's the value of "this" inside the notfound action?
[9:30] <zumbrunn> if "this" is blabla, you could check if it's prototype is Page
[9:31] <fab_> i can only tell for the HopObject not_found action, there it is of type Root
[9:31] <fab_> which seems wrong
[9:41] <fab_> String notFoundAction = app.props.getProperty("notfound", "notfound");
[9:41] <fab_> currentElement = root;
[9:41] <fab_> action = getAction(currentElement, notFoundAction, req);
[9:42] <fab_> this is from the RequestEvalutator class. currentElement is always set to the root element
[9:42] <zumbrunn> ok, I agree this is probably not a great "feature"
[9:43] <zumbrunn> not sure why we shouldn't go for the parent object instead
[9:44] <zumbrunn> I suggest you bring this up on the mailing list to see what Hannes says
[9:44] <fab_> ok, i suppose the dev list?
[9:44] <zumbrunn> that's always a bit difficult to decide
[9:44] <zumbrunn> it doesn't really matter
[9:45] <zumbrunn> both subscriber lists are almost identical
[9:45] <fab_> ok
[9:59] <zumbrunn> what you can do as a workaround is to dissect the req.path value
[9:59] <zumbrunn> but I agree that's ugly
[10:01] <fab_> yes, that would be possible, but it is not very urgent, so i'll wait for the response on the ml
[10:01] <zumbrunn> ok :-)
[10:07] <zumbrunn> in http://adele.helma.org/download/helma/documentation/documentation.html#GuideResponses Michi writes...
[10:07] <zumbrunn> "It is possible to catch such 404 by specifying a special notfound-action"
[10:07] <zumbrunn> "It should be noted, that it is even possible to define separate notfound_actions for each prototype"
[10:11] <fab_> this is strange
[10:11] <fab_> since the code above is the only place i found "notfound" in
[10:12] <zumbrunn> maybe the behavior was (accidentally) changed at one point
[12:30] <zumbrunn> fab_, since as Hannes pointed out, path still contains the resolved portion of the path, you could get the behavior you want by beginning the notfound action in Root with the following...
[12:30] <zumbrunn> var notfound = path[path.length-1].notfound_action;
[12:30] <zumbrunn> if (notfound && notfound != arguments.callee) { notfound(); return; }