-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]On Behalf Of Tim Van Der Hulst
Sent: Thursday, November 25, 2004 1:03 AM
To: [EMAIL PROTECTED]
Subject: RE: AW: AW: [CFCDev] Validation

Hi Nando, losing me here a bit..
 
I'm not. I'm using a seperate class to render the content blocks in html.
 
so ur content blocks stored in memory prior to output. correct?
[Nando] 
Yes, DisplayContent is instantiated with a factory and is persisted in app scope. 
 
The content types all have gateways that handle the front end.
 
By gateway you mean a subclass of ur content class or what? 
[Nando] 
No. Each content type, like Text, has a DAO and a Gateway - the gateway returns queries. 
 
So how are you content blocks being arranged??
[Nando] 
Templates. Each template has a method in a ContentContainerManager that defines the ContentContainer and has a .cfm that places the cointainers in a spatial arrangement on the page, or at least part of the page.
 
Thanks
 
TiM
 
-----Original Message-----
From: Nando [mailto:[EMAIL PROTECTED]
Sent: Thursday, 25 November 2004 12:41 p.m.
To: [EMAIL PROTECTED]
Subject: RE: AW: AW: [CFCDev] Validation

I'm not. I'm using a seperate class to render the content blocks in html. The content types all have gateways that handle the front end. A PageDisplayManager pulls all the pieces together, content container definitions for the page, gateways, rendering - and a small, insignificant function in the middle of it, getContent(), delivers a stucture of rendered content blocks to the page.
 
The app uses fusebox as a skeleton, but it could be easily ported to Mach-ii at this point, as nearly everything but the barebones layout and display files are abstracted to cfc's.
 
 
 -----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]On Behalf Of Tim Van Der Hulst
Sent: Wednesday, November 24, 2004 11:49 PM
To: [EMAIL PROTECTED]
Subject: RE: AW: AW: [CFCDev] Validation

Nando can you explain how you are using these classes for your view layer?
eg do your Content, ContentContainer classes handle layout/presentation code, eg CSS.
 
Any further thoughts on programatic GUI layout in general much appreciated.
(Currently hacking together a couple of layout tags but really think someone else should have done this already)
 
thanks,
 
TiM
 
-----Original Message-----
From: Nando [mailto:[EMAIL PROTECTED]
Sent: Thursday, 25 November 2004 11:35 a.m.
To: [EMAIL PROTECTED]
Subject: RE: AW: AW: [CFCDev] Validation

I'd be a little careful here. :) It all depends on whether you're using the concept "page element" to refer to a container that locates the element on a page (that would be composition!) or as a generalization of a content type (that would be inheritance). It's also possible that you're mixing the two things together in your mind.
 
What i wound up doing after a lot of trial and a lot of error is to create 2 classes, Content, and ContentContainer. In practice, Text, Image, etc all extend Content, and Content just basically deals with ContentContainer for Text, Image, etc - that functionality is abstracted to Content.
 
Sounds a little complicated, and i certainly tried to get around that complication by trying to reduce the 2 into one class, but it never worked. In practice, it turned out to be a lot simplier and cleaner to use 2 classes than i would have thought. My advice, if "page element" is meant to be a container for a type of content, that's composition. If you wanna abstract something to a supertype, do that AFTER you get your container working using composition. It's easy to be "deceived" with has-a / is-a if you don't look deeply enough at the element of responsibility in an object.
 
:) nando
 
I'm not sure I understand why this isn't an "is-a" relationship.  The basic component is called a PageElement, and all of the classes that extend are PageElements.  For example, an "image is a page element" and a "text block is a page element", is this too general of a way to use inheritance?  An element must be serializable, deserializable, and must have a display() method. 
 

##

##

##

##

Reply via email to