Hi Dan,
> Hi again,
> I'm starting to grasp beehive and have managed to write my
> first test now:
>
> Hello hello = (Hello) Beans.instantiate( getClass().getClassLoader(),
>
> "pkg.HelloBean" ); assertNotNull(hello);
>
> ControlContainerContext context = new ControlContainerContext();
>
> HelloControlTester user = new HelloControlTester();
> HelloControlTesterClientInitializer.initialize(context, user);
>
> assertNotNull(user);
> assertEquals("hello!", user.hello());
Excellent!
> Simple enough! What I didn't grasp before was that the class
> which contained @Control definitions needed to be run through
> the generator as well to generate the "XXXClientInitializer"
> class. I had figured it was done through reflection on the
> fly magically :-)...
>
> Anyway, this has given risen to a couple questions...
> 1. Why are Implementation classes "jcs" files instead of java files?
Strictly speaking, they don't need to be. At the end of the day, all
control source files are really just annotated Java files. That said,
there are a number of reasons why the .jcx and .jcs extensions exists.
Initially, it was legacy -- historically controls have used those
extensions, and there hasn't been sufficient impetus to get away from
it. It's the easiest mechanism for tools to identify the semantic type
of the file. Ideally, tools could do file-sniffing and be taught to
identify a class annotated with @ControlImplementation as semantically
different from one annotated with @ControlInterface etc, but existing
tools aren't like that. For example, to get Sun's apt tool to even come
close to handling dependencies between control interfaces and
implementations properly, we had to write some wrapper code that lets
you specify the order extensions get compiled in (in our case, because
we do code-gen during the processing of files, and the programming model
allows dependencies on generated classes, it's not good enough to rely
on straight forward static Java dependency analysis).
We're planning to get the point where the extension is transparent by v1
GA, but that work isn't particularly high priority at this point.
> 2. In the control tutorial there is just a bean which is
> instantiated (ie the first line of the test). For classes
> which contain "@Control"
> definitions is the "XXXClientInitializer" pattern above the
> best way to initialize them? Or is there some kind of
> container which does this automatically?
Yes and yes. The runtimes for all Beehive artifacts (controls,
pageflows, web services) contain code that automatically calls the
ClientInitializer class when necessary (actually, pageflows may still be
using private code dating back to before the ClientInit code was written
-- I know a JIRA issue exists to track updating that). The sweet spot
for controls usage in v1 is in those artifacts. We need to provide more
documentation here; my sense is that the ClientInitialization docs
should be primarily a part of the "container integration" docs, and only
peripherally a part of the "application developer" docs.
Glad you're making progress wading in :)
