> The solution using RENDER-VIEW-FIELD sounds better to me... By this do you mean changing passing the :onkeyup argument to form- view-field instead of input-presentation? I guess I didn't do this because the Javascript events are properties on specific input types (and different input types have different events they can handle, and it seemed like presentations mapped to the input types and properties of presentations mapped to properties of that input type). Also, I'm not sure how I could do this in just render-view-field - becaues onKeyUp is a property on the input type, I think I have to change render-view-field-value, where the input type is being rendered?
So I guess my question is, when you say to use the render-view-field solution, do you actually mean changing render-view-field instead of render-view-field-value? Or do you mean adding the :on-keyup property to form-view-field instead of in a presentation mixin, and if so, why? Thanks, Saikat On Mar 10, 7:11 am, "Leslie P. Polzer" <[email protected]> wrote: > On Mar 10, 11:43 am, Saikat Chakrabarti <[email protected]> wrote: > > > 1) Currently, I want the events to be able to either take backquoted > > scripts that will be transformed into javascript calls made entirely > > on the client-side or a lisp function that would be called with AJAX. > > For example, if you pass `(test-fun) to on-keyup, it will just output > > that using ps* in onKeyUp for the input. I was going to do this by > > putting this transformation code in the initialize-instance of my > > event-presentation-mixin, but this led to me keeping on getting errors > > that said ("The variable HUNCHENTOOT:*SESSION* is unbound." > > " [Condition of type UNBOUND-VARIABLE]" nil). The only way I got it > > to end up working was by putting the nasty transformation code in > > render-view-field-value. It would be nice though to be able to have > > this code happen automatically in the initialize instance (so all the > > presentations using this mixin won't have to remember to call this > > transformation code) - do you have any ideas on this/know why the > > *session* variable is unbound? > > Yes, it's another symptom of the presentation singleton issue. > > The object gets instantiated at load time when no session is active. > You are calling MAKE-ACTION which needs a session. > > > 2) Is the approach I am taking similar to what you were imagining? I > > am just working with what little I know, so it is entirely likely that > > I am missing some obviously better way of doing this - it feels like I > > am ending up doing what you said I wouldn't have to do (setting up > > actions on the server side that will be marking my widget dirty and > > passing them to my on-keyup function). > > Yes, it's quite along the lines of what I had in mind. > > The idea with the mark-dirty convenience js function is mostly > orthogonal to your changes and may easily be implemented > on top of them. > > > 3) I am also not entirely sure how to pass the widget that this > > formview is part of as an argument to the function that will be callen > > on-keyup, if it is a lisp function. > > Is there a way from a form to get it's owning widget? > > Tough thing. RENDER-VIEW-FIELD would have to bind this dynamically > (like it happens with *presentation-dom-id*) as a hack. > > > Is there a way right now that you pass arguments > > to actions called using AJAX? > > Yes you need to use the JS function initiateActionWithArgs on > the client side. That way you'd need to send them DOM ID > though, and convert that into a widget on the client side. > > The solution using RENDER-VIEW-FIELD sounds better to me... --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
