I'm still not exactly sure of the schema choice for the app but one thing I 
would suggest is forget about beans, services, factories, dao's and gateways to 
start with. 
Just create your 2 objects, Lookup and LookupContents and get them interacting 
with each other. You can refactor out into bean, service, factories and 
gateways later once you're happy your design actually works.
It sounds like there will be many design changes as you build this so you don't 
want 8+ objects to start with that will probably all go through big changes, 
just go with one or two and take it from there.
Its also a good idea to try some unit testing as you go so you can refactor 
with more confidence.

Alan



----- Original Message ----
From: cs01rsw <[EMAIL PROTECTED]>
To: CFCDev <[email protected]>
Sent: Wednesday, September 17, 2008 12:45:22 PM
Subject: [CFCDEV] Re: cfc scenario help


Hi Baz, thanks for the reply

yes the goal of the system is to allow the users to model anything.
they can create their own lookups, as you said surgeons, hostpitals
etc.... our system stores the data not in a grid format but in the 4
tables.

so the lookupColumns will store just the names of the columns and the
lookupvalues just store the values, then the 4th lookupdata table will
store the data for a value and a column - so it is acting like a grid
but then allows the users to add as many columns and values as they
want

hmmm, now that you have got me explaining this i'm thinking that this
may not be the right way to do it. maybe the better way to do it would
be to actually create the lookuptable in the background then if they
add a new column, then simply add that column to the table, if they
add a new row then add a new row to the table. then i can get rid the
last 3 tables and just have a lookupname table which just stores the
names and then holds a reference point to the tables that are built to
store the data in the background

i suppose what confuses me now is how we would model this in OO for
the cfc's. would we have:

- a lookup bean, which holds information relating to the lookup -
lookup id, and the table it references etc... also have a services,
dao and gw cfcs for this bean (functions would be addLookup(),
deleteLookup(), etc...)
- then also have another bean called lookupcontents which models the
data and will also have a services, gw, and dao cfcs for this bean
(this will be used for manipulating the data in the lookup table; such
as addColumn(), addRow(), addData() etc...)

i think this sounds right, would really appreciate the feedback though
as i am fairly new to OO :-)

thanks also for making me see that the 4 table model didn't look the
best option

richard

On Sep 16, 11:59 pm, Baz <[EMAIL PROTECTED]> wrote:
> Hey Richard, a couple of questions for clarification:
>
>    - Is one of the goals of your system to model anything? For example,
>    today it is GPs but tommorow it may be sports-cars, then laptops and so on?
>    Or maybe a little more narrow but similar in concept, nurses, interns,
>    surgeons, etc? If so, would you store that primary id in the "lookup" 
> table?
>    - Is the "lookupValues" table where you store *possible* values for a
>    given field and lookupData where you store the actual value? For example a
>    column of "title" would have lookupValues of "Mr.,Dr.,Mrs.etc." and a
>    lookupData of just "Dr."?
>
> Cheers,
> Baz
>
> On Mon, Sep 15, 2008 at 7:01 AM, Richard (J7) <[EMAIL PROTECTED]> wrote:
> >  hi,
>
> > we have a feature in out software that allows users to create multi column
> > lookups:
>
> > e.g. they can create a lookup for gp which would look like the following:
>
> > value  |  gp name  | go title |   gp address 1 | etc....
>
> > ---------------------------------------------------------
>
> > 0         Smith        Dr           25 Gate Road  .....
>
> > 1         May          Dr           12 Old Street ......
>
> > the user can add any columns they want, and then add as many values as they
> > want, and start adding gp details in the grid in the database we have 4
> > tables to store this data:
>
> > table 1) lookup (which stores just the name of the lookup - in this case
> > gp)
>
> > table 2) lookupValues (which store the values - 0,1,2 etc....)
>
> > table 3) lookupColumns (which store the columns - 'GP Name', 'GP Title',
> > 'GP Address 1', etc...)
>
> > table 4) lookupData (which holds the actual data and references to the
> > value and columns that it is data for - e.g. it holds lookupName=GP,
> > lookupValue=1, lookupColumn=GP Name, lookupData=Smith)
>
> > we are getting stuck on knowing the correct way to model this in cfc's and
> > OO. we usually create a Bean for the object, a service, a gateway, and a
> > dao. but where do we start for this? do we have a single lookup bean and
> > then a gateway and dao for each table, or do we simply have one bean,
> > service, gateway, dao. if we have one bean then how are the properties of
> > that bean going to be built up, and how are the getters and setters going to
> > reflect this grid structure of this lookup object. really appreciate any
> > help,
>
> > thanks
>
> > richard
>
> > Regards,
>
> > Richard White BSc (Hons), MBCS
>
> > Director
>
> > J7IS Ltd
>
> > Web Application Development
>
> > *Contact Details:*
>
> > Email 1: [EMAIL PROTECTED]
>
> > Email 2: [EMAIL PROTECTED]
>
> > Web:www.j7is.co.uk
>
> > Tel: +44 (0)798 472 1810
>
> > *Head Office (Postal Address):*
>
> > J7 Group
>
> > University College London
>
> > Department of Computer Science
>
> > Gower Street
>
> > London
>
> > WC1E 6BT
>
> > *Registered Details:*
>
> > *J7IS Ltd*
>
> > *3a Livingstone Court*
>
> > *55 Peel Road***
>
> > *Harrow***
>
> > *Middlesex*
>
> > *HA3 7QT*
>
> > * *
>
> > *Company Number: 05613376*
>
> > *VAT Number: 924 9392 93*
>
> > ---------------------------------------------------------------------------------
>
> > This e-mail is confidential and privileged. If you are not the intended
> > recipient please accept our apologies; please do not disclose, copy or
> > distribute information in this e-mail or take any action in reliance on its
> > contents: to do so is strictly prohibited and may be unlawful. Please inform
> > us that this message has gone astray before deleting it. Thank you for your
> > co-operation.
>
> > * *



      
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"CFCDev" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/cfcdev?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to