Hey, I just had the following conversation with myself. I'd like your feedback on these topics!
Me: So, now we have support for scripting! Cool! Me2: Yeah, neat. What are we going to use it for? Me: No idea. Me2: Well, let's think about it. Using script languages to define API's is a bad idea. Documentation is very difficult, not to mention IDE support and refactoring. I want my tab completion and "Find usages", damnit! Me: Right. Scripts are probably better for stuff that is not used by any other code. Like building UI's. Me2: Yeah, I saw some really cool Ruby demos where they built Swing UI's interactively. Maybe that's what we should use it for? Me: Could be. But what is the problem we are solving really? Me2: Well, there seems to be two problems. One is that the Java code needed to do the same thing is very verbose, and another is that if we do it in Java then we have the whole compile-deploy-run cycle to consider. If you're building the UI with a domain expert by your side that's not going to be fun. Too slow. Me: The verbosity is not so much an issue. I use code completion all the time, so typing speed is a non-problem. It's been a loooong time since I last typed a whole method name really. Sure, some of the junk needed to do Swing UI's is a bit of a mess, but with decent frameworks like JGoodies that can be dealt with. The long roundtrip cycles is a real issue though. Me2: Hm... maybe we ought to think about what is involved with doing UI's anyway. It's not all the same. Me: How do you mean? Me2: Well, there's two very different kinds of coding involved when doing UI's. First there's the work needed to build widgets. This can be done in relative peace and quiet, and you can spend time making the widget feature-rich and of high quality. The second is when you take these widgets and put them together into a real application, which deals with a specific problem or domain. That's where speed really is an issue, and you want to be able to quickly get things done, and try out different ways of solving a problem. Me: So scripting then would be good for the second, but terrible for the first? Me2: Yeah, probably. Me: Ok, so we have narrowed it down to which problem it is we want to solve. Next question is, is scripting the best way to solve it? Me2: Maybe. If all we are doing is glue code, i.e. take this widget and attach it to this domain object, there's other ways to do it. For example, it might be possible to do a drag&drop UI builder where you simply create the UI using a widget toolbox, and attach it to the existing model. Then serialize the whole thing and deserialize it at startup to recreate it. No coding involved. Me: This sounds a bit like Visual Basic style apps. Is that going to work? How complex stuff can you do if all you have is drag&drop? What about actual business logic? Me2: No idea. Me: What if we combine it? Use drag&drop visual style to do the outline, and then use scripting for the glue code. Would that work? The script code could be part of the serialized state of the UI actually, so it's still the same basic idea, just a bit more intelligent. Me2: I guess it's possible. So, then we'd want some kind of base platform for building these UI's, which has two modes: build-time and production-time. When in build-time you would have extra toolboxes that you can use to create the UI, and in production-time it's just being run. Me: Sort of. Me2: Cool. WDYAT? /Rickard _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
