Column order

[Leslie P. Polzer]

Is there a possibility for setting the column order of a table view?

This would be useful.

[Vyacheslav Akhmechet]

On 4/27/08, Leslie P. Polzer <leslie...@gmx.net> wrote:
> Is there a possibility for setting the column order of a table view?

Sure, just reorder the way they're declared:

(defview foo (...)
name age)

vs.

(defview bar (...)
age name)

At the moment a dervied view cannot declaratively change the order of
fields defined in the base view. This is a limitation that eventually
needs to be solved.

[Leslie P. Polzer]

On Apr 27, 7:20 pm, "Vyacheslav Akhmechet" <coffee...@gmail.com>
wrote:

> At the moment a dervied view cannot declaratively change the order of
> fields defined in the base view. This is a limitation that eventually
> needs to be solved.

Are custom readers handled in a special way, too?

For example, in

(defview ...
(a ...)
(b ...)
(c :reader #'foo))

C is always the last column, regardless of where it occurs in the
DEFVIEW form.

Leslie

[Vyacheslav Akhmechet]

On 4/28/08, Leslie P. Polzer <leslie...@gmx.net> wrote:
> Are custom readers handled in a special way, too?

No, there is nothing special about custom readers. This works as
expected for me.

I suspect this has something to do with the way you're using view
inheritance. If you have a base view (including a scaffold) like this:

(defview base (...)
(a ...)
(b ...)
(c ...))

And then you derive like this:

(defview derived (:inherits-from base)
(foo :reader "test")
(b ...))

The field FOO will be placed at the end. This is because the merge
algorithm will interpret field B in the derived view as a field that
"overrides" the one in base view. So, it will first place field A,
then the derived B, then C, and finally the derived FOO.

There is no way at the moment for a derived view to place fields
before the ones defined in a base view. It's a limitation that will
need to be solved.

[Leslie P. Polzer]

On Apr 28, 7:12 pm, "Vyacheslav Akhmechet" <coffee...@gmail.com>
wrote:

> There is no way at the moment for a derived view to place fields
> before the ones defined in a base view. It's a limitation that will
> need to be solved.

What I'm doing is this:

(defclass table*-view (table-view)
())

(defclass table*-view-field (table-view-field)
() (:default-initargs :hidep t)) ; easier for maintenance/
prototyping

(defclass table*-scaffold (table-scaffold)
())

(defview my-grid-view (:type table* :inherit-from '(:scaffold zork))
(field1 :hidep nil)
; ...
(field2 :hidep nil :label "foo" :reader #'zoo)
)

and field2 always shows up last regardless of its position in the
declaration.

[Vyacheslav Akhmechet]

On 4/30/08, Leslie P. Polzer <leslie...@gmx.net> wrote:
> What I'm doing is this:
>

> (defview my-grid-view (:type table* :inherit-from '(:scaffold zork))
> (field1 :hidep nil)
> ; ...
> (field2 :hidep nil :label "foo" :reader #'zoo))
>
> and field2 always shows up last regardless of its position in the
> declaration.

Could you give an example zork?

[Leslie P. Polzer]

> Could you give an example zork?

The problem indeed seems to lie in the scaffold class definition, as
it works correctly with a simple mock-up

The class in question has a large number of slots itself and a few
mixins:

(defpclass player (attributes-mixin equipment-mixin preferences-mixin)
...)

The fields declared in the view are not provided by the mixins,
though.
I can send you the whole class in private if you wish.

Leslie

[Vyacheslav Akhmechet]

On 4/30/08, Leslie P. Polzer <leslie...@gmx.net> wrote:

> The problem indeed seems to lie in the scaffold class definition, as
> it works correctly with a simple mock-up

The fields are determined by calling class-visible-slots (which is a
facade for class-visible-slots-impl), and the order should be the same
as the order returned by these functions (defined in
src/views/view/scaffold.lisp:96). Could you check what they return for
your class? Do they give a correct slot order?

This is somewhat difficult to track down without a self-contained
example, so I'm just trying to narrow done where the problem comes
from.

[Leslie P. Polzer]

On Apr 30, 10:02 pm, "Vyacheslav Akhmechet" <coffee...@gmail.com>
wrote:
> On 4/30/08, Leslie P. Polzer <leslie.pol...@gmx.net> wrote:> The problem indeed seems to lie in the scaffold class definition, as

> > it works correctly with a simple mock-up
>
> The fields are determined by calling class-visible-slots (which is a
> facade for class-visible-slots-impl), and the order should be the same
> as the order returned by these functions (defined in
> src/views/view/scaffold.lisp:96). Could you check what they return for
> your class? Do they give a correct slot order?

All involved classes are Elephant persistent classes; this gives:

(#<SB-MOP:STANDARD-DIRECT-SLOT-DEFINITION ELEPHANT::%OID>
#<SB-MOP:STANDARD-DIRECT-SLOT-DEFINITION ELEPHANT::DBCONNECTION-SPEC-
PST>
... slots of ATTRIBUTES-MIXIN ...
#<SB-MOP:STANDARD-DIRECT-SLOT-DEFINITION ELEPHANT::%OID>
#<SB-MOP:STANDARD-DIRECT-SLOT-DEFINITION ELEPHANT::DBCONNECTION-SPEC-
PST>
... slots of EQUIPMENT-MIXIN ...
#<SB-MOP:STANDARD-DIRECT-SLOT-DEFINITION ELEPHANT::%OID>
#<SB-MOP:STANDARD-DIRECT-SLOT-DEFINITION ELEPHANT::DBCONNECTION-SPEC-
PST>
... slots of PREFERENCES-MIXIN ...
... slots of PLAYER ...)

From what I can see the order (as per class precedence and order of
slot declaration) is correct, too.

> This is somewhat difficult to track down without a self-contained
> example, so I'm just trying to narrow done where the problem comes
> from.

If all else fails I can give you access to the whole code base.

Leslie

[Vyacheslav Akhmechet]

On 4/30/08, Leslie P. Polzer <leslie...@gmx.net> wrote:
> All involved classes are Elephant persistent classes

This is unrelated to your problem, but how do you deal with the fact
that some parts of weblocks create instances of classes that may need
to be thrown away? For example, if you click "add" on a gridedit, and
then click "cancel", you'll end up with an instance of the class in
your store that really shouldn't be there.

Could you post your elephant store code? I'd be very interested in
integrating it into weblocks.

> If all else fails I can give you access to the whole code base.

I'll try to recreate it here. Meanwhile, if you could track it down
and/or create a small self-contained example, that'd be great. If this
doesn't work, we'll move to drastic measures :)

[Leslie P. Polzer]

On Apr 30, 11:38 pm, "Vyacheslav Akhmechet" <coffee...@gmail.com>
wrote:
> On 4/30/08, Leslie P. Polzer <leslie.pol...@gmx.net> wrote:> All involved classes are Elephant persistent classes

>
> This is unrelated to your problem, but how do you deal with the fact
> that some parts of weblocks create instances of classes that may need
> to be thrown away? For example, if you click "add" on a gridedit, and
> then click "cancel", you'll end up with an instance of the class in
> your store that really shouldn't be there.

Yeah, I know about that problem.

I don't deal with the problem where it occurs so far (in an admin
backend where people
can be expected to deal with glitches like this), and if it becomes a
problem I might just
add behaviour to cancel that removes the object.

Of course it would be nice to have a general solution for this,
especially given the
fact that we have a half-baked object as soon as the user clicks on
"Add"...

> Could you post your elephant store code? I'd be very interested in
> integrating it into weblocks.

Heh, I don't have a store. I use ON-QUERY exclusively right now
and never use Weblocks persistence.

> > If all else fails I can give you access to the whole code base.
>
> I'll try to recreate it here. Meanwhile, if you could track it down
> and/or create a small self-contained example, that'd be great. If this
> doesn't work, we'll move to drastic measures :)

I'll see what I can do, thanks so far. :)

Leslie

[Leslie P. Polzer]

Seems to have nothing to do with the PLAYER class, and neither with
the view inheritance.

(defview item-form-view (:type form :inherit-from '(:scaffold
item) :persistp nil)
...
(foo :label "foo" :reader (constantly t) :writer (constantly
t) :requiredp nil)
(required-attributes :type mixin :view 'attribute-default-form-view)
(bar :label "bar" :reader (constantly t) :writer (constantly
t) :requiredp nil)
(attribute-modifiers :type mixin :view 'attribute-default-form-view)
)

shows the same behaviour, i.e. FOO and BAR get appended at the very
end.

Leslie

[Leslie P. Polzer]

Interestingly enough, this view:

(defview adventure-form-view (:type form :inherit-from '(:scaffold
adventure))
...
(duration :hidep t)
(on-complete :hidep t)

(only-races :present-as (checkboxes :choices (lambda (obj) (declare
(ignore obj))
*valid-races*))
:parse-as checkboxes)


(blocking-text :requiredp t :present-as textarea :writer (make-slot-
writer 'blocking-text))
(success-text :requiredp t :present-as textarea :writer (make-slot-
writer 'success-text))
(failure-text :requiredp t :present-as textarea :writer (make-slot-
writer 'failure-text))
)

renders ONLY-RACES between BLOCKING-TEXT and SUCCESS-TEXT. %)

[Vyacheslav Akhmechet]

Leslie,

Did you get anywhere with the column order problem?

[o_z]

воскресенье, 27 апреля 2008 г., 12:42:48 UTC+3 пользователь Leslie P. Polzer написал:

Is there a possibility for setting the column order of a table view?

This would be useful.

I have implemented some kind of extension for it

https://gist.github.com/html/4444927