[dev] "Divot" idea

[Jan Schneider]

Zitat von "Jason M. Felice" <jfelice at cronosys.com>:

> 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.

This is how PHP serializing works by default.

> 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.

Jan.

-- 
Do you need professional PHP or Horde consulting?
http://horde.org/consulting/