Duplicate widget children problem

[radisb]

I think there should be a check and a kind of handling (removal?) of duplicates in the widgets argument of 

(defgeneric (setf widget-children) (widgets obj &optional type).

Currently there is not any such check and so someone could do:

(let ((dup (make-dup-widget)))

(make-instance 'composite

:widgets (list dup dup)))

Since the above is accepted as it is , the first page load renders 2 widgets with same id, but any subsequent ajax request always renders the first one

because firstly, mark-dirty does this:

 ...

  (unless (widget-dirty-p w)

     (push w *dirty-widgets*)

 ...

and widget-dirty-p will see the same object,

and secondly even if somehow we pushed dup twice into *dirty-widgets* there would be problem in the ajax response content handling by JS.

Unless I am missing something, this should be resolved but i am not sure about plain removal of the duplicate. Any suggestions?

Could there be a legit use case of one widget being rendered twice in different html places? And even if there is I am not sure if it could be implemented by same widget rendered twice (in html space).

Any suggestions? 

[Nandan Bagchee]

I dont think there is a case for duplicate widgets in the sense of dom
ids being identical if I understand you correctly.

Suppose you have a complicated-wodget you can simply say

(let ((a (make-instance 'complicated)
(b (make-instance 'complicated)))
(make-instance 'composite
:widgets (list a b)))

And they end up w differing dom ids. It's a great way to reuse
functionality and a killer feature of weblock's widget oriented
approach imho.

Sent from my iPad

> --
> You received this message because you are subscribed to the Google Groups "weblocks" group.
> To post to this group, send email to webl...@googlegroups.com.
> To unsubscribe from this group, send email to weblocks+u...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/weblocks?hl=en.

[radisb]

So where do you think 

(make-instance 'composite

:widgets (list dup dup))

unwanted effect should be fixed? In composite definition or in defgeneric (setf widget-children) ?

[Leslie P. Polzer]

I wonder how you would end up putting a duplicate object into a children
list; never fell into that pit. But I guess it might be different for
other people, and I'm very much in favor for checking things to prevent
people from shooting themselves in the foot all too easily.

Comments and questions:

* composite is deprecated, just use (make-instance 'widget :children (...))

* what do you mean by "in composite definition"?

* not taking your answer to the above into account: it should probably
go into (setf widget-children)

Hope that helps. :) Thanks for your interest in Weblocks!

Leslie

[radisb]

> I wonder how you would end up putting a duplicate object into a children
> list; never fell into that pit.

I fell into that pit by trying the following: I wanted to present the one widget twice on the client by "splitting-mirroring" its visual behaviour in the same page but in two different locations (Start and end of the page). For example I would like for all my pages to render a widget as header and as footer. It should be the same widget because it is the same data I want to present. I just want to present it in 2 locations. So why creating another widget and having to synchronise its contents?

 

Would that be a legit case?

>  * composite is deprecated, just use (make-instance 'widget :children (...))

Ah didnt know that.

>  * what do you mean by "in composite definition"?

I meant check for duplicate children in the code for the composite widget, but it was a dump suggestion anyway. Should be handled in lowest possile level.

>  * not taking your answer to the above into account: it should probably

    go into (setf widget-children)

Absolutely. 

> Hope that helps. :) Thanks for your interest in Weblocks!

No, thank you and the other contributors for the framework :)

[Leslie P. Polzer]

radisb wrote:
>> I wonder how you would end up putting a duplicate object into a children
>> list; never fell into that pit.
>
> I fell into that pit by trying the following: I wanted to present the one
> widget twice on the client by "splitting-mirroring" its visual behaviour in
> the same page but in two different locations (Start and end of the page).
> For example I would like for all my pages to render a widget as header and
> as footer. It should be the same widget because it is the same data I want
> to present. I just want to present it in 2 locations. So why creating
> another widget and having to synchronise its contents?
>
> Would that be a legit case?

It seems to be, but there are some issues you'll have to take care
of. In this case we somehow need to ensure that DOM ids are unique,
and be careful to sync the state of the other copies when one of
them is updated (marked dirty).

So I guess it could be done, but it will need a couple of hours to make
it work correctly (and not break anything else).

Leslie