BorlandTalk.com Borland discussion newsgroups   Archives   FAQ   Search   Memberlist   Usergroups   Register   Profile   Log in to check your private messages   Log in  Needing 2nd set of eyes, Document vs. Model concepts          BorlandTalk.com Forum Index -> Delphi OO design View previous topic :: View next topic   Author Message Shawn Oster Guest Posted: Thu May 19, 2005 6:42 pm    Post subject: Needing 2nd set of eyes, Document vs. Model concepts I'm too close to this design and I keep erasing my whiteboard then rewriting the same things, perhaps someone out there can help. My question is should you make your Model as broad as possible to accommodate all the various Documents you *may* load into the system. My issue is that I have certain Documents that only have a subset of what the Model can hold and I need to limit the system from showing the entire model. An example might help. My system has three main Document types. A JobDoc, LabelDoc and PageDoc. All three contain ColorTables and DataReferences. The kicker is that a Job can contain 0..N Labels and 0..1 Pages while a LabelDoc holds 1 Label, 0 Pages and PageDoc holds 1 Page and 0 Labels. When I return a PageDoc object from my Persistence layer I don't want it to have an empty LabelList or if I return a LabelDoc I only want a single Label property vs a Labels collection that is simply *known* that the first element should contain a Label and that you shouldn't add more labels to it. I suppose my real stumbling block has been trying to treat the Document as the Model. By Document I mean all the objects returned from a Persistence.Load call. A load of a Page vs. a Label vs. a Job all return different objects of different quantities yet I'm looking for a generic way to represent them all while providing the ability to mask certain features based on the Document type. Does it make sense to do the following: 1. Return one of several different Document types from the Persistence layer. 2. "Import" that Document into the Model. I'd need a handful of helper methods here (ImportJobDocumentIntoModel, ImportLabelDocumentIntoModel, etc). 3. Signal the Model for what it should be representing so the UI can mask functionality. Basically the Model can be populated in various ways and based on how it was populated changes what you can do with it until it's reset or repopulated. Any other ideas or thoughts or critiques? Almost all the examples of apps I find back into a common database vs. having to use multiple file formats as the persistence storage mechanism. In a way I'm having to deal with a single front-end that can back into a multiple backends with various levels of functionality. Thanks, Shawn Back to top Andrea Raimondi Guest Posted: Mon May 23, 2005 6:41 am    Post subject: Re: Needing 2nd set of eyes, Document vs. Model concepts Shawn Oster wrote: Quote: Basically the Model can be populated in various ways and based on how it was populated changes what you can do with it until it's reset or repopulated. Any other ideas or thoughts or critiques? Almost all the examples of apps I My take: Type TDocumentBit = class public procedure SetupUI(AFrm : TMyDocForm);virtual;abstract; end; TLabelPiece = class(TDocumentBit) public procedure SetupUI(AFrm : TMyDocForm);override; property Text : String; end; TText = class( TDocumentBit) public procedure SetupUI(AFrm : TMyDocForm);override; end; TDocumentBitList = class(TDocumentBit) // Add, Remove, etc, inherit from TDocumentBit so you can use it as a // piece itself public procedure SetupUI(AFrm : TMyDocForm);override; end; TDocument = class private FList : TDocumentBitList; public procedure SetupUI(AFrm : TMyDocForm);override; end; TJob = class(TDocument) public procedure SetupUI(AFrm : TMyDocForm);override; end; TPage = class(TDocument) public procedure SetupUI(AFrm : TMyDocForm);override; end; Do u like this? Quote: Thanks, Welcome, Quote: Shawn Andrew Back to top Joanna Carter (TeamB) Guest Posted: Mon May 23, 2005 8:02 am    Post subject: Re: Needing 2nd set of eyes, Document vs. Model concepts "Shawn Oster" <soster (AT) colorflex (DOT) com> a écrit dans le message de news: 428cddda$1 (AT) newsgroups (DOT) borland.com... Quote: My system has three main Document types. A JobDoc, LabelDoc and PageDoc. All three contain ColorTables and DataReferences. The kicker is that a Job can contain 0..N Labels and 0..1 Pages while a LabelDoc holds 1 Label, 0 Pages and PageDoc holds 1 Page and 0 Labels. When I return a PageDoc object from my Persistence layer I don't want it to have an empty LabelList or if I return a LabelDoc I only want a single Label property vs a Labels collection that is simply *known* that the first element should contain a Label and that you shouldn't add more labels to it. I suppose my real stumbling block has been trying to treat the Document as the Model. By Document I mean all the objects returned from a Persistence.Load call. A load of a Page vs. a Label vs. a Job all return different objects of different quantities yet I'm looking for a generic way to represent them all while providing the ability to mask certain features based on the Document type. I guess you are trying to do a sort of MVP system here. Look at your object model first : you have two "item" classes and one "container" class. You also have the concept of a Tree structure creeping in here in that all three class contain common functionality, regardless of their position in the hierarchy. Doc (abstract) { ColorTables DataReferences } LabelDoc inherits Doc { Label } PageDoc inherits Doc { Page } JobDoc inherits Doc { Labels Pages } To display these you need to mimic this hierarchy in your UI. You should never need to mask functionality; rather, you should start with a base UI and then add more to it as you move down the hierarchy. Quote: Basically the Model can be populated in various ways and based on how it was populated changes what you can do with it until it's reset or repopulated. Any other ideas or thoughts or critiques? Almost all the examples of apps I find back into a common database vs. having to use multiple file formats as the persistence storage mechanism. In a way I'm having to deal with a single front-end that can back into a multiple backends with various levels of functionality. You seem to be talking about populating a Model; I would talk about populating an object or list and containing that object or list in a Model. I use the Model concept, not just to link into MVP but also to encapsulate behaviour that affects other classes when applied to the value type of the model. Come back to me if things are not yet clear; we need to take this one step at a time. Joanna -- Joanna Carter (TeamB) Consultant Software Engineer TeamBUG support for UK-BUG TeamMM support for ModelMaker Back to top Joanna Carter (TeamB) Guest Posted: Mon May 23, 2005 8:04 am    Post subject: Re: Needing 2nd set of eyes, Document vs. Model concepts "Andrea Raimondi" <rainaple (AT) tin (DOT) it> a écrit dans le message de news: [email]42917b0e (AT) newsgroups (DOT) borland.com[/email]... Quote: My take: Type TDocumentBit = class public procedure SetupUI(AFrm : TMyDocForm);virtual;abstract; end; <snip> Quote: Do u like this? Not a lot ! ) You are allowing the business classes to get involved with UI matters and this is always a bad thing as it ties your BOs to one particular UI layer. Joanna -- Joanna Carter (TeamB) Consultant Software Engineer TeamBUG support for UK-BUG TeamMM support for ModelMaker Back to top Andrea Raimondi Guest Posted: Mon May 23, 2005 11:41 am    Post subject: Re: Needing 2nd set of eyes, Document vs. Model concepts Joanna Carter (TeamB) wrote: Quote: Not a lot ! ) Grrrr! Quote: You are allowing the business classes to get involved with UI matters and this is always a bad thing as it ties your BOs to one particular UI layer. Uhm... I'm not sure I agree here, actually, I don't :-) I mean, the UI can be abstracted and you decouple it, despite what controls you have on the form. I was thinking along these lines: Type TMyDocForm = class(TForm) public procedure AddLabel(ALabel : TLabel);virtual;abstract; procedure AddPage(APage : TPage);virtual;abstract; // so on... end; What don't you like of this? Quote: Joanna Andrew Back to top Display posts from previous: All Posts1 Day7 Days2 Weeks1 Month3 Months6 Months1 Year Oldest FirstNewest First         BorlandTalk.com Forum Index -> Delphi OO design All times are GMT Page 1 of 1   Jump to: Select a forum C++ Builder Newsgroups----------------C++ BuilderC++ Builder (ActiveX)C++ Builder (Announcements)C++ Builder (Command Line Tools)C++ Builder DatabasesC++ Builder Databases (ADO)C++ Builder Databases (Desktop)C++ Builder Databases (InterBase Express)C++ Builder Databases (Multi-Tier)C++ Builder Databases (SQL Servers)C++ Builder (Graphics)C++ Builder (IDE)C++ Builder (Internet)C++ Builder (Internet Socket)C++ Builder (Internet Web)C++ Builder (Jobs)C++ Builder (Language)C++ Builder (Language C++)C++ Builder (Compatibility with MFC)C++ Builder (Native API)C++ Builder (Non-Technical)C++ Builder (Students)C++ Builder (Third Party Tools)C++ Builder (Upgrade)C++ Builder (VCL)C++ Builder (VCL Components Usage)C++ Builder (VCL Components Development)C++ Builder (VCL Usage)C++ Builder (WinAPI)C++ Builder Installation Delphi Newsgroups----------------Delphi (General)Delphi ActiveX Controls UsageDelphi ActiveX Controls DevelopmentDelphi As400Delphi DatabasesDelphi Databases (ADO)Delphi Databases (dbExpress)Delphi Databases (Desktop)Delphi Databases (InterBase Express)Delphi Databases (Multi-Tier)Delphi Databases (SQL Servers)Delphi DeploymentDelphi GraphicsDelphi IDEDelphi InternationalizationDelphi InternetDelphi Internet Isapi-WebBrokerDelphi Internet WebSnapDelphi Internet WinsockDelphi JobsDelphi Language BASMDelphi Language ObjectPascalDelphi Model Driven Architecture (General)Delphi Model Driven Architecture (Third Party)Delphi MultimediaDelphi Native APIDelphi Non-TechnicalDelphi ObjectPascalDelphi OLE AutomationDelphi OO designDelphi OpenToolsAPIDelphi Reporting-ChartingDelphi RTLDelphi StudentsDelphi TeamSourceDelphi Thirdparty ToolsDelphi Thirdparty Tools (General)Delphi Thirdparty Tools (IntraWeb)Delphi Thirdparty Tools (RaveReports)Delphi UpgradeDelphi VCLDelphi VCL ComponentsDelphi VCL Components UsingDelphi VCL Components WritingDelphi WebServices SOAPDelphi WinAPIDelphi XMLDelphi Installationcomp.lang.pascal.delphi.components.misccomp.lang.pascal.delphi.components.usagecomp.lang.pascal.delphi.components.writingcomp.lang.pascal.delphi.databasescomp.lang.pascal.delphi.misccomp.sources.delphi JBuilder Newsgroups----------------JBuilderJBuilder AnnouncementsJBuilder Applet IssuesJBuilder As400JBuilder CompilerJBuilder CORBA/RMIJBuilder DatabasesJBuilder DB SwingJBuilder DebuggerJBuilder DeploymentJBuilder DocumentationJBuilder EnterpriseJBuilder HandheldJBuilder IDEJBuilder JavaJBuilder JavaAPIJBuilder Java LanguageJBuilder Java SwingJBuilder Java BeansJBuilder Java Beans UsageJBuilder Java Beans DevelopmentJBuilder JBCLJBuilder JDataStoreJBuilder JobsJBuilder LinuxJBuilder MacintoshJBuilder & MobileSetJBuilder MultiLingual AppsJBuilder Non-TechnicalJBuilder OpenToolsJBuilder Servlets (JSP)JBuilder StudentsJBuilder Team DevelopmentJBuilder Thirdparty ToolsJBuilder UpgradeJBuilder Installation InterBase Newsgroups----------------InterBaseInterBase Bug DiscussionInterBase GeneralInterBase IBConsoleInterBase OpenSourceInterBase ReplicationInterBase SQLInterBase ThirdpartyInterBase Installation Miscellaneous Borland Newsgroups----------------AppCenterAppServerEnteraVisiBroker  You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum Powered by phpBB © 2001, 2006 phpBB Group SEO toolkit © 2004-2006 webmedic.