cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Larson <>
Subject Re: [CForms] Repeater is not a ContainerWidget?
Date Mon, 03 May 2004 18:57:21 GMT
We can solve this container issue by pulling in a couple ideas:
  ReiserFS: Every file can also be a directory.
  Gnu-Hurd: Hierarchial filesystem translators.

Translated this is:
  (1) Every widget can also be a container.
  (2) We navigate a WidgetSystem instead of navigating widgets,
      which calls back to the widgets to allow them to add their
      own semantics and present their own views (database-like
      query-views, not template-views) of their "children".

Why would we want any widget to also be able to be a container?
  Well, what does containment imply right now?
      Records logical relationships.
      Adds split/merge semantics.
      Disambiguates parameter names with another "<name>."
      Maintains relative positioning/sort order
      Enforces naming (e.g. repeater row names must be #'s)
      Quarantines dynamically created and destroyed widgets.
  And what do we gain by extending this to all widgets?
    Control of access, permissions, and access logging.
    Use of child widgets as attributes of the containing widget.

(2) What would indirect access via a WidgetSystem win us?
  Generic ways to enforce:
    Access rights/permissions
    Logging of various types of accesses.
    Read/write locking.
    Control over access to widgets' type-specific ioctl's ;)

Widgets would reside in a WidgetSystem and navigation would be
performed by negotiating with the WidgetSystem, which may call
back to the widgets for rights, special semantics, views, etc.
For example, the WidgetSystem could be made smart to understand
that some widget collections are ordered and for these support
positional inserts.

The main problem seems to be how to write java ioctl calls to
the widgets...

--Tim Larson

View raw message