Extending adapter classes

Posts   
 
    
Paul
User
Posts: 28
Joined: 26-Feb-2004
# Posted on: 11-Mar-2004 20:00:49   

I've been reading the related threads...

http://www.llblgen.com/tinyforum/Messages.aspx?ThreadID=448 http://www.llblgen.com/tinyforum/Messages.aspx?ThreadID=517 as well as the Generated Code - Extending the framework through inheritance, Adapter

...and have a fairly good understanding of how to extend the EntityClasses using the Adapter model.

Working through this today I've noticed that the entity class SetRelatedEntity method also refers to EntityClasses by name.

Should these be extended/overridden as well?

For instance:

(Before)


        Public Overrides Sub SetRelatedEntity(relatedEntity As IEntity2, fieldName As string)
            Select Case fieldName
                Case "AssemblySubGroup"
                    ResetEventHandler(_assemblySubGroup)
                    _assemblySubGroup = CType(relatedEntity, AssemblySubGroupEntity)
                    AddHandler _assemblySubGroup.AfterSave, AddressOf OnEntityAfterSave
                    MyBase.SetEntitySyncInformation(fieldName, relatedEntity, AssemblySubGroupLineLocationEntity.Relations.AssemblySubGroupEntityUsingSiteCdAssemblySubGroupCd)
                    If Not _assemblySubGroup.IsNew Then
                        ' sync now
                        MyBase.SyncFKFields( AssemblySubGroupLineLocationEntity.Relations.AssemblySubGroupEntityUsingSiteCdAssemblySubGroupCd, _assemblySubGroup)
                    End If
            End Select
        End Sub

(After)


    Public Overrides Sub SetRelatedEntity(ByVal relatedEntity As IEntity2, ByVal fieldName As String)
        Select Case fieldName
            Case "AssemblySubGroup"
                ResetEventHandler(MyBase.AssemblySubGroup)
                MyBase.AssemblySubGroup = CType(relatedEntity, AssemblySubGroupXEntity)
                AddHandler MyBase.AssemblySubGroup.AfterSave, AddressOf OnEntityAfterSave
                MyBase.SetEntitySyncInformation(fieldName, relatedEntity, AssemblySubGroupLineLocationXEntity.Relations.AssemblySubGroupEntityUsingSiteCdAssemblySubGroupCd)
                If Not MyBase.AssemblySubGroup.IsNew Then
                    ' sync now
                    MyBase.SyncFKFields( AssemblySubGroupLineLocationXEntity.Relations.AssemblySubGroupEntityUsingSiteCdAssemblySubGroupCd, MyBase.AssemblySubGroup)
                End If
        End Select
    End Sub

If this is appropriate, would I also need the Shadows to hide the base method? If not, why not?

I really appreciate your fast responses. smile They make all the difference!

Paul
User
Posts: 28
Joined: 26-Feb-2004
# Posted on: 12-Mar-2004 20:19:01   

Bug fixes come first, but have you had a chance to peek at this thread?

I'm spending a lot of time keeping these methods in the extended classes as well as GetRelationInfo... methods. If they aren't needed to extend the adapter classes I could move more quickly.

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39588
Joined: 17-Aug-2003
# Posted on: 12-Mar-2004 20:32:55   

Sorry, had to fix the 1:1 issues today as well as some minor issue in the runtime lib. simple_smile

You don't need to override those. The thing is: the name is used to identify the type so it can retrieve the persistence information. A name is used and not a 'type' object for performance reasons.

Because derived classes use at the moment the same entity fields, you can keep all that code simple_smile So all persistence related code can be borrowed from the generated code, and you just add new, non persistent properties and new methods to the derived class.

This also goes for the GetRelationInfo methods, as these will simply generate filter and relation information for retrieving the data, and your derived factory classes will then use that read data to create the correct class.

Frans Bouma | Lead developer LLBLGen Pro
Paul
User
Posts: 28
Joined: 26-Feb-2004
# Posted on: 12-Mar-2004 20:52:05   

That's a relief. I have 65 entities to extend!

Then the "base" extended class should only contain: 1) Constructors 2) Overriden entity class properties

With these the extended class is ready to go.

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39588
Joined: 17-Aug-2003
# Posted on: 12-Mar-2004 21:30:45   

Paul wrote:

That's a relief. I have 65 entities to extend!

Then the "base" extended class should only contain: 1) Constructors 2) Overriden entity class properties

With these the extended class is ready to go.

Correct simple_smile As in my example in the docs.

65 entities to extend is pretty much, is there a reason you want them to be extended? (because perhaps I can add a feature to help you with it). You can also think of a template to generate these classes for you. Saves time simple_smile

Frans Bouma | Lead developer LLBLGen Pro
Paul
User
Posts: 28
Joined: 26-Feb-2004
# Posted on: 12-Mar-2004 22:01:52   

Otis wrote:

65 entities to extend is pretty much

YES IT IS confused

Otis wrote:

is there a reason you want them to be extended? (because perhaps I can add a feature to help you with it). You can also think of a template to generate these classes for you. Saves time simple_smile

Many of them don't need to be.

I want all database activity to flow through a business layer. To reduce confusion (and errant coding) I'm extending all the entity classes so that the programmers have a single (consistant) way to access data. This will eleminate deciding (or forget to decide) when to use an entity class vs. an extended entity.

Once this is accomplished I will begin truely extending the classes with business logic where appropriate.

I've not looked at your templates on purpose. I'm having enough trouble getting my hands around the OOP; frowning everyone's new at something!

I would LOVE a template enhancement that pop's out a third project with just extended entity classes. If it's easier than I expect, just give me some encouragement and I'll take a look at it.

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39588
Joined: 17-Aug-2003
# Posted on: 12-Mar-2004 23:04:00   

I'll see if I can come up with a template for that tomorrow simple_smile It's not that much.

Frans Bouma | Lead developer LLBLGen Pro
Otis avatar
Otis
LLBLGen Pro Team
Posts: 39588
Joined: 17-Aug-2003
# Posted on: 15-Mar-2004 09:56:59   

Paul, I haven't had time for these templates this weekend. I'll see what I can come up with today.

Frans Bouma | Lead developer LLBLGen Pro
Paul
User
Posts: 28
Joined: 26-Feb-2004
# Posted on: 15-Mar-2004 13:25:16   

Otis wrote:

Paul, I haven't had time for these templates this weekend. I'll see what I can come up with today.

I can't thank you enough!

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39588
Joined: 17-Aug-2003
# Posted on: 15-Mar-2004 17:13:17   

They're on their way. (SqlServer, VB.NET only).

Please let me know if these work. I can then turn them into an add-on for customers simple_smile

Frans Bouma | Lead developer LLBLGen Pro
ctadlock avatar
ctadlock
User
Posts: 60
Joined: 12-Feb-2004
# Posted on: 16-Mar-2004 00:57:36   

This would be an extremly helpful feature to me as well. I have 100+ entities in my system and am not looking forward to extending all of them. A C# version would be great!

CT

netclectic avatar
netclectic
User
Posts: 255
Joined: 28-Jan-2004
# Posted on: 16-Mar-2004 11:55:30   

I'll second that simple_smile

Cadmium avatar
Cadmium
User
Posts: 153
Joined: 19-Sep-2003
# Posted on: 17-Mar-2004 22:57:17   

Thirded on the C# version.

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39588
Joined: 17-Aug-2003
# Posted on: 17-Mar-2004 23:20:24   

Ok I'll crank out a C# version tomorrow simple_smile Stay tuned simple_smile

Frans Bouma | Lead developer LLBLGen Pro
Otis avatar
Otis
LLBLGen Pro Team
Posts: 39588
Joined: 17-Aug-2003
# Posted on: 18-Mar-2004 17:18:41   

It's available now, in the 3rd party section in the customer area. Please read the readme.txt file. They probably require some work on your side.

Frans Bouma | Lead developer LLBLGen Pro
Lakeman
User
Posts: 12
Joined: 15-Mar-2004
# Posted on: 26-Mar-2004 21:59:54   

Otis wrote:

It's available now, in the 3rd party section in the customer area. Please read the readme.txt file. They probably require some work on your side.

I noticed that the subclasses that get generated are missing the contructor that allows you to construct an entity by providing its primary key. Is that absent on purpose, or does that fall under 'They probably require some work on your side.'?

-Brian

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39588
Joined: 17-Aug-2003
# Posted on: 26-Mar-2004 22:35:03   

Excellent point, Brian, I'll try to fix that simple_smile

"The work on your part" means that you probably have to alter the templates so you get your own prefixes for the classes, perhaps have them in another namespace, perhaps in another folder.

Frans Bouma | Lead developer LLBLGen Pro
eugene
User
Posts: 85
Joined: 05-Oct-2004
# Posted on: 09-Nov-2004 11:51:37   

Hi Otis,

I haven't spent enough time exploring the 3rd Party Tools part, and now I know I should. The Add-On is what I was thinking of lately smile

I do have a question: The extended classes are not used as relation-members in the generated classes. For example, the MyOrder class would expose a CustomerEntity class. Shoud it not be possible for it to expose a MyCustomer class? If the MyCustomer class were to have a number of added properties, the member of MyOrder, CustomerEntity, would not provide these members.

Is it possible/advisable to change the template so that subclasses are always returned (any member of type SubClass.RelationMember would return a subclass)? I believe it is not possible to cast an EntityClass into a SubEntity (upward casting ????)?

What do you suggest.

Greetings

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39588
Joined: 17-Aug-2003
# Posted on: 09-Nov-2004 14:17:07   

eugene wrote:

Hi Otis,

I haven't spent enough time exploring the 3rd Party Tools part, and now I know I should. The Add-On is what I was thinking of lately smile I do have a question: The extended classes are not used as relation-members in the generated classes. For example, the MyOrder class would expose a CustomerEntity class. Shoud it not be possible for it to expose a MyCustomer class? If the MyCustomer class were to have a number of added properties, the member of MyOrder, CustomerEntity, would not provide these members.

It exposes an Orders collection and the type stored in that collection is determined by the factory used for the fetch action of that collection. So if you use the MyCustomer methods for the relation info for Orders, you'll get that info, also through prefetch paths, that's been taken care of. The Orders property is overriden in the derived class and it has a different attribute value, which signals the ITypedList implementation of EntityCollection to produce the proper propertydescriptors in a databinding scenario.

Frans Bouma | Lead developer LLBLGen Pro
eugene
User
Posts: 85
Joined: 05-Oct-2004
# Posted on: 09-Nov-2004 15:33:21   

Sorry flushed It must have been a case of Bad-Read or something like that. I re-read the code and now I see that all has been taken care of!

Greetings

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39588
Joined: 17-Aug-2003
# Posted on: 09-Nov-2004 17:14:53   

Ok! smile

Frans Bouma | Lead developer LLBLGen Pro