Hi OC,

Yeah we missed your point. We gave you advice about the EO but not the 
relationships. 

Generally I don’t have logging coming out about relationships nor the object 
graph. I suppose you’ll have to look at what is generating those logs and have 
some sort of preprocessor that does something “smart” for the display of your 
object graph. Maybe a big if/else block for each your relationships or maybe 
something generic if that’s good enough that has heuristics for display names. 
AARON ROSENZWEIG / Chat 'n Bike <http://www.chatnbike.com/>
e:  [email protected] <mailto:[email protected]>  t:  (301) 956-2319        
        
        

> On Jun 2, 2020, at 1:36 PM, ocs--- via Webobjects-dev 
> <[email protected]> wrote:
> 
> Paul,
> 
>> On 2. 6. 2020, at 2:05 PM, Paul Yu <[email protected] <mailto:[email protected]>> 
>> wrote:
>> There are two templates _EO and EO.java that are used by eogenerate to 
>> create your EO classes.  If you open your Eogenerate File you can see where 
>> your templates are.
> 
> Can't recall anything like that from WO. Isn't that some 
> Eclipse/WOLips-specific thing? I don't use Eclipse anymore; I am yet to see a 
> worse IDE. Having tested many of them (and having suffered with Eclipse for 
> some years), eventually I stick with Xcode, which is far from perfect too and 
> it definitely has a plethora of ugly quirks, but at the very least it is 
> infinitely better than the Eclipse disaster (and aside of that, I do all my 
> *OS development in there, and it's quite convenient to use one and the same 
> IDE for all the work; myself, I found switching IDEs really inconvenient. As 
> always, your mileage may vary ;))
> 
> Besides, well, you got me ranting, but anyway: I do not, not, not use 
> generated code, in my opinion and experience, that's one very very bad 
> approach. My EO classes are based on my own superclass which reads in the 
> model at startup and installs the appropriate accessors dynamically (in a way 
> quite similar, though of course not identical, to CoreData). And it, quite 
> naturally, also contains my own overridden toString.
> 
> Which all seems to me completely beside the point. From the very beginning, I 
> am writing of entities/attributes/relationships, not EO classes. I can do 
> almost whatever I want with the EO classes, but so far, I haven't succeeded 
> to find any way to affect toStrings of entities/attributes/relationships 
> (i.e., the EOEntity, EOAttribute and EORelationship class).
> 
> Or do I miss something of importance here?
> 
> Thanks,
> OC
> 
>>> On Jun 2, 2020, at 7:04 AM, OCsite via Webobjects-dev 
>>> <[email protected] <mailto:[email protected]>> 
>>> wrote:
>>> 
>>> Markus,
>>> 
>>>> On 2 Jun 2020, at 12:09, Markus Ruggiero <[email protected] 
>>>> <mailto:[email protected]>> wrote:
>>>> Why not simply override toString() in EOGenerate templates once and for 
>>>> all?
>>> 
>>> What are “EOGenerate templates” and how they affect the 
>>> entities/attributes/relationships toStrings? I can't find anything like 
>>> that in my WO documentation. Seems it might be the right solution... if I 
>>> knew what it is :)
>>> 
>>> Thanks!
>>> OC
>>> 
>>>> 
>>>>>> On 2 Jun 2020, at 01:52, ocs--- via Webobjects-dev 
>>>>>> <[email protected] <mailto:[email protected]>> 
>>>>>> wrote:
>>>>> 
>>>>> Hi there,
>>>>> 
>>>>> occasionally, I need to put entities/attributes/relationships into 
>>>>> complex nested property lists. Occasionally for debug, I need to print 
>>>>> out these property lists.
>>>>> 
>>>>> Alas, entities/attributes/relationships normally print out their complete 
>>>>> contents in their toStrings, which makes the logs completely unuseable 
>>>>> (and when there's more of them in a property list, actually bogs down the 
>>>>> application so much it must be killed).
>>>>> 
>>>>> Isn't there some trick to make those darned model classes toString 
>>>>> something reasonable, e.g., just their class, name and hash?
>>>>> 
>>>>> Thanks,
>>>>> OC
>>>>> 
>>>>> _______________________________________________
>>>>> Do not post admin requests to the list. They will be ignored.
>>>>> Webobjects-dev mailing list      ([email protected] 
>>>>> <mailto:[email protected]>)
>>>>> Help/Unsubscribe/Update your Subscription:
>>>>> https://lists.apple.com/mailman/options/webobjects-dev/steiner%40rucotec.ch
>>>>>  
>>>>> <https://lists.apple.com/mailman/options/webobjects-dev/steiner%40rucotec.ch>
>>>>> 
>>>>> This email sent to [email protected]
>>>> 
>>> 
>>> _______________________________________________
>>> Do not post admin requests to the list. They will be ignored.
>>> Webobjects-dev mailing list      ([email protected] 
>>> <mailto:[email protected]>)
>>> Help/Unsubscribe/Update your Subscription:
>>> https://lists.apple.com/mailman/options/webobjects-dev/pyu%40mac.com 
>>> <https://lists.apple.com/mailman/options/webobjects-dev/pyu%40mac.com>
>>> 
>>> This email sent to [email protected]
> 
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list      ([email protected])
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/webobjects-dev/aaron%40chatnbike.com
> 
> This email sent to [email protected]

 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list      ([email protected])
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to [email protected]

Reply via email to