I think we are all dangerously close to implying a Document Model approach. Lets take a step back disassociate the relationships between a comment and an article.
In its rawest form an Article can exist entirely separate from a comment. A comment can exist without an article. A comment cannot exist on its own as by its very nature it has to belong to something. Although one could argue a Message forum is really a comment existing unto itself - but it still needs to be associated with a parent (i.e. category or discussionTopic)
The very nature of a comment can have children or siblings (even though both siblings don't know about each other).
The more I look at this entire concept the more I keep getting the feeling that something needs to draw the pieces together, whether that's a manager or an ArticleBO either way all that's being accomplished is we are shifting the goal posts (i.e. Manager gets pushed aside for ArticleBO).
Taking onboard simple old DOM, typically something "Builds" the page while each node/element/document exists separate from one another. Yet if you want to dump the entire document you would get all of its chained nodes.
How is this accomplished? In DOM its done via DocumentBuilder (from memory it's been awhile) DocumentBuilder is an instance which "has-a" a series of nodes. If you want to save a portion of those nodes, you'd transform the portion into a documentFragment, take that fragment and push it do something that can traverse it, then save each piece to their relevant places...
The point is, in order to create children within children, something has to take that request and inform the children what to do (node1 = document.createElement("TextArea"), myForm.myDivInForm.appendChild(node1); - the form and TextArea have a relationship yes as a form can still submit without a textarea, but a textarea cannot be submitted without a form. Yet the textarea can still exist on its own if need be without a form (ie DHTMl trickery).
So getting back to simple ArticleBO has-a CommentBO composition, I'm inclined to say NO, as simply put my ArticleBO is now tightly coupled to the concept of having comments. Furthermore I'm now setting a concrete relationship between Articles and Comments in that an Article cannot exist without having a comment (whether you actually add comment branches is up to you) but the _root branch still exists and logic is still there i.e. (Article.addComment())
Now in this example whats the big deal, so an array doesn't get populated wooopydooo.. And maybe has a 3 functions that never get executed if you want that article to exist without comments... That's fine and I'm also going to agree with that just saying if the comment logic were to exist in it, you now have to write something that can pick it apart and pigeonwhole it in a spot. So this could mean for every time you want a comment situation you have to write something that continues to pick it apart - vs - writing a comment in a way it looks after its own lifecycle.
If a "manager" whether it be called ArticlesBO has composition of:
Class defaultArticlesBO extends managerClass {
instance = StructNew();
instance.articles = StructNew(1);
function addArticle(articleBO) {
// StructAppend logic here.
}
function addComment(commentBO) {
// arrayappend logic here
}
function getArticle(id) {
var tmpArticle = instance.articles[id];
var aggArticleBO = new aggArticleBO();
var tmpComment = "";
aggArticleBO.setArticle(tmpArticle);
for(var i=0; i=ArrayLen(instance.articles[id]); i++) {
tmpComment = instance.articles[id].comments[i].commentsBO;
aggArticleBO.addComment(tmpComment);
}
return aggArticleBO;
}
function saveArticle(id) {
var tmpComment = "";
var tmpCommentDAO = new commentDAO();
var tmpArticleDAO = new articleDAO();
tmpArticleDAO.save(instance.articles[id]);
for(var i=0; i=ArrayLen(instance.articles[id]); i++) {
tmpComment = instance.articles[id].comments[i].commentsBO;
// could put some IsDirty() concept meaning if timestamps our out of sync etc..
// Save it..
tmpCommentDAO.save(tmpComment);
}
}
}
Now what I've done here is I've created an object specifically setup to handle the aggregation of both object types, part of the rules within this aggregated object is that I can only have 1xArticle and many Comments.
Ok, so what does this really do in the end? Well it allows us to still keep ArticleBO and CommentBO separate lives and never know about each other. It furthermore allows us to create relationships between objects (that are abstract from one another) per context in that our manager becomes our context (as in this light we want comments to be associated with an article...I'm really trying to stray away from the word interface here hehe I've never really used them so I don't want to throw that in the had in case I stuff its concept up).
aggArticleBO (it could simply be a struct aswell not really an object per say) is the spawn of your ArticlesBO, the two are tightly coupled I guess, it's a "singular" version of your articles concept. This then opens up the possibility of adding other objects into the mix while still keeping them separate. All we are doing is creating an object which marries objects together to form one uniform virtual object @ Runtime.
Now this a simple diagram of merging objects together, I'm sure with some inheritance here and generic methods you could marry the two together quite easily via one uberAggregateObject (which doesn't care about its innerChildren) and still come out unscathed. You could use the use the decorator pattern creatively here as well.. Not sure how but something in the back of my mind flagged "Decorator pattern..investigate now!" hehe.
I guess I'm thinking out loud again (concept probably will get laughed at hehe) but I thought if I impose an relationship between two objects that "Can" exist else where within the system independent of each other specifically you could find yourself not having re-use capabilities.
If you build the commentBO to have ownerDocument and parentNode style approach you could move comments around between objects (today it will be a typical article but tomorrow that article could mutate into this uber photo-text-page-article that's radically changed but the comment stays the same and so it just needs to keep track of who owns it (refID or refObject).
Hows that for brainfart moment! Hehehe
Scott.
P.S
In reality if we use DOM approach for most things in CFMX we could make life easier.. As in the end aren't we really emulating DOM server-side? Its just our way of parsing heirachies that hurt... Never did like traversing a 20,000 node dom for one object..could use SAX I guess but I'm baffled how to implement SAX + DOM + CFMX together...hehee
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]] On Behalf Of Nando
> Sent: Thursday, 13 January 2005 4:17 AM
> To: [email protected]
> Subject: RE: [CFCDev] When to Use Composition (Was: Newbie
> approach...)
>
>
> I've always wondered what "service" means in this context -
> comment service.
> I hear references sometimes to the service layer, or a
> "_____" service in an app and although i get the general
> sense, i'm wondering what distinguishs a service from anything else.
>
> I like this general concept better. I just ran into this
> here, specifically with "comments". I originally built it
> coupled with content versions, but the moment it appeared in
> the app, a user asked if they could add a comment to a page.
> My hand hit my forehead in less than a second. (Why didn't i
> couple comments and versions like that!!!)
>
> I'd also say that i've found that EDITING and RENDERING are 2
> very different things in an app of this nature, and gradually
> i've learned that it's important to treat them separately.
> Perhaps this seems academic at first glance, but i ran smack
> into that distinction as soon as i tried to code my first attempts.
>
> RenderPage, to be flexible and efficient, shouldn't need to
> traverse a changing sea of hierarchy to throw a page
> together. And users can only deal with one bit of content at
> a time. All these things imply, in my limited experience,
> that components of a page shouldn't be tightly coupled. How
> to accomplish that in a well constructed model is a bit of a
> challenge.
>
>
>
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
> Behalf Of Bill Rawlinson
> Sent: Wednesday, January 12, 2005 6:02 PM
> To: [email protected]
> Subject: Re: [CFCDev] When to Use Composition (Was: Newbie
> approach...)
>
>
> boy, this discussion is getting busy.
>
> Another thought is to create a comment service that anything
> could use. For instance you might have a photo that needs
> comments. Then your photo functionality could register with
> the comment service.
> Likewise your articles. Maybe you want to post some
> documents on your site and let people comment on them. Then
> you have a document manager that registers with the comment
> service. (technically, a photo is just a document afterall).
>
> plus, with a comment service you could use the onc service
> across many apps including the blog without havnig to
> recreate comment functionality each time. The service could
> provide the form for posting the comment and everything if
> you wanted it to (which you could then style to fit in your
> sites look and feel).
>
>
>
>
> On Wed, 12 Jan 2005 11:46:56 -0500, Brian Kotek
> <[EMAIL PROTECTED]> wrote:
> > Thoughts on why that would be better or worse than this in
> the manager:
> >
> > public void addComent( int articleID, commentTO commentTO ) {
> > commentDAO.save( articleID, commentTO ); }
> >
> > In that case you don't need to call the articleDAO at all,
> nor is the
> > article responsible for doing anything with the comment. And if you
> > had the articleID as part of the commentTO you could
> actually just do:
> >
> > commentDAO.save( commentTO )
> >
> >
> > > >From the ArticleManager's point of view, this is all
> that happens:
> > >
> > > var article = ArticleDAO.getArticle( articleID ); var comment =
> > > article.addComment( commentTO );
> ArticleDAO.createComment( comment
> > > );
> > >
> >
> > ----------------------------------------------------------
> > You are subscribed to cfcdev. To unsubscribe, send an email to
> > [EMAIL PROTECTED] with the words 'unsubscribe cfcdev'
> > in the message of the email.
> >
> > CFCDev is run by CFCZone (www.cfczone.org) and supported by
> Mindtool,
> > Corporation (www.mindtool.com).
> >
> > An archive of the CFCDev list is available at
> www.mail-archive.com/[email protected]
> >
>
>
> --
> --------------
> [EMAIL PROTECTED]
> http://blog.rawlinson.us
>
> I have 9 gmail invites,want one?
> ----------------------------------------------------------
> You are subscribed to cfcdev. To unsubscribe, send an email
> to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev'
> in the message of the email.
>
> CFCDev is run by CFCZone (www.cfczone.org) and supported by
> Mindtool, Corporation (www.mindtool.com).
>
> An archive of the CFCDev list is available at
> www.mail-archive.com/[email protected]
>
>
>
> ----------------------------------------------------------
> You are subscribed to cfcdev. To unsubscribe, send an email
> to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev'
> in the message of the email.
>
> CFCDev is run by CFCZone (www.cfczone.org) and supported by
> Mindtool, Corporation (www.mindtool.com).
>
> An archive of the CFCDev list is available at
> www.mail-archive.com/[email protected]
>
