From mb at bese.it Tue Nov 2 14:17:00 2004 From: mb at bese.it (Marco Baringer) Date: Tue, 02 Nov 2004 15:17:00 +0100 Subject: [Bese-devel] different tyes of components Message-ID: ucw basically has three types of components: 1) root components - these are the ones which get put in a session-frame and take of rendering the entire page. (usually by printing the html headers, a nav bar or something, delegating the real work to someone else and finally printing the footer) 2) control components - these are things like forms, navigation bars and components which control other components. generally these don't do much grahpically but have a lot o actions and greatly influence what actually gets shown to the user. 3) widgets - the parts of the user interface. the "meat" of the app. would there be any gain in seperating these three types into seperate branches of the component hierachy? i can't see any advantage as far as functionality is conscerned, but i wouldn't cost anything and may make it easier to understand cretain apps. comments? -- -Marco Ring the bells that still can ring. Forget your perfect offering. There is a crack in everything. That's how the light gets in. -Leonard Cohen From mb at bese.it Tue Nov 2 17:55:54 2004 From: mb at bese.it (Marco Baringer) Date: Tue, 02 Nov 2004 18:55:54 +0100 Subject: [Bese-devel] UCW on sbcl and cmucl Message-ID: UCW currently triggers a bug in CMUCL and SBCL where loading a compiled file with a :default-initargs defclass option causes the :default-initargs to be ignored. The temporary solution is to just use manually load (not compile) the files which contain defclass. if anyone knows if this has been fixed in recent sbcl/cmucl i'd love to hear it. -- -Marco Ring the bells that still can ring. Forget your perfect offering. There is a crack in everything. That's how the light gets in. -Leonard Cohen From mb at bese.it Wed Nov 3 16:40:59 2004 From: mb at bese.it (Marco Baringer) Date: Wed, 03 Nov 2004 17:40:59 +0100 Subject: [Bese-devel] different tyes of components References: <41883555.6030601@tech.coop> Message-ID: Drew Crampsie - Software Developer writes: > I had a defcomponent-container macro similar to what you call a 'root'. > It would set up the various things specific to a container. I never > actually used it, because it's quite unpolished. and with the new MOP > changes it's no longer relevant. even if you can't publish it i'd love to see a copy of the code, or if you could just tell me what it did which you found usefull. > I vote for branching! so it's 2 to 0. good enough. here's the new (tentative) component class hierarchy: - component - standard-component - window-component - 3column-layout - widget-component - tabbed-pane - date-picker - option-dialog - ... - container window-components will have methods for setting things like the title, stylesheets (and regular old