Re: Entity/attribute/relationship terrible toString?
Re: Entity/attribute/relationship terrible toString?
- Subject: Re: Entity/attribute/relationship terrible toString?
- From: Jesse Tayler via Webobjects-dev <email@hidden>
- Date: Tue, 2 Jun 2020 13:40:32 -0400
EOF uses this template system -- don’t think of it as generated code but rather
boiler plates no different than using Wonder or even a library to do math.
Read the code and you’ll see it’s quite intelligently surrounding your object
model with useful, reliable foundations that are valuable.
Your model is text, this needs to reflect as an object in memory and this
template bridge starts off that process for you in a way that makes sense and
you’ll find useful for sure.
> 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> 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> wrote:
>>>
>>> Markus,
>>>
>>>> On 2 Jun 2020, at 12:09, Markus Ruggiero <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> 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)
>>>>> 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
_______________________________________________
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