>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
