On Sat, Apr 11, 2009 at 03:31:07AM -0700, Saikat Chakrabarti wrote: > > (defgeneric render-presentation (obj value) ...) > > > > That seems too limited, I think we also need to be able to specialize > > on the view, the form widget and the view field name. > > The thing is, at that abstraction level, the presentation has no > knowledge of the view field name or the widget that is using this > presentation. I suppose we could have it take in a view field name or > widget, but is there an example of a scenario where you could see > rendering the presentation differently based on the field or the > widget using the presentation? I just didn't want to start having > widget rendering and field rendering getting mixed into the logic of > presentation rendering.
We can keep it like this and see whether it's enough. > > (validator > > :initform nil > > :initarg :validator > > :accessor stateful-field-validator > > > > Don't forget that it should be possible to specify multiple > > validators. > > I hadn't thought of that - you were thinking this should be allowed at > the field level as well as the view level? We should have validation both at the view and field level, and for both it should be possible to specify multiple validators. This is the current implementation. > > (data-class > > :initform nil > > :initarg :data > > :accessor stateful-view-data-class > > > > Why not always derive the data class store via CLASS-STORE? > > It would be my preference to do that (you mean by doing (object-store > data-object)? If not, I'm not entirely sure what you mean). Well, yes -- I guess #'object-store =~ (compose #'class-store #'class-of) > I put that there because it seemed like dataform currently keeps around a > class-store, and I wasn't sure if there was a use case for this (maybe > having the same data-object in multiple stores?). If there isn't a > reason for this, I'll get rid of it. The dataform needs to have a data class because it supports creating new objects if it is not given any. So this is a special requirement of dataform, not of views in general. > > ;; This error checking looks a bit stupid. > > (when (slot-in-object-p 'data-object view-data) > > (error "Tried to map a data-model to a view when the data-model has > > a slot called > > 'data-object', which is reserved.")) > > (when (slot-in-object-p 'data-class view-data) > > (error "Tried to map a data-model to a view when the data-model has > > a slot called > > 'data-class', which is reserved.")) > > (when (slot-in-object-p 'validator view-data) > > (error "Tried to map a data-model to a view when the data-model has > > a slot called > > 'validator', which is reserved.")) > > > > Yes, why not rely on packages here and allow these slot names? > > > > The reason I'm not just relying on packages is because the mapping > being done in the views is package agnostic. So, for example, if you > create a view with slots called "name, address" in a package called > "test" and then your data object that you are tying to the view is in > a package called "test1", slots called "name" and "address" on the > data object will still be mapped to the name/address slots in the > view. Thus, without these checks, if you have a data-object that has > a slot called "validator" in any package, and you have currently not > assigned anything to the validator slot for the view, the > initialize-instance will create a default field for the validator slot > for the view. This is why slot-in-object-p forces the slot names to a > string before doing the comparison. > > I could rely on packages here, but it seemed too constraining to > assume that data objects and their corresponding views will always be > in the same package, but I don't have a very strong opinion on that. There's no need to assume that. If you like to keep your models in a separate package you just need to export the view field name symbols from it and make the ui package use it. > >> 5) I started on something to allow creating presentations on the fly > >> using lambdas, but was foiled because I'm not sure how to tell if a > >> form presentation created in a lambda is a form presentation (this > >> seems necessary in parse-fields-into-view) - any ideas on this? > > > > I don't think I get it. Do you mean a function that returns a > > presentation or a function the implements/acts as a presentation? > > > > I meant a function that implements/acts as a presentation. So > something like (lambda (value) (with-html (:input :value value :name > "test")) could just be dropped into the :present-as for a field (I > have some commented out code in presentation.lisp that would handle > this fine - it's more the parsing of lambda presentations that are > form fields that tripped me up). Why not just make the compiler take the lambda and use it to create a FUNCALL-PRESENTATION? > I'm not sure if I understand you. Would it not be possible to edit a > large object in chunks if the view for the object was created from a > bunch of mixed in views? The widget still has full control over where > to render each field of the views and its mixed in views. Or do you > mean something else? I think my question is moot considering that view fields can hold their own data now and thus are decoupled from the underlying data object. Leslie --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
