I agree with your design decisions so far, especially with the
statefulness of fields.
Some first suggestions:
Please try to split up the code into multiple files, preferably
one per class. It's cumbersome to review these huge chunks of code.
(defmethod initialize-instance :around ((obj stateful-view) &key)
(let ((*current-view* obj))
(when (next-method-p)
(call-next-method))))
I didn't look it up in the spec but I guess we can rely on there
being a default initialize-instance so the check for the next method
is moot.
Why is it necessary to supply this variable to the next method(s)?
Same for *current-presentation*.
(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.
(validator
:initform nil
:initarg :validator
:accessor stateful-field-validator
Don't forget that it should be possible to specify multiple
validators.
(data-class
:initform nil
:initarg :data
:accessor stateful-view-data-class
Why not always derive the data class store via CLASS-STORE?
(declaim (inline current-view))
(defun current-view ()
*current-view*)
Why this? To provide some abstraction? You probably want a macro
here to make it SETFable too.
(defun stringified-slot-names (obj)
Is this really necessary?
;; 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?
> 2) I haven't yet fleshed out the syntax for actually defining views
> (right now, as you'll see, it's just using defclass and is clunky). I
> think eventually I want something fairly similar to how it used to be
> (like (defview view ((field-1 :parse-as input :reader (lambda
> (obj)...)))), and have the things in the defview be defaults that are
> used per instance (but overwriteable by each instance). Any thoughts
> on this?
This sounds like a good way to do it. I don't think it will require
much work to adapt the current DSL compiler to it, either.
> 3) One thing I wasn't sure about was whether views should keep state
> or not.
But in the following text you talk about view fields, not views.
Do you mean view fields above, or both?
> 4) Much of this code is not well tested/buggy, and there is a lot of
> stuff missing that the old views have (that I will add in later - for
> example, validation just returns true right now, but the stub I have
> is where validation will go) - I mostly just wanted to show off the
> diff.
Yes, very good!
> 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?
> 6) There is also a "view-alternate-version.lisp" which was a (i think
> foolish) attempt at making a way for views to be mapped on top of
> multiple models in a way that was different from just using mixed in
> views. I'm not sure if anyone sees any value to this (there is a
> better explanation at the top of the file), but I've included it for
> the curious.
View composition -- does this make it possible to edit one large
object in chunks, e.g. one slot per page?
Thanks so far, I think we're on the right way!
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
-~----------~----~----~----~------~----~------~--~---
