This is yet another example of something the people should try to fix
in their code before we support it in the product. Look at the mess
with the "Roots" folder support from Wonder or this SQL gen thing we
were arguing the whole morning to see what I mean. You try to fix up
something and then see all sort of strange bugs creeping out from the
woods.
There are effectively two supported ways to handle this: Prototypes
and different frameworks. Prototypes is most certainly the right way
to go here, but if this is too much work, then the models could get
split up. Only when a compelling argument besides "well, it always
worked" can be made, *then* someone (meaning you! Think about that!)
could spend the effort to try and fix this. If he can't be bothered
to fix his problems is his code (not saying that he his, mind you!),
then why should we be bothered to fix them in ours?
Eg, I'd also like that "_" is sorted right below everything and not
at the top, but I tried to fix it, couldn't find it and will now
rename stuff to "X" to it ends up at the bottom. I think a one-time
change is very much justified when we finally switch.
Right now, I would be totally content if EM worked just the same way
as EOM did and we could use it for day to day development and it
seems like its almost there. Everything else is just a distraction,
IMO. So kudos for the qualifier editor, which you omitted from your
list of "what works" so far!
Notwithstanding this, there seems to be a problem when EM is just to
eager so it also loads from the build directory, I have to see what
this is about and will send you more info if I find something.
Cheers, Anjo
Am 31.07.2006 um 14:14 schrieb Mike Schrag:
> Maybe a new "Exclude from Entity Modeler auto-loading"? This would
> really only work out if you have ONE model that behaves like this.
> If you had TWO models in your project (Model A FrontBase, Model A
> Oracle and Model B FrontBase, Model B Oracle) this would fail,
> because technically he would want us to load is Model A FrontBase
> and Model B FrontBase, but all of them would have autoloading
> false. I really don't have a good solution for this offhand.
>
> I think the only thing I could do would be to add a new file type
> that is just a text file with an explicit list of models to load
> (a .eomodelgroup file) and you open Entity Modeler by double-
> clicking this and I have you select which model in the group you
> would like to open. Basically you have to manually resolve this
> problem by creating this file, bypassing my own modelgroup loading
> implementation.
>
> On Jul 31, 2006, at 8:08 AM, Anjo Krank wrote:
>
>> Won't work.. because they are most likely copied over to a
>> Resources/mydb/ subfolder...
>>
>> Cheers, Anjo
>>
>> Am 31.07.2006 um 14:05 schrieb Mike Schrag:
>>
>>> Maybe we should be checking model paths against the Exclude from
>>> Resources pattern in your project? I assume you must have these
>>> set to not be Resources for this to be true?
>>
>
This archive was generated by hypermail 2.0.0 : Mon Jul 31 2006 - 08:30:11 EDT