RE: AW: AW: [CFCDev] Validation

[Nando]

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. 

 

##

##