This looks great Frank. I don't know why I thought I should compile the type in the resolve step. I think I was worried that types needed to be defined very early on, but it seems not necessary now, because I think there is a later step in the compiler that re-orders definitions to avoid forward references.
Nice work! On 2012-02-03, at 05:34, Frank Guo wrote: > > Summary: Fix lazyreplicator.insertNode(), classroot > > New Features: > > Bugs Fixed: LPP-10129 > > > Documentation: > > Release Notes: > > Overview: > > when compiling file include user type definition to lzo, > there are some generated code out side the XML. > > Details: > TypeCompiler.java > > It is because the TypeCompiler generate the lzs code when it resolve the type > element. > The moment is too early, so the lzs code for user type declaration will > appear at the top of lzo file. > But the compile method of TypeCompiler is empty, so it will not generate > any code, when compile the type element. > > > > Files: > M WEB-INF/lps/server/src/org/openlaszlo/compiler/TypeCompiler.java > M WEB-INF/lps/server/src/org/openlaszlo/compiler/ViewSchema.java > > After tracing the OL code, I found the reason of LPP-10129, the lzo problem. > > > It is because the TypeCompiler generate the lzs code when resolve the the > type element. > The moment is too early, so the lzs code for user type declaration will > appear at the top of lzo file. > But the compile method of TypeCompiler is empty, so it will not generate > any code, when compile the type element. > > I read the code of ClassCompiler, use the idea of it. I added the content of > compile method of TypeCompiler, move the code that can generate lzs > code from resolve method to compile method. > > After some basic test, I found it works well. Do you think we can fix the bug > like this. > > I attach the file I had changed, I add a method to ViewSchema class, to get > Type Class model. > > > > thanks > > > frank > > <TypeCompiler.java><ViewSchema.java><diff.txt>
