Spot on Greg,
Your proposal is much better, if the include id is only used to
namespace the contents and you loose nothing else by leaving this out.
It seems quite logical then to breakdown the view of some controller
class into parts without qualifying them if you wish to keep the
controller variables/bindings flat.
Shame about the applet restriction. Any way to save plumbing time and
code noise is important for a modern api and using convention rules is a
good way of offering this. It sounds like the WTKX annotation is all
you have planned for now, so I'll continue building out my application
and think about this some more. Being 'efficient' with my time (some
might call it lazy :) I will probably build some utility class to do
more complex auto-binding and I'll shame my thoughts/code if I get
something like a potential patch together.
thanks...Roy
Greg Brown wrote:
If this is a patch, can you please submit it by attaching it to a new
JIRA
ticket (http://issues.apache.org/jira/browse/PIVOT)? Routing
contributions
through JIRA help with possible legal ramifications.
That was my bad - I forgot that we are managing patch submissions via
JIRA now and had asked Roy to post it to the list directly.
Roy-
Regarding the patch: if I understand you correctly, I believe it is
intended to make WTKX IDs defined in an include available in the
parent namespace without needing to qualify the name with the
include's ID. Is that correct? For example, given the following WTKX:
foo.wtkx:
<Window>
<content>
<wtkx:include wtkx:id="bar" src="bar.wtkx"/>
</content>
</Window>
bar.wtkx
<BoxPane>
<Label wtkx:id="myLabel"/>
</BoxPane>
The "label" value would now be accessible via get("myLabel") on the
root serializer, not just get("bar.myLabel").
I'm not sure I like that particular solution, since I think it could
generate confusion. For example, what if "myLabel" is also defined in
the parent include? However, I have another suggestion that might suit
your needs (I actually think Noel may have made a similar suggestion a
while back). Currently, if an include defines named values and isn't
given an ID itself, WTKXSerializer displays a warning (because there's
no way to access those values). However, we could simply add those
named objects to the parent namespace in that case. If the
<wtkx:include> tag does have a "wtkx:id" attribute, they would remain
accessible via the fully-qualified name only.
Would this address what you are trying to accomplish?
In response to the other question you had asked about why we don't use
the @WTKX annotation in the tutorials: WTKX binding uses reflection to
set member variables, which are generally private. This is considered
a privileged operation by the JVM, and untrusted code (such as that
which often runs in a web browser) isn't allowed to execute it. Using
@WTKX in the tutorials would require us to sign all of the tutorial
apps, which wouldn't otherwise be necessary.
Greg
