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
