Re: Questions to new WonderEntity templates

From: Ramsey Lee Gurley (rgurle..ac.com)
Date: Fri Jul 02 2010 - 13:02:09 UTC

  • Next message: David Avendasora: "Re: Questions to new WonderEntity templates"

    On Jul 2, 2010, at 7:01 AM, David Avendasora wrote:

    > It appears that this change is also breaking existing Wonder Frameworks and Apps that have models and generated EOs such as ERAttachment and ERModernMoviesDemo:
    >
    > _ERDatabaseAttachment.java has this:
    >
    > public static class _ERDatabaseAttachmentClazz extends ERAttachment.ERAttachmentClazz {
    > /* more clazz methods here */
    > }
    >
    > ERAttachment.java has no ERAttachmentClazz class in it since it is an existing class and EOGenerator doesn't touch it.
    >
    > _ERAttachment.java has this:
    >
    > public static class _ERAttachmentClazz extends ERXGenericRecord.ERXGenericRecordClazz<ERAttachment> {
    > /* more clazz methods here */
    > }

    True, since the Entity.java are never regenerated, those would need to be added manually or the subclasses will be pointing at a non-existant class for super.

    If that's a huge problem, I can create a patch to pull the clazz stuff back out. WOL-1125 started as a simple little patch to change inline strings to static strings, so if this is really problematic, I'm not insistent that these stay. But if everyone likes the clazz stuff, I can create a patch to add those too. Either is fine with me.

    > Does it really make sense to have the underscore variant of the Clazz classes?

    For the generics aspect, I think it makes sense. For instance if you have a subclass, then the super class is the generic. Subsequently, calling a method like createAndInsertInstance should(?) return the generic superclass instead of the correct subclass. This is where issues like that could be addressed by overriding the method to return the subclass instead. Maybe I'm wrong here.

    > If you want to add them to the _Entity.java, shouldn't they be added as simply EntityClazz (no underscore)? They can then be overridden in the Entity.java file. But I'm not sure how any of this fits in with inheritance in the model.
    >
    > Dave

    If the _Entity of a subclass wants to override the super, it would have to have a guaranteed super to override I think.

    Ramsey

    > On Jul 1, 2010, at 8:45 PM, Ramsey Lee Gurley wrote:
    >
    >> I made the mess, so I'll do it (^_^) Thanks for pointing out the error. I had not thought about testing for subclassed entities in different packages.
    >>
    >> Ramsey
    >>
    >>
    >> On Jul 1, 2010, at 1:02 PM, Johann Werner wrote:
    >>
    >>> Hi Ramsey,
    >>>
    >>> should I prepare a patch and file a JIRA or are you taking care of if?
    >>>
    >>> jw
    >>>
    >>>
    >>> Am 01.07.2010 um 04:00 schrieb Ramsey Lee Gurley:
    >>>
    >>>>
    >>>> On Jun 29, 2010, at 9:22 AM, Johann Werner wrote:
    >>>>
    >>>>> Hi,
    >>>>>
    >>>>> the template files WonderEntity.java and _WonderEntity.java were changed recently. Now I have some observations and questions I wanted to share:
    >>>>>
    >>>>> 1) in WonderEntity there is a method stub for init. It is declared as public though the overridden method in ERXGenericRecord is protected. Shouldn't they match?
    >>>>
    >>>>
    >>>> I copied Anjo's template on this one. ERCAudit* classes all had public init()s. Every usage I've seen of init and awakeFromInsertion all used public... so that's what I went with. As long as it doesn't cause an issue with calling init() from inside EOF, I'm fine with protected though.
    >>>>
    >>>>
    >>>>> 2) in _WonderEntity there is the static class stub _${entity.classNameWithoutPackage}Clazz extends ${parentClazzClass}. As this template represents the fixed part of the entity classes (every code change is overwritten during eogenerate) all modifications in the Clazz class would be useless. This raises the question if it is wise to put it there as it won't/shouldn't be ever used. Why not remove it and change the line in WonderEntity (where manual changes will be kept) to
    >>>>>
    >>>>> public static class ${entity.classNameWithoutPackage}Clazz extends ${parentClazzClass}
    >>>>
    >>>>
    >>>> I basically just copied Anjo's template here too. I think the intention is if you were to want to eogenerate some common methods into your clazz then this would give you a place to do so.
    >>>>
    >>>>
    >>>>> 3) subentities that have their parent entity in another framework are causing errors in Eclipse 3.6. For example I have SubEntity and ParentEntity. Then with the new templates I have
    >>>>>
    >>>>> public static class _SubEntityClazz extends ParentEntity.ParentEntityClazz { ...
    >>>>>
    >>>>> and Eclipse saying that "ParentEntity cannot be resolved to a type". If I either remove the "ParentEntity." part or add the full package name before ParentEntity the error is resolved. Of course Eclipse doesn't know ParentEntity as there is no import statement generated but why it doesn't complain "ParentEntityClazz" when removing "ParentEntity." escapes me. I think the best would be to add the full package name in the template.
    >>>>>
    >>>>> jw
    >>>>
    >>>> I would agree. That one slipped by me. I did not try separate packages for the super class and subclasses. It seems to work anyway if you use a separate package for your generated files. (Which I personally prefer) Changing line 18-ish to
    >>>>
    >>>> #set ($parentClazzClass = "${entity.parent.className}.${entity.parent.classNameWithoutPackage}Clazz")
    >>>>
    >>>> appears to make it work in both cases, and should probably be patched in.
    >>>>
    >>>> Ramsey
    >>
    >



    This archive was generated by hypermail 2.0.0 : Fri Jul 02 2010 - 13:03:00 UTC