RE: AW: AW: [CFCDev] Validation

[Tim Van Der Hulst]

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?

 

The content types all have gateways that handle the front end.

 

By gateway you mean a subclass of ur content class or what? 

 

So how are you content blocks being arranged??

 

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. 

 

##

##

##

##