Here is a cleaned up verios of the log, I hope it helps to explain.
- 11:41 -
nunb: did you get the login flow working?
nunb:
http://paste.lisp.org/+1XIN
harag: I am looking at it now
harag: If I use yield in the on-success the code wont compile it says
that yield does not exist
harag: nunb: is f_% an actual function or must I replace it with my own
function?
lpolzer: f_% is a macro from f-underscore
lpolzer: you need to do an explicit replace in on-success
lpolzer: like :on-success (lambda (obj &rest args) (do-widget obj
(make-replacement-widget)))
harag: thanx
harag: lpolzer: just for curiosites sake why does the compiler not see
the yield in the on-success declaration/code
lpolzer: yield is expanded by with-flow
lpolzer: if there's no with-flow around it, it won't get expanded
harag: lpolzer: your version of on-success does not work either
lpolzer: please paste what you have now
harag: k
harag: I have two version with two different results
nunb: harag: alternatively you can try the version with the flag that i
pasted (it's the last one)
nunb: I forgot that yield converts to do-widget only inside with-flow
harag: nunb: the last one works for me
harag: but I need to understand how to use weblocks ...cleanly
harag:
http://paste.lisp.org/+1XIN/1
harag: lpolzer: there it is with both versions of layout-main page
lpolzer: UNBOUND-SLOT: The slot WEBLOCKS::BASE-URI is unbound in the
object #<NAVIGATION MAIN-MENU>
lpolzer: are you running the latest dev version?
harag: lpolzer: yes
harag: the one I downloaded the other night
harag: lpolzer: did you find out why your example of login did not work
with my code?
harag: I would prefer tho use that model..like event programming...it
will make my code easier to understand for those the newbies I am
getting some time
lpolzer: harag, I did a bit of research on the unbound slot problem
lpolzer: I thought I fixed it some months ago
lpolzer: but I didn't
lpolzer:
http://bitbucket.org/S11001001/weblocks-dev/issue/6/change-in-navigation-structure-is-not-considered-on-ajax
lpolzer: in this ticket there's a link to the original discussion
lpolzer: you can read this if you want to know what the problem is
about.
harag: ok I will read it
lpolzer: I'd prefer not to fix this right now (as I did back then)
because it will likely take me at least two hours quality time.
lpolzer: the main thing is: right now I will set aside time for broken
functionality that is absolutely needed by some weblocks user.
lpolzer: but this isn't one of them I guess
lpolzer: it's not hard to work around it.
lpolzer: for example by issuing a full page reload.
- 21:48 -
harag: lpolzer: ok if I understand it correctly it is because a new page
is loaded from an ajax request (on-success) or is it just because it is
going to a new navigation(widget?) that is the issue ...and if it is the
navigation what makes it special?
lpolzer: no new page is being loaded, and that's the problem
harag: so do you loose context then?
lpolzer: a navigation has a slot named BASE-URI
lpolzer: this slot is configured on normal requests only (based on the
request uri)
lpolzer: so when you insert a new navigation into the widget tree in an
ajax req
lpolzer: it doesn't know where it will fit in
lpolzer: thus base-uri is reported as unbound
lpolzer: the main problem behind this is that an unconfigured nav won't
know what child to display
harag: what do you mean by unconfigred...not called yet?
harag: so it does not have a context ie root to build in?
- 21:53 -
lpolzer: as I noted in the original thread we should either reconfigure
the tree on every ajax request (a bit expensive and unnecessary in most
cases)
lpolzer: or reconfigure it when we detect that a new navigation/selector
has entered the tree (optimal solution but requires some fiddling)
lpolzer: it works like this
lpolzer: we have a request uri, say /foo/bar/qux
lpolzer: no, let's make that just /foo
lpolzer: and one navigation at the toplevel that has widgets for tokens
foo, foo2, foo3
lpolzer: on a normal request to /foo the navigation will be told that
its token is "foo"
harag: thanx for taking the time to explain this by the way...
lpolzer: yw
lpolzer: so it knows that it must display the widget matching token
"foo"
lpolzer: on an ajax request this doesn't happen at all
lpolzer: not a problem if the nav is already configured
lpolzer: but if it is newly born in the ajax request itself, it is at a
loss on what widget to display
harag: so the ajax call expects to come back to its parent structure ..?
harag: is there a way to configre the navigation without showing it
before you sue it?
lpolzer: no, that won't work
lpolzer: a navigation will be configured only if it's part of the tree.
harag: can a navigation (or views like the grid) be hidden in a page and
then just activated displayed when needed? like hiding a div
lpolzer: you could write a custom navigation that does that
lpolzer: but I don't recommend it
lpolzer: it's way easier to just do a redirect (after the login in your
case)
harag: and this is only a prolem with navigation widgets ?
- 22:04 -
lpolzer: yes
lpolzer: well, with all selectors
lpolzer: but I guess you could be a bit fuzzy and just say all
"navigations"
harag: so if I loaded a normal page from on-success it would not be a
problem something with no "navigations" or does stuff like selecting an
item in the grid fall under the same heading?
lpolzer: no, only selectors are affected.
harag: ok thanx ...
lpolzer: the problem occurs only when a selector is inserted into the
tree in an ajax request
lpolzer: these three conditions must be met.