[dev] "Divot" idea

[Jason M. Felice]

Quoting Jan Schneider <jan at horde.org>:

> Zitat von "Jason M. Felice" <jfelice at cronosys.com>:
>
>> Attached is an incomplete but illustrative example of a concept that
>> I'm working on for a possible new PEAR library tenatively called
>> "Divot."  A divot is sort of an HTML widget... it could be a form
>> control, or a form, or a reusable spin component.
>>
>> The idea is to be able to automagically dispatch events back to their
>> respective objects, and automatically handle Ajax callbacks, and
>> still have all the code localized to the thing we are working with.
>> And still be lightweight.
>>
>> Let me know what you think.  I'm only attached to the basic concept,
>> I know there are a lot of things with this idea which could use some
>> work.  Objections of any sort are always welcome.
>
> I like the general idea of having encapsulated widgets. Sort of what we
> started with the blocks, but much more flexible. But I don't understand
> why you would use the memento pattern. From what I can see where you
> are heading at, serializing/deserializing the Divot objects would be
> the appropriate action to restore the object state in the next request.

Thanks for the feedback--I want to get really clear on the concepts 
involved in this thing before I do the "real" code.

I thought about it some more (actually, as I was replying--I kept it 
below if you are interested in the creaky internal workings of my 
brain), and it looks like using serialization is the best bet.

I can see this might simplify some other stuff, so I'll see about 
posting revised "concept code" later.

-Jason

Concern One:

I was contemplating dispatching events to container-type divots (a useful
example--a date edit control consisting of month/day/year selectors).  If we
use serialize we must either:

a) Serialize the sub-objects with the parent, if the parent references them.
b) Manage parent/children relationships outside of the object, (perhaps
    using an array of "singleton keys")  So the parent indirectly references
    children.
  Right now, I'm assuming the singleton key by itself is how we get back to the
object for dispatch.  If we serialize the children with the parent, then we
need to have a root key with a path; otherwise, we'd have two copies of the
serialized object (the one associated with the singleton key and the one
associated with the parent).

I see now that we could use the indirect reference method for child 
divots successfully with serialize()/unserialize().  As I think about 
it now, that should even make things more light-weight, because we 
could create some divot in the middle of the heirarchy directly to 
handle an event, and re-instantiate parents and children on demand.

Concern Two:
Will need to make sure we have freeze()/thaw() methods.  Not a problem.

Concern Three:
What happens if we need to reference other external objects which are 
specially constructed?

Answer: I guess that means we have to handle that in freeze()/thaw().

Conclusion: serialization() works better than get/setMemento() for this.

-- 
Jason M. Felice
Cronosys, LLC <http://www.cronosys.com>
216-221-4600 x302