Re: Entity/attribute/relationship terrible toString?
Re: Entity/attribute/relationship terrible toString?
- Subject: Re: Entity/attribute/relationship terrible toString?
- From: Aaron Rosenzweig via Webobjects-dev <email@hidden>
- Date: Tue, 2 Jun 2020 13:40:53 -0400
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@hidden <mailto:email@hidden> t: (301) 956-2319
> On Jun 2, 2020, at 1:36 PM, ocs--- via Webobjects-dev
> <email@hidden> wrote:
>
> Paul,
>
>> On 2. 6. 2020, at 2:05 PM, Paul Yu <email@hidden <mailto:email@hidden>> 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@hidden <mailto:email@hidden>>
>>> wrote:
>>>
>>> Markus,
>>>
>>>> On 2 Jun 2020, at 12:09, Markus Ruggiero <email@hidden
>>>> <mailto:email@hidden>> 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@hidden <mailto:email@hidden>>
>>>>>> 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@hidden
>>>>> <mailto:email@hidden>)
>>>>> Help/Unsubscribe/Update your Subscription:
>>>>>
>>>>>
>>>>> This email sent to email@hidden
>>>>
>>>
>>> _______________________________________________
>>> Do not post admin requests to the list. They will be ignored.
>>> Webobjects-dev mailing list (email@hidden
>>> <mailto:email@hidden>)
>>> Help/Unsubscribe/Update your Subscription:
>>>
>>> This email sent to email@hidden
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden