On Mon, Jan 31, 2011 at 12:37, Leslie P. Polzer <[email protected]> wrote:
> On Jan 31, 11:21 am, Slobodan Milnović <[email protected]>
> wrote:
>> On Mon, Jan 31, 2011 at 10:27, Leslie P. Polzer <[email protected]>
>> wrote:
>>
>> > What do you think is the best way to proceed with this?
>>
>> I understand that I'm probably pain in the ass,
>
> Haha, no. It's good that you're asking questions.
>
> But we need to find a way to make your learning process as effective
> as possible, so I'm trying not to just feed you customized code. And
> that seems to be your goal as well.
I have yet to finish reading AMOP by Kiczales, Riveres and Bobrow and
Object-Oriented Common Lisp by Slade, it is obvious that without
better understanding of CLOS I'll just keep on hitting the wall. But
for now, I'd just like to have something that works. And yes, like the
meme "feed them fish and you have fed them for a day, teach them to
fish and you have helped them feed themselves for their entire life"
:-) I want to really understand what is going on. Simple copy&paste
can get you just so far, after that you keep depending on others
without actually accomplishing anything.
>> I'd really like to understand what is happening in your example and
>> why. :-) For starters, I still don't understand why I can't use
>> default login and navigation widgets that come with weblocks?
>
> Because out of the box the login widget relies on a flow which in turn
> triggers a navigation-related issue (which I've talked about in length
> somewhere else).
Ok, I'm starting to understand this issue, I think. It is connected
with the AJAX and the way weblocks knows (or doesn't) when is
something happening on the browser side.
>> Ok, so :user-fn by default receives an result from authenticatedp. In
>> that case, I don't understand why in your example have you used (f0
>> (webapp-session-value 'user)), why would you have to set up additional
>> key in webapp-session-value?
>
> There's no setter pendant for authenticatedp. So to make sure that the
> example works I rely on my own. I should probably use
> weblocks:*authentication-key* instead. But in the end this seems to be
> a moot point for a simple example.
I see. I have been trying to use *authentication-key* in my first
attempt at the login widget, before I have started this thread, and I
have passed my user object to it. My thinking was that since it was an
*authentication-key* why not just send it the user object that has the
user data for the user that has been authenticated. It seemed logical
somehow. :-)
>> :login-widget defines what widget will be used for login? Do I put in
>> there something like
>> :initform 'login
>> or my login widget that has my parameters (username instead of e-mail
>> as the login slot)?
>
> None of it. As a user of this class you don't need to set this slot at
> all. It's just for storing the login widget after it has been created.
> We could also store it in the children slot to make it a bit more
> intuitive. So it's just for keeping state.
I see. These are just generic definitions and only later on when I
actually make an instance of the widget, I actually redefine the
widget and give it my functions. So, which one should I use in my
case, login-widget or login-widget-generator? I guess the first one if
I already have my own login widget with defined :on-login and
:on-success and stuff, and login-widget-generator if I just want to do
"on the spot" simple login widget or just some login function?
>> If I do that, then I guess I could put
>> login-widget-generator :initform nil ?
>
> No, you want to write your own generator function that returns your
> custom login widget. It will be called to initialize the `login-
> widget' slot for the first time.
Something like this then?
(defun my-login (something something)
(make-instance 'my-login-widget
:view
'login-form-view
:on-login
'authenticate-user
:on-success
(this one puzzles me, I have tried to use it in
some sense, but I'd get various blank screens)))
:login-widget-generator 'my-login
What about nested navigation - submenus?
>> I don't get exact specifics, but I do get that "get-widget-for-tokens"
>> parses uri. I don't know why you need it, but ok.
>
> We need it to get the actual widget that we display after the user has
> been authenticated.
Ok, I see. There in the weblocks is an list of active widgets, that
are in some way (I have seen the code but still have very little
understanding of the underlying mechanism) defined with the URI, so
the URI request is beeing parsed, and using the result the appropriate
widget is selected.
>> Like I said before, I still don't understand the need for
>> redefining navigation widget.
>
> The flow explanation I've already given, but there's another reason.
> This way of doing login is way more intuitive actually because it
> works in the line of the URI dispatch. You can just think of it as a
> guard that says "What's the password?" before it gives access to the
> actual widget tree (as determined by navigation dispatch) behind it.
> With the additional convenience that the guard remembers your face
> after you've given it the password once (for the duration of the
> session). I hope this analogy helps you a bit to understand how this
> works.
Yes, it does, thanks. I'll still have to study the actual implemention details.
>> I have tried
>> putting there my login widget, but there is an lack of understanding
>> on my side, so it doesn't work...
>
> How did you try to put it there? I suppose the problem is your
> misunderstanding about the `login-widget' slot, as explained above.
I've tried it this way, but then I would get the error
"UNDEFINED-FUNCTION: The function VTS::LOGIN-MAYBE is undefined."
http://paste.lisp.org/display/118899#3
>> I don't know yet how to debug or at least do a step trace into
>> sbcl threads.
>
> Hint: #'sb-thread:release-foreground.
Thanks, I'll check it.
--
You received this message because you are subscribed to the Google Groups
"weblocks" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/weblocks?hl=en.
