Re: Generating EOs from an EOModel

From: Ulrich Köster (ulric..bjectstyle.org)
Date: Sat Jun 07 2003 - 14:07:10 EDT

  • Next message: Kaj Hejer: "Enable/disable plugins... (or: no fun without WOLips)"

    Hi Anjo,

    Am Samstag, 07.06.03 um 16:39 Uhr schrieb Anjo Krank:

    > 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.
    When I use the eomodeld the project is bound to eof. The EMF stuff to
    build the XML Editors. Velocity generates the code. Ever tried to
    generate code with the EMF demo? It won't be a EOModeler clone. It will
    be a tool to desribe my basic business logic.
    >
    >> 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's more like a controller. In this example a UserSearchProcess is
    used. In the real code this should be a LoginProcess which sets the
    user in the session.

    public class LoginComponent ... {

            public UserSearchProcess userSearchProcess = new
    UserSearchProcess(this.getEditingContext());

            public LoginComponent() {
                    super(...);
            }

            public WOComponent login() {
                    if(userSearchProcess.isValid()) {
                            userSearchProcess.commit();
                            return this.pageWithName(Foo.pageName);
                            }
                    return this.context.page();
            }
    }

    from the wod
    //shows an error if the login string is null
    LoginErrorComponent: ErrorComponent {
            errorKey = userSearchController.LoginMissingKey;
            processErrors = userSearchController.processErrors;
    }
    //the field to enter the user name
    LoginTextField: WOTextField {
            value = userSearchController.login;
    }

    The userSearchProcess has instance variables for login and password. It
    hides all the stuff required to search for a user.

    >
    >> 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?
    Sometimes you have to change things even the templates. Which each
    change there is a good chance that something else may act different
    then before.

    Ulrich

    >
    > Cheers, Anjo
    >



    This archive was generated by hypermail 2.0.0 : Sat Jun 07 2003 - 14:05:51 EDT