Re: EOModel needs an easy tweak
Hi Chuck, Thanks for your input and I hope it will help me understand the EOF relationship modelling better. Comments below: On 2010-11-07, at 8:35 PM, Chuck Hill wrote: > On Nov 6, 2010, at 11:02 PM, Farrukh Ijaz wrote: > >>> For your case, I'm finding it difficult to imagine why two entities >>> (IS-A) have such different relationship requirements. >> >> The model has a legacy. In the beginning the entities appear to be different >> but semantically they are have some common behaviour when observed under >> specific domain . E.g. in a File System we have File and Folder (Directory) >> two separate entities. But at OS level, both have name, timestamp, >> permissions etc. The need before was to treat File and Folder as separate >> entities, but now the requirement demands to have some granularity among >> them. This is just an example to explain the situation. > > > But do they share behavior? Shared data is not necessarily an indication for > inheritance. I can't answer this with 100% accuracy. But let me try to explain the model using Unix file system so it could become clear whether they share behaviour or not. In Unix (or Linux) I can create directories (Entity A), and files (Entity B). Directories can have subdirectories and files (Entity A -> toMany Entity A and Entity A -> toMany Entity B). Now I have a requirement where I need to have a special type of directory (Entity C) which can have symlinks (Entity D) or subdirectories of it's own type (Entity C) which means Entity C -> toMany Entity C and Entity C -> toMany Entity D. Each symlink can only point to directory, file, special directory or another symlink (which means Entity D -> toOne Entity A or toOne Entity B or toOne Entity C or toOne Entity D). In this situation, if need an abstraction (either based on java based interface or EOF inheritance) which could treat all Entity A, Entity B, Entity C and Entity D such as Entity Alpha so I could have only 1 toOne relationship from Entity D to Entity Alpha. My assumption is, if I implement a Java interface instead of EOF inheritance, EOF won't help much and I need to manage this relationship programmatically, right? If the explanation is still confusing then I would opt for four toOne relationships from Entity D -> Entity A, Entity B, Entity C and Entity D. Assign all of them an interface to collect common data provide additional method to return a common object (by inspecting all of the four relationships as only 1 will be present at a time). Farrukh ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: EOModel needs an easy tweak
On Nov 6, 2010, at 11:02 PM, Farrukh Ijaz wrote: >> For your case, I'm finding it difficult to imagine why two entities >> (IS-A) have such different relationship requirements. > > The model has a legacy. In the beginning the entities appear to be different > but semantically they are have some common behaviour when observed under > specific domain . E.g. in a File System we have File and Folder (Directory) > two separate entities. But at OS level, both have name, timestamp, > permissions etc. The need before was to treat File and Folder as separate > entities, but now the requirement demands to have some granularity among > them. This is just an example to explain the situation. But do they share behavior? Shared data is not necessarily an indication for inheritance. Chuck -- Chuck Hill Senior Consultant / VP Development Practical WebObjects - for developers who want to increase their overall knowledge of WebObjects or who are trying to solve specific problems. http://www.global-village.net/products/practical_webobjects smime.p7s Description: S/MIME cryptographic signature ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: EOModel needs an easy tweak
Hi Mark, Thanks for the detailed explanation. Comments below: On 2010-11-06, at 10:35 PM, Mark Wardle wrote: > Hi Farrukh, > > I'm no expert on these matters but unless I have a very simple and > straightforward plan of inheritance that would be immediately obvious > to someone else joining the project, I've avoiding using EOF > inheritance. I've dabbled with a number of options depending on the > exact circumstances and most importantly, what has the *correct > real-life semantic*. > > For instance, I've used enums to represent behaviours and have linked > these to behaviour classes - the enterprise objects can simply call > its registered behaviour object.method - I'm basing this on posts to > the list from Ramsey. Can you please explain a little bit more on this? > > In other situations, I've simply used java interfaces and implement > these within separate entities perhaps factoring out common > functionality into a helper class. > > For your case, I'm finding it difficult to imagine why two entities > (IS-A) have such different relationship requirements. The model has a legacy. In the beginning the entities appear to be different but semantically they are have some common behaviour when observed under specific domain . E.g. in a File System we have File and Folder (Directory) two separate entities. But at OS level, both have name, timestamp, permissions etc. The need before was to treat File and Folder as separate entities, but now the requirement demands to have some granularity among them. This is just an example to explain the situation. > If you really > need to do this and want to use EOF inheritance, then perhaps you can > have two trees of inheritance. The first tree would have Entity X as > root. These entities would defer handling of relationships to one of > two entities that provide the appropriate relationship behaviour - > to-one or to-many. My domain knowledge is limited so I may need further explanation here too. Farrukh > > Good luck, > > Mark > > On 6 November 2010 11:39, Farrukh Ijaz > wrote: >> Hi EOF-ologists, >> >> I've a modelling issue and need to know what could be the suitable fix (or >> tweak) to fulfil the requirement. >> >> Below is the existing EO Model. >> >> >> I've two entities (Entity A and Entity B) extending Abstract Entity X but >> these entities have their own tables (no single table inheritance). I need >> to design Entity D and Entity E where Entity D has a toMany relationship >> with Entity E and Entity E needs to have a toOne relationship with Entity A, >> Entity B, Entity C and Entity D. >> >> 1. One way can be for Entity E to have four different relationships such as >> toEntityA, toEntityB, toEntityC and toEntityD. (This is _not_ desirable) >> 2. The other way mentioned in the lower diagram where Entity A, Entity B, >> Entity C and Entity D extend Abstract Entity X and Entity E will have toOne >> relationship with Abstract Entity X. (This is _desirable_). >> >> >> What would be the easiest way to model such relationship? I'm _not_ >> relationship expert so may be the way I assumed the model (second diagram) >> can be wrong or practically impossible? >> Also note that I cannot make Entity C and Entity D to extend Abstract Entity >> X due to some design constraints therefore I think to introduce Abstract >> Entity Alpha. >> >> Thanks, >> >> Farrukh >> >> >> >> >> ___ >> Do not post admin requests to the list. They will be ignored. >> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) >> Help/Unsubscribe/Update your Subscription: >> http://lists.apple.com/mailman/options/webobjects-dev/mark%40wardle.org >> >> This email sent to m...@wardle.org >> > > > > -- > Dr. Mark Wardle > Specialist registrar, Neurology > Cardiff, UK > ___ > Do not post admin requests to the list. They will be ignored. > Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/webobjects-dev/farrukh.ijaz%40fuegodigitalmedia.com > > This email sent to farrukh.i...@fuegodigitalmedia.com ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: EOModel needs an easy tweak
Hi Chuck, All the entities (A, B, C, and D) eventually have become IS-A relationship. I would also like to use interface instead of inheritance but thinking how I can manage the Entity E to have toOne relationship for all these entities using interface. May be I need to write custom code to manage the storage and retrieval for this relationship? Any clue or reference to existing example would be helpful. Thanks, Farrukh Sent from my iPhone On 2010-11-07, at 1:00 AM, Chuck Hill wrote: > If all they share is a few common, generic attributes, I would not use > inheritance for this. I'd prefer an interface. As Mark pointed out, > inheritance is for "IS A" relationships. It is not to save some > implementation time. That is an abuse of inheritance. If they share > behavior, then inheritance is more likely the correct design. > > Barbara Liskov has some excellent articles on this. Google for "Liskov > Substitution Principal". > > Chuck > > > On Nov 6, 2010, at 12:23 PM, Farrukh Ijaz wrote: > >> Yes, they will expose certain properties which are symmetrical in all the >> entities, e.g. title, description, etc. >> >> Consider this requirement as a tree structure which can have nodes that >> appear to be symmetric but their underlying user object can be different. >> >> Farrukh >> >> Sent from my iPhone >> >> On 2010-11-06, at 9:58 PM, Steve Peery wrote: >> >>> Is there any shared functionality between Entity A, Entity B, Entity C and >>> Entity D that would justify Abstract Entity Alpha? >>> >>> Steve >>> >>> On Nov 6, 2010, at 7:39 AM, Farrukh Ijaz wrote: >>> Hi EOF-ologists, I've a modelling issue and need to know what could be the suitable fix (or tweak) to fulfil the requirement. Below is the existing EO Model. I've two entities (Entity A and Entity B) extending Abstract Entity X but these entities have their own tables (no single table inheritance). I need to design Entity D and Entity E where Entity D has a toMany relationship with Entity E and Entity E needs to have a toOne relationship with Entity A, Entity B, Entity C and Entity D. 1. One way can be for Entity E to have four different relationships such as toEntityA, toEntityB, toEntityC and toEntityD. (This is _not_ desirable) 2. The other way mentioned in the lower diagram where Entity A, Entity B, Entity C and Entity D extend Abstract Entity X and Entity E will have toOne relationship with Abstract Entity X. (This is _desirable_). What would be the easiest way to model such relationship? I'm _not_ relationship expert so may be the way I assumed the model (second diagram) can be wrong or practically impossible? Also note that I cannot make Entity C and Entity D to extend Abstract Entity X due to some design constraints therefore I think to introduce Abstract Entity Alpha. Thanks, Farrukh ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/speery%40me.com This email sent to spe...@me.com >>> >> ___ >> Do not post admin requests to the list. They will be ignored. >> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) >> Help/Unsubscribe/Update your Subscription: >> http://lists.apple.com/mailman/options/webobjects-dev/chill%40global-village.net >> >> This email sent to ch...@global-village.net > > -- > Chuck Hill Senior Consultant / VP Development > > Practical WebObjects - for developers who want to increase their overall > knowledge of WebObjects or who are trying to solve specific problems. > http://www.global-village.net/products/practical_webobjects > > > > > > > ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: EOModel needs an easy tweak
If all they share is a few common, generic attributes, I would not use inheritance for this. I'd prefer an interface. As Mark pointed out, inheritance is for "IS A" relationships. It is not to save some implementation time. That is an abuse of inheritance. If they share behavior, then inheritance is more likely the correct design. Barbara Liskov has some excellent articles on this. Google for "Liskov Substitution Principal". Chuck On Nov 6, 2010, at 12:23 PM, Farrukh Ijaz wrote: > Yes, they will expose certain properties which are symmetrical in all the > entities, e.g. title, description, etc. > > Consider this requirement as a tree structure which can have nodes that > appear to be symmetric but their underlying user object can be different. > > Farrukh > > Sent from my iPhone > > On 2010-11-06, at 9:58 PM, Steve Peery wrote: > >> Is there any shared functionality between Entity A, Entity B, Entity C and >> Entity D that would justify Abstract Entity Alpha? >> >> Steve >> >> On Nov 6, 2010, at 7:39 AM, Farrukh Ijaz wrote: >> >>> Hi EOF-ologists, >>> >>> I've a modelling issue and need to know what could be the suitable fix (or >>> tweak) to fulfil the requirement. >>> >>> Below is the existing EO Model. >>> >>> I've two entities (Entity A and Entity B) extending Abstract Entity X but >>> these entities have their own tables (no single table inheritance). I need >>> to design Entity D and Entity E where Entity D has a toMany relationship >>> with Entity E and Entity E needs to have a toOne relationship with Entity >>> A, Entity B, Entity C and Entity D. >>> >>> 1. One way can be for Entity E to have four different relationships such as >>> toEntityA, toEntityB, toEntityC and toEntityD. (This is _not_ desirable) >>> 2. The other way mentioned in the lower diagram where Entity A, Entity B, >>> Entity C and Entity D extend Abstract Entity X and Entity E will have toOne >>> relationship with Abstract Entity X. (This is _desirable_). >>> >>> What would be the easiest way to model such relationship? I'm _not_ >>> relationship expert so may be the way I assumed the model (second diagram) >>> can be wrong or practically impossible? >>> Also note that I cannot make Entity C and Entity D to extend Abstract >>> Entity X due to some design constraints therefore I think to introduce >>> Abstract Entity Alpha. >>> >>> Thanks, >>> >>> Farrukh >>> >>> >>> >>> ___ >>> Do not post admin requests to the list. They will be ignored. >>> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) >>> Help/Unsubscribe/Update your Subscription: >>> http://lists.apple.com/mailman/options/webobjects-dev/speery%40me.com >>> >>> This email sent to spe...@me.com >> > ___ > Do not post admin requests to the list. They will be ignored. > Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/webobjects-dev/chill%40global-village.net > > This email sent to ch...@global-village.net -- Chuck Hill Senior Consultant / VP Development Practical WebObjects - for developers who want to increase their overall knowledge of WebObjects or who are trying to solve specific problems. http://www.global-village.net/products/practical_webobjects smime.p7s Description: S/MIME cryptographic signature ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: EOModel needs an easy tweak
If that is the case, then your Abstract Entity Alpha scenario seems reasonable. Steve On Nov 6, 2010, at 3:23 PM, Farrukh Ijaz wrote: > Yes, they will expose certain properties which are symmetrical in all the > entities, e.g. title, description, etc. > > Consider this requirement as a tree structure which can have nodes that > appear to be symmetric but their underlying user object can be different. > > Farrukh > > Sent from my iPhone > > On 2010-11-06, at 9:58 PM, Steve Peery wrote: > >> Is there any shared functionality between Entity A, Entity B, Entity C and >> Entity D that would justify Abstract Entity Alpha? >> >> Steve >> >> On Nov 6, 2010, at 7:39 AM, Farrukh Ijaz wrote: >> >>> Hi EOF-ologists, >>> >>> I've a modelling issue and need to know what could be the suitable fix (or >>> tweak) to fulfil the requirement. >>> >>> Below is the existing EO Model. >>> >>> I've two entities (Entity A and Entity B) extending Abstract Entity X but >>> these entities have their own tables (no single table inheritance). I need >>> to design Entity D and Entity E where Entity D has a toMany relationship >>> with Entity E and Entity E needs to have a toOne relationship with Entity >>> A, Entity B, Entity C and Entity D. >>> >>> 1. One way can be for Entity E to have four different relationships such as >>> toEntityA, toEntityB, toEntityC and toEntityD. (This is _not_ desirable) >>> 2. The other way mentioned in the lower diagram where Entity A, Entity B, >>> Entity C and Entity D extend Abstract Entity X and Entity E will have toOne >>> relationship with Abstract Entity X. (This is _desirable_). >>> >>> What would be the easiest way to model such relationship? I'm _not_ >>> relationship expert so may be the way I assumed the model (second diagram) >>> can be wrong or practically impossible? >>> Also note that I cannot make Entity C and Entity D to extend Abstract >>> Entity X due to some design constraints therefore I think to introduce >>> Abstract Entity Alpha. >>> >>> Thanks, >>> >>> Farrukh >>> >>> >>> >>> ___ >>> Do not post admin requests to the list. They will be ignored. >>> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) >>> Help/Unsubscribe/Update your Subscription: >>> http://lists.apple.com/mailman/options/webobjects-dev/speery%40me.com >>> >>> This email sent to spe...@me.com >> ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: EOModel needs an easy tweak
Yes, they will expose certain properties which are symmetrical in all the entities, e.g. title, description, etc. Consider this requirement as a tree structure which can have nodes that appear to be symmetric but their underlying user object can be different. Farrukh Sent from my iPhone On 2010-11-06, at 9:58 PM, Steve Peery wrote: > Is there any shared functionality between Entity A, Entity B, Entity C and > Entity D that would justify Abstract Entity Alpha? > > Steve > > On Nov 6, 2010, at 7:39 AM, Farrukh Ijaz wrote: > >> Hi EOF-ologists, >> >> I've a modelling issue and need to know what could be the suitable fix (or >> tweak) to fulfil the requirement. >> >> Below is the existing EO Model. >> >> I've two entities (Entity A and Entity B) extending Abstract Entity X but >> these entities have their own tables (no single table inheritance). I need >> to design Entity D and Entity E where Entity D has a toMany relationship >> with Entity E and Entity E needs to have a toOne relationship with Entity A, >> Entity B, Entity C and Entity D. >> >> 1. One way can be for Entity E to have four different relationships such as >> toEntityA, toEntityB, toEntityC and toEntityD. (This is _not_ desirable) >> 2. The other way mentioned in the lower diagram where Entity A, Entity B, >> Entity C and Entity D extend Abstract Entity X and Entity E will have toOne >> relationship with Abstract Entity X. (This is _desirable_). >> >> What would be the easiest way to model such relationship? I'm _not_ >> relationship expert so may be the way I assumed the model (second diagram) >> can be wrong or practically impossible? >> Also note that I cannot make Entity C and Entity D to extend Abstract Entity >> X due to some design constraints therefore I think to introduce Abstract >> Entity Alpha. >> >> Thanks, >> >> Farrukh >> >> >> >> ___ >> Do not post admin requests to the list. They will be ignored. >> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) >> Help/Unsubscribe/Update your Subscription: >> http://lists.apple.com/mailman/options/webobjects-dev/speery%40me.com >> >> This email sent to spe...@me.com > ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: EOModel needs an easy tweak
Hi Farrukh, I'm no expert on these matters but unless I have a very simple and straightforward plan of inheritance that would be immediately obvious to someone else joining the project, I've avoiding using EOF inheritance. I've dabbled with a number of options depending on the exact circumstances and most importantly, what has the *correct real-life semantic*. For instance, I've used enums to represent behaviours and have linked these to behaviour classes - the enterprise objects can simply call its registered behaviour object.method - I'm basing this on posts to the list from Ramsey. In other situations, I've simply used java interfaces and implement these within separate entities perhaps factoring out common functionality into a helper class. For your case, I'm finding it difficult to imagine why two entities (IS-A) have such different relationship requirements. If you really need to do this and want to use EOF inheritance, then perhaps you can have two trees of inheritance. The first tree would have Entity X as root. These entities would defer handling of relationships to one of two entities that provide the appropriate relationship behaviour - to-one or to-many. Good luck, Mark On 6 November 2010 11:39, Farrukh Ijaz wrote: > Hi EOF-ologists, > > I've a modelling issue and need to know what could be the suitable fix (or > tweak) to fulfil the requirement. > > Below is the existing EO Model. > > > I've two entities (Entity A and Entity B) extending Abstract Entity X but > these entities have their own tables (no single table inheritance). I need to > design Entity D and Entity E where Entity D has a toMany relationship with > Entity E and Entity E needs to have a toOne relationship with Entity A, > Entity B, Entity C and Entity D. > > 1. One way can be for Entity E to have four different relationships such as > toEntityA, toEntityB, toEntityC and toEntityD. (This is _not_ desirable) > 2. The other way mentioned in the lower diagram where Entity A, Entity B, > Entity C and Entity D extend Abstract Entity X and Entity E will have toOne > relationship with Abstract Entity X. (This is _desirable_). > > > What would be the easiest way to model such relationship? I'm _not_ > relationship expert so may be the way I assumed the model (second diagram) > can be wrong or practically impossible? > Also note that I cannot make Entity C and Entity D to extend Abstract Entity > X due to some design constraints therefore I think to introduce Abstract > Entity Alpha. > > Thanks, > > Farrukh > > > > > ___ > Do not post admin requests to the list. They will be ignored. > Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/webobjects-dev/mark%40wardle.org > > This email sent to m...@wardle.org > -- Dr. Mark Wardle Specialist registrar, Neurology Cardiff, UK ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: EOModel needs an easy tweak
> 2. The other way mentioned in the lower diagram where Entity A, Entity B, > Entity C and Entity D extend Abstract Entity X and Entity E will have toOne > relationship with Abstract Entity X. (This is _desirable_). Not knowing anymore that that of your model, I would take the Entity Alpha option. Take a look at ERXLongPrimaryKeyFactory in order to ease the fetching of that relationship (not to fetch many tables). jfv ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: EOModel needs an easy tweak
Is there any shared functionality between Entity A, Entity B, Entity C and Entity D that would justify Abstract Entity Alpha? Steve On Nov 6, 2010, at 7:39 AM, Farrukh Ijaz wrote: > Hi EOF-ologists, > > I've a modelling issue and need to know what could be the suitable fix (or > tweak) to fulfil the requirement. > > Below is the existing EO Model. > > I've two entities (Entity A and Entity B) extending Abstract Entity X but > these entities have their own tables (no single table inheritance). I need to > design Entity D and Entity E where Entity D has a toMany relationship with > Entity E and Entity E needs to have a toOne relationship with Entity A, > Entity B, Entity C and Entity D. > > 1. One way can be for Entity E to have four different relationships such as > toEntityA, toEntityB, toEntityC and toEntityD. (This is _not_ desirable) > 2. The other way mentioned in the lower diagram where Entity A, Entity B, > Entity C and Entity D extend Abstract Entity X and Entity E will have toOne > relationship with Abstract Entity X. (This is _desirable_). > > What would be the easiest way to model such relationship? I'm _not_ > relationship expert so may be the way I assumed the model (second diagram) > can be wrong or practically impossible? > Also note that I cannot make Entity C and Entity D to extend Abstract Entity > X due to some design constraints therefore I think to introduce Abstract > Entity Alpha. > > Thanks, > > Farrukh > > > > ___ > Do not post admin requests to the list. They will be ignored. > Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/webobjects-dev/speery%40me.com > > This email sent to spe...@me.com ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com