Hi Ulrich,
Am Samstag, 07.06.03 um 14:00 Uhr schrieb Ulrich Köster:
> there is a good reason why I spend my time for it: Time. It's no fun
> to write the same code over and over again. Let's take a login panel
> for instance. It requires an EO User and a Component with the fields
> user and password. On submit I'll check if the user and password are
> not null . If that's okay I create my fetch spec and so on.
I've been using the generation gap pattern and the auto-created fetch
specs for a pretty long time now, so you don't need to preach to the
choir:) What I meant was that you can simply create your XML from
.eomodeld files and a few settings in the userInfo of entities and
attributes. I simply can't see why you would write a real modeler clone
for that - which you'd need to do if I get the EMF demo correctly.
> Entity User
[snip]
I don't understand the example? Are you creating a "User" or a
"UserFetchController"? If the latter, how does is look like and how is
it invoked?
> It generates everything to create, modify, delete and search a user.
> When I write my WOComponent all I need is to make an instance of the
> usersearch and bind the fields (including language aware errors string
> when the user enters nothing). There will be no fetch until the user
> enters something.
I'm using similar stuff what I called the "Clazz" pattern:
public class User ...{
public static class UserClazz extends EOGenericRecordClazz {
// fetch specs go here
// the advantage vs static methods is that you can inherit and
extend them easily;
}
public final static UserClazz clazz = new UserClazz();
}
so you can call
User.clazz.usersWithUsernamePassword(ec, "joe", "secret");
or
// inherited from EOGenericRecordClazz
NSArray arr = User.clazz.objectsWithPrimaryKey(ec, "1");
User u = User.clazz.createAndInsertObject(ec);
But I find this makes the code path a bit hard to follow when doing
complex operations which should have a real controller. And you may end
up with a lot of "waste" code that never gets called. Dunno.
> Another thing are unit tests. They get generated also.
Does that make sense? I mean, what good is a testSetFoo() if you
generate it? Or am I being dense here? What do the tests look like?
Cheers, Anjo
This archive was generated by hypermail 2.0.0 : Sat Jun 07 2003 - 10:38:12 EDT