Ah .. here's the "why". This is a question for Lachlan ... I don't
know if this was a merge problem or, if not, why he's piggy-backing on
patchesModelOnLoad, which I can't imagine ever actually wanting turned
on. You could also set er.extensions.ERXModelGroup.modelClassName to
the Model class explicitly. I'm not sure we shouldn't default to
that, actually?
ms
On Jun 20, 2009, at 11:06 AM, Kieran Kelleher wrote:
> Hi Mike,
>
> I had looked at the ERXModelGroup source to look for something that
> might indicate some scheme like that, but had not noticed anything.
> After getting your reply I now looked at ERXModelGroup svn history,
> I see Anjo's commit of this feature to ERXModelGroup$Model on
> 2/19/2009 and that you moved Anjo's logic for this over to ERXModel
> subclass on 3/29/2009.
>
> It appears that the property
> er.extensions.ERXModelGroup.patchModelsOnLoad needs to be true to
> ensure that (ERXModelGroup$Model extends ERXModel extends EOModel)
> is used instead of plain old EOModel. What might be a cause for
> concern is the fact that this property is not listed anywhere in
> ERXExtensions/Properties or in a new WOnderApp/Properties and in a
> default Wonder integration, this propery defaults to false. Without
> looking at the source just now, I would not have realized that I
> have never had that property set to true in any app.
>
> So, to see what happens, I put that property into two apps just now
> and they blow up with NPE's and terminate on startup. Just started 2
> new discussion threads on those so we can see if we can solve these
> 2 different NPE cases. If patchesModelsOnLoad can only be used under
> certain conditions, I will happily document that along with some
> docs that explain the Custom protos (aka extended protos usage) and
> configuration.
>
> -Kieran
>
>
>
>
>
> On Jun 19, 2009, at 5:57 PM, Mike Schrag wrote:
>
>> It's actually that we support specifically Wonder's "Custom"
>> prototypes that Anjo added -- EOCustom<OriginalPrototypeName> --
>> EOCustomJDBCPrototypes, EOCustomPrototypes,
>> EOCustomFrontBaseJDBCPrototypes (or whatever the order of those
>> words is).
>>
>> ms
>>
>> On Jun 19, 2009, at 5:14 PM, Kieran Kelleher wrote:
>>
>>> OK, answering my question (sort of) and posting the solution so I
>>> don't violate "Mike's thread ribbon rules" ;-) ....... it seems
>>> EntityModeler only merges your custom prototypes IF they are named
>>> EOPrototypes.
>>>
>>> So in summary, if you want a few custom prototypes in addition to
>>> Wonder's prototypes, just create a new proto framework called
>>> whatever you like and inside it a new EOModel named whatever you
>>> want and create a prototypes entity named "EOPrototypes". After
>>> you include that framework into your buildpath, your custom
>>> prototype attributes will be merged with the erprototypes in the
>>> ptototype drop-down in entity modeler.
>>>
>>> make sure to use a prefix such as "wk" or "my" or sth like that so
>>> your proto attribute names are namespaced and so they don't clash
>>> with erprototypes attribute names.
>>>
>>> Mike, if there is other conventions for custom proto entity names
>>> so that they get recognized by EntityModeler, please let us know,
>>> and I will post the info on the wiki.
>>>
>>> -Kieran
>>>
>>> On Jun 19, 2009, at 4:52 PM, Kieran Kelleher wrote:
>>>
>>>> Mikes blog post from March 2009 says
>>>>
>>>> "Entity Modeler now supports the new custom prototypes naming
>>>> convention from Wonder."
>>>>
>>>> So I have a custom eomodel with a custom proto entity that I want
>>>> to use alongside ERPrototypes. I am using orefixed proto
>>>> attribute names too so I don't clash with erprototype attr. names.
>>>>
>>>>
>>>> I have added these properties to the Properties file that has the
>>>> EOModel I am editing ..... Am I wrong in expecting EntityModeler
>>>> to look at this to add my custom protos to the proto dropdown menu?
>>>>
>>>> er.extensions.ERXModelGroup.prototypeModelNames = erprototypes,
>>>> WKCompatiblePrototypes
>>>> WKCompatiblePrototypes.EOPrototypesEntity =
>>>> MySQLCompatiblePrototypes
>>>
>>
>
This archive was generated by hypermail 2.0.0 : Sat Jun 20 2009 - 11:16:02 EDT