Header

Ignoring certain instance variables

By this hook you can specify a list of instance variables that won't be serialized. The way to do it is to implement in a particular class the method #fuelIgnoredInstanceVariableNames. Let's say we have the class User and we do not want to serialize the instance variables 'acumulatedLogins' and 'applications'. So we implement:
User class >> fuelIgnoredInstanceVariableNames
	^#('acumulatedLogins' 'applications')
When materialized, such instance variables will be nil. If you want to re-initialize and set values to those instance variables, you can use #fuelAfterMaterialization for that.Be aware that in case of renaming those instance variables, you should rename that method as well. Notice also that the method #fuelIgnoredInstanceVariableNames is implemented at class side. This means that ALL instances of such class will ignore the defined instances variables. In StOMP serializer this same hook is called #stompTransientInstVarNames and in SIXX it is #sixxIgnorableInstVarNames. We test this feature in FLClassShapeTest.

Post materialization action

The method #fuelAfterMaterialization let us execute something once an object has been materialized. For example, let's say we would like to set back the instance variable 'acumulatedLogins'during materialization. Hence, we can implement:
User >> fuelAfterMaterialization
 acumulatedLogins := 0. 
We test this feature in FLClassShapeTest.

Substitutes on Serialization

This way, an object can the actual object to serialize. This is useful when you want to serialize something different than the original object. You have to override two hooks: #fuelSubstitution and #fuelAccept:. As an example, imagine we want to replace an object directly with nil. In other words, we want to make a whole object transient, say CachedResult. For that, we should implement:
CachedResult >> fuelAccept: aVisitor
	^ aVisitor visitSubstitution: self
CachedResult >> fuelSubstitution
	^ nil
As another example, we have a Proxy class and when serializing we want to serialize its target instead of the proxy. So we implement:
Proxy >> fuelAccept: aVisitor
	^ aVisitor visitSubstitution: self
Proxy >> fuelSubstitution
	^ target
Notice that #fuelAccept: is the same as the previous example. The last example is when an object needs to change the value of its instance variables. Say we have again the class User and we want to nil the instance variable 'history' if history size is bigger than 100. At the same time, we want change the value of 'lastLoginDay':
User >> fuelSubstitution
	| copy |
	copy := self copy.
	copy history size > 100 
		ifTrue: [ copy history: nil ].
	copy lastLoginDay: Date today.	
User >> fuelAccept: aVisitor
    ^self history isNil
        ifTrue: [super fuelAccept: aVisitor]
        ifFalse: [aVisitor visitSubstitution: self]
Notice that in this case, we can decide whether to nil an instance variable or not at instance level, not a class level as with #fuelIgnoredInstanceVariableNamesNote also that since in this case the substitution is a copy of the user, we can fall in an infinite sequence of substitutions. That's why in this example we need the if to escape from the cycle.You can see tests for this functionality at FLHookedSubstitutionTest.

Substitutes on Materialization

Global Sends

Suppose we have a special instance of User that represents the admin user, and it is a unique instance in the image. In case the admin user is referenced in our graph, we want to treat that object as a global. We can do that in this way:
User >> fuelAccept: aVisitor
    ^self == User admin
        ifTrue: [aVisitor visitGlobalSend: self]
        ifFalse: [super fuelAccept: aVisitor]
User >> fuelGlobalName
    ^#User
User >> fuelSelector
    ^#admin
So what will happen is that during serialization, the admin user won't be completly serialized (with all its intance variables) but instead its global name and selector are stored. Then, at materialization time, Fuel will send the selector #admin to the class User, and use what that answers as the admin user of the materialized graph. We test this feature in FLGlobalSendSerializationTest.

Ignoring certain instance variables

By this hook you can specify a list of instance variables that won't be serialized. The way to do it is to implement in a particular class the method #fuelIgnoredInstanceVariableNames. Let's say we have the class User and we do not want to serialize the instance variables 'acumulatedLogins' and 'applications'. So we implement:

User class >> fuelIgnoredInstanceVariableNames
	^#('acumulatedLogins' 'applications')

When materialized, such instance variables will be nil. If you want to re-initialize and set values to those instance variables, you can use #fuelAfterMaterialization for that.

Be aware that in case of renaming those instance variables, you should rename that method as well. Notice also that the method #fuelIgnoredInstanceVariableNames is implemented at class side. This means that ALL instances of such class will ignore the defined instances variables.

In StOMP serializer this same hook is called #stompTransientInstVarNames and in SIXX it is #sixxIgnorableInstVarNames.

We test this feature in FLClassShapeTest.

Post materialization action

The method #fuelAfterMaterialization let us execute something once an object has been materialized. For example, let's say we would like to set back the instance variable 'acumulatedLogins'during materialization. Hence, we can implement:

User >> fuelAfterMaterialization
 acumulatedLogins := 0. 

We test this feature in FLClassShapeTest.

Substitutes on Serialization

This way, an object can the actual object to serialize. This is useful when you want to serialize something different than the original object. You have to override two hooks: #fuelSubstitution and #fuelAccept:.

As an example, imagine we want to replace an object directly with nil. In other words, we want to make a whole object transient, say CachedResult. For that, we should implement:

CachedResult >> fuelAccept: aVisitor
	^ aVisitor visitSubstitution: self
CachedResult >> fuelSubstitution
	^ nil

As another example, we have a Proxy class and when serializing we want to serialize its target instead of the proxy. So we implement:

Proxy >> fuelAccept: aVisitor
	^ aVisitor visitSubstitution: self
Proxy >> fuelSubstitution
	^ target

Notice that #fuelAccept: is the same as the previous example. The last example is when an object needs to change the value of its instance variables. Say we have again the class User and we want to nil the instance variable 'history' if history size is bigger than 100. At the same time, we want change the value of 'lastLoginDay':

User >> fuelSubstitution
	| copy |
	copy := self copy.
	copy history size > 100 
		ifTrue: [ copy history: nil ].
	copy lastLoginDay: Date today.	
User >> fuelAccept: aVisitor
    ^self history isNil
        ifTrue: [super fuelAccept: aVisitor]
        ifFalse: [aVisitor visitSubstitution: self]

Notice that in this case, we can decide whether to nil an instance variable or not at instance level, not a class level as with #fuelIgnoredInstanceVariableNames

Note also that since in this case the substitution is a copy of the user, we can fall in an infinite sequence of substitutions. That's why in this example we need the if to escape from the cycle.

You can see tests for this functionality at FLHookedSubstitutionTest.

Substitutes on Materialization

Global Sends

Suppose we have a special instance of User that represents the admin user, and it is a unique instance in the image. In case the admin user is referenced in our graph, we want to treat that object as a global. We can do that in this way:

User >> fuelAccept: aVisitor
    ^self == User admin
        ifTrue: [aVisitor visitGlobalSend: self]
        ifFalse: [super fuelAccept: aVisitor]
User >> fuelGlobalName
    ^#User
User >> fuelSelector
    ^#admin

So what will happen is that during serialization, the admin user won't be completly serialized (with all its intance variables) but instead its global name and selector are stored. Then, at materialization time, Fuel will send the selector #admin to the class User, and use what that answers as the admin user of the materialized graph.

We test this feature in FLGlobalSendSerializationTest.