Hi Simon, I thnk that so far we all agree that: > * the old approach of files with "==do not edit this bit==" sucks. It is > inelegant and people *do* edit that bit. > * having artificial generated parent classes sucks; it distorts the true > hierarchy and simply cannot be applied to the API classes. > * generating source in general sucks, because it is not usual and is an > extra step that developers need to learn about; the more complicated the > process is, the worse the suckiness. > * generating source for files that other code depends on sucks, because > the code is not compilable after a checkout > * checking in generated source sucks. > * generating source into the src/main/java tree sucks, because it is > hard to tell generated code apart from non-generated stuff. > * generating source into the target tree sucks a bit, because you need > to explicitly add it to an IDE > * generating source for files that are frequently debugged sucks, > because you have to add the generated source path before using a > debugger. > * having code in templates sucks, because you don't have the normal IDE > support, and it leads to the above "generated code" suckiness.
we all agree that all these solutions suck more or less - but we do not agree which of this solutions sucks least. From a practical point of view, we NEED make it most simple for the developer/maintainer to work with this stuff, so we can cut out all theoretical "suck" statements. > > Doesn't this all lead back to having annotations on normal classes, with > no code-generation except for classes that no-one really cares about > (tag handlers)? no, it doesn't, cause the annotation structure you will be generating - well - sucks ;) And - there is no solution without reflection and accessing private inner fields for restoreState / saveState. This sucks even more. The only direct alternative I can see is Matthias' view that components > should not be edited at all, and all custom logic should be in renderer > classes. However like Mario I am rather skeptical about that; it just > does not sound right to me. And in any case, that still qualifies for a > number of the above categories. Matthias view sucks, cause component logic should be right where the data is, according to object-oriented principles - and not in the renderer. The renderer is only there for RENDERING logic, as the name says. regards, Martin
