<snip> robert burrell donkin wrote: > most times i've used generation before i've had a pretty good > understanding of the code. i really can't say that about ecs2. what i > need to move forward on generation is to focus on just one ecs package > - let's say rtf - and get templates that seem to work ok for that. > then they can be rolled out and refined as we go. what would be really > useful for me is just one or two typical example classes from rtf > hand-coded. i can then use these as a base-line and attempt to > generate to them (ie. have a template that produces identical output > for those classes). once i've got to that stage i'd need you to go > through and take a look at the complete rtf package and make sure that > the generation's working ok. we can then try to generate everything > and maybe create some junit tests for the major packages so we can > make sure that the stuff works. then we'd need to start tweaking by > hand - and we'd be committed to the generated code. Agreed. > > > another issue is one of the main features of ecs are all those really > handy methods which can't really be generated. from what i can see, > the work on html seems to have stalled (i'm happy to be corrected, > though). so even once we've got a set of templates that you, we'll > still need to go through and transfer methods across. Yeah, If we can cut down on 70% of the generation of the initial html element code the biggest barrier will be crossed, It's alot easier/fun to code useful methods/constructors then it is a bunch of accessors. Nope, I'd pretty much agree html is pretty much stalled. > if you could find the time just to code one or two typical rtf > elements (i shouldn't need more than that), then i'll start to work on > creating templates for the generation. Ok, I can do that their isn't much to rtf. -stephan --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
