polygene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Merlin <p...@nosphere.org>
Subject Re: Massive Refactoring in ZEST-105 branch
Date Wed, 23 Dec 2015 18:59:14 GMT
Gang,

Niclas Hedhman a écrit :
> Sooooo.... I have tried to straighten up the difference between the "Model"
> and the "Instances", especially for the ModuleInstance, which was heavily
> overloaded with Model stuff.
> The interesting bit about the Modules (and Application and Layer too) is
> that there is one model and one instance, so it is possible to go from one
> to the other and back. Does that sound right?

At first sight It doesn't sound quite right.

Stanislav Muhametsin a écrit :
> Strictly my personal opinion, but no, it doesn't sound right.
> IMO instance should know its model, but models should not know
> instances that are created off the model.

That makes sense to me.


Niclas Hedhman a écrit :
> Right... I kind of agree with you. But end of the day, isn't the Module
> effectively a singleton, and like the "Class" will "know" of its only
> instantiation... I could also see that it makes sense the other way.
Stanislav Muhametsin a écrit :
> I remember Paul was writing some program, which would instantiate
> multiple Applications off a single ApplicationModel.
> How things would behave then?

I did write code that "restart" applications for integration with Play
"development mode",but without reusing ApplicationModel. Probably as a
result of too much defensive coding ; this coincide with the time I was
working on passivation.

But, if I recall correctly, there should be nothing that prevents it.

Back to model/instance bidirectional navigability.
I can't come up with a valid usecase for model -> instance navigation
except maybe for runtime stuff. Or I miss something.
If we need it maybe it could be a lookup at the Application level
instead of a direct bidirectional relationship.


Niclas Hedhman a écrit :
> I have also started to break out the many different Factories that Module
> implements. I want to go down the same route as with the UnitOfWork and
> make them customizable services.
>
> Anyway, I have pushed this massive changed into the ZEST-105 branch, but it
> doesn't pass the tests yet. I had to rewrite a big chunk of the Service
> handling, since it felt completely wrong to skip the Model and deal with
> ServiceReferences directly.
> Another issue that breaks tests, is that I removed the implicit OrgJson
> value serialization, and intend to handle that the same way (what ever that
> will be) as EntityStore, UnitOfWorkFactory and other SPI extension
> mechanisms. Want uniformity in the SPI.
> I have refactored the ValueSerialization so that the ModuleDescriptor is
> passed along in the chained calls. What I have NOT done yet, is to lookup
> the type to deserialize, get ITS ModuleDescriptor and use that for the
> nested type and so on. I am pretty sure that will remove the "hack" of
> Value Type Finder (or whatever it was called)

+1 to all of the above

> What else?? Uhhhhh... super-tired from this long stint of refactoring, but
> hope I can push all the way through. I think I will take a couple of days
> rest from this...
>
> Cheers

Enjoy new year and stuff :)

Cheers

/Paul


Mime
View raw message