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: aa...@chatnbike.com <mailto:aa...@chatnbike.com> t: (301) 956-2319 > On Jun 2, 2020, at 1:36 PM, ocs--- via Webobjects-dev > <webobjects-dev@lists.apple.com> wrote: > > Paul, > >> On 2. 6. 2020, at 2:05 PM, Paul Yu <p...@mac.com <mailto:p...@mac.com>> >> 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 >>> <webobjects-dev@lists.apple.com <mailto:webobjects-dev@lists.apple.com>> >>> wrote: >>> >>> Markus, >>> >>>> On 2 Jun 2020, at 12:09, Markus Ruggiero <mailingli...@kataputt.com >>>> <mailto:mailingli...@kataputt.com>> 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 >>>>>> <webobjects-dev@lists.apple.com <mailto:webobjects-dev@lists.apple.com>> >>>>>> 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 (Webobjects-dev@lists.apple.com >>>>> <mailto:Webobjects-dev@lists.apple.com>) >>>>> 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 stei...@rucotec.ch >>>> >>> >>> _______________________________________________ >>> Do not post admin requests to the list. They will be ignored. >>> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com >>> <mailto:Webobjects-dev@lists.apple.com>) >>> 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 p...@mac.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: > https://lists.apple.com/mailman/options/webobjects-dev/aaron%40chatnbike.com > > This email sent to aa...@chatnbike.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: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
