One thing I'm missing is why this would be any more magic than generating the control bean class in the first place.
? Rich
Mike Foster wrote:
From what you guys have said, it seems like there are a few options to me:
Problem -- simple "business logic" controls aren't a single file, even though in most cases the interface is nothing more than exposing all the public methods on the impl:
Tooling solutions:
1) IDE support for keeping interface/implementation in sync, so that changes in one get reflected in the other. You could do this by exposing one editing surface, or file watching pros -- easy to use, doesn't change the current model.
cons -- assuming you automatically expose all public methods, it hard to keep in sync if people want to extend another class, and don't want all the super's public methods to show up in the interface... possible solution is to just keep local methods in sync, and force delegation to automatically expose the super methods you want.
tool specific
2) As Kyle and Bob suggest, a tool could stub out the Impl (either directly or an abstract class).
pros -- provides some value by getting off the ground quickly.
cons -- falls apart under iterative dev. i'm probably missing something :) but how does this stop you from editing both files?
Tool agnostic solution:
1) Much like EJBGen, we could generate both a interface and an implementation from a specially annotated file. Something like this:
@SimpleControl
public class SpecialControl
{
public String hello (String name){return "hi " + name;} // don't know why i needed to type this all out :) }
pros -- we could set this up to generate a full control interface and implementation, no? would simplify authoring cons -- introduces "magic" back into controls. one piece of feedback i've heard from workshop 8.1 is that controls are to magic for their own good. the beehive devs have made a conscious effort to expose the authoring model as exactly what they are -- javabeans.
**************
I guess my take is that this should be a tooling issue. I would favor a IDE integration that keeps both files in sync with some restrictions mentioned above. Or a common design surface. Ias, I'm interested to know what you think of all these options :)
-Mike
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Saturday, November 20, 2004 11:31 AM To: Beehive Developers; Kyle Marvin Subject: Re: Idea on "write only implementation" for control
- one thing that is possible is actually to go in the other direction:
to derive a stubbed out implementation from only the public interface
declaration (since nothing in the public interface ever ref's the impl
class, thus avoiding the apt dependency issue). This is nice for an
initial stub of the control impl, but starts to break down in
iterative dev scenarios (how can i regenerate my stubbed impl after
i've actually modified some of the stub methods).
Yah, that's one of the primary hassles with code-generation in general. I've seen it work nicely where you end up generating AbstractFoo, which isn't intended to be edited, but rather sub-classed.
Basically, you get default no-op types of methods, and just override
in MyFoo as you need. This at least allows for nice TDD-style of
development. But I don't know how subclassing would figure in with
controls.
If you think I'm missing or misunderstanding something, please let me
know! Keep those ideas coming!
I'm personally controls-ignorant aside from what Dan has waved his hands about. Though, I'll be learning more m'self over the next week or two as I work on docs for'em.
-bob
